Re: Driver Interface and protected properties

Hi, Mark Wiesemann wrote: >> Stab in the dark but maybe this is a templating question, Im working >> with some .NEt programming atm, i found this quite insane, all u need >> to do is put a datagrid tag placement with an id of the variable of >> the dataset and it generates the grid for u > > (1) Please put feature requests directly into the bug tracker. Right. > (2) Not exactly this, but a very convenient way to fill a custom > container is provided with the new rendering interface. For the > HTMLTable renderer this means that you pass an existing HTML_Table > instance to the SDG method fill() which is then "filled" with the > datagrid. The Smarty renderer will behave with fill() in a similar way > -- at least, I think so. As Olivier stated, he has found a problem with > the new rendering concept and the Smarty renderer. But I'm sure, that he > (or we) will find a solution for this, so that all renderers have this > common fill() functionality. Just for you all to know, here is the basic fill() paradigm : $table = new HTMLTable(); // Optionally customize your $table object, prepend some header/body/footer, // rows, etc... Then pass it to the datagrid : $datagrid->fill($table); // the datagrid has now filled the $table with data // You can further customize $table if you wish so. // Then you can : echo $table->toHTML(); fill() is generally not meant as a replacement to render(). It is just a more flexible alternative. >> Maybe it could be incorporated in the smarty and flexy renderer >> (waiting for the stable code next week to rework that). The trouble I'm having with the Smarty renderer is that I just realized that the fill() method just makes more sense with it, while the render() method is pointless. Why ? Because the Smarty needs to do a lot of bad and intrusive things that it wouldn't have to do if it was the sole user responsibility to call Smarty::display(). The fill() method allow/require the user to call display by him(her)self, but the render() method forbids it. After some more investigations I came to the temporary conclusion that : - with some drivers calling SDG::fill() makes sense but SDG::render() doesn't, - " " " calling SDG::render() makes sense but SDG::fill() doesn't, - " " " calling SDG::render() and SDG::fill() both make sense, And I'm trying to make the rendering layer allow these three flavours. Any comment is welcome. > > Olivier told you via the bug tracker that this won't happen next week. > Please be patient. ;-) You will be contacted by us when the Smarty is > ready enough to a be "template" (*g*) for the Flexy renderer. Yeah, first we're targetting a release with the new design for the end of march, then we'll see what we can do with new renderers requests. Regards, -- og