Description: ------------ In bug #5298, Mark Wiesemann and I agreed that, for more flexibility and coherence, the rendering layer needs to be rewritten. The main idea is to define a new renderer driver interface to make it easy for people to adapt Structures_DataGrid to their own need. Additionally, in bug #5858, Helgi Þormar suggested to split Structures_DataGrid drivers apart, as in the MDB2 package. I think that this is a very good idea, because in the current situation Structures_DataGrid will only get stable when every driver is stable. That means we need to refuse new drivers if we want to reach stable, which is pretty sad. Both of these discussions have one common point : defining a new renderer driver interface. In this regard, the challenge is to avoid design mistakes, keeping in mind that we're into pure MVC : - Controller = Structures_DataGrid - View = Renderer driver - Model = DataSource driver Last but not least, Structures_DataGrid is beta, so backward compatibility is important.

Can you please explain your goals in terms of refactoring the renderer? It sounds like a good idea, but I am curious as to how you plan to do this as the renderers are already abstracted with an Abstract Base Class. While on the topic of refactoring, it might be good to look at other components such as how the SDG class extends the SDG_Render class with then extends the SDG_Core class. I did this to abstract the different parts of the class for easier maintainability however, all methods are accesible from 1 class. This might be good to revisit and implement some sort of object pattern. Please explain your goals in more detail for commenting.

Oops, I was thinking of the data source class. The renderer should definitly have an abstract base class to work from.

Indeed, the renderer layer needs an abstract driver class. Calling column formatters has nothing to do with renderer drivers, and should happen inside this abstract class. And, the renderer driver interface must be clarified for users to be able to write/adapt drivers easily. Something like : class Renderer_FooBar extends Renderer { function header($labels) {} function row($content) {} function footer() {} // optional } should be fine. A user could for example overload the header() method of the Renderer_HTMLTable driver, while leaving the row() method untouched. See bug #5298 for more on this. Currently the driver interface consists in one render() method where everything is mixed up. That is not flexible. I completely agree on the problem of the DataGrid extending the Renderer extending the Core. It is well known that big class trees eat memory in PHP, and this hierarchy is useless. The solution is to move everything from the Core and the Renderer into the DataGrid. The Core would disappear, and the Renderer, now empty, could become the driver abstract class. So, to answer you first question, my goals are : clarification, flexibility, optimization and, by splitting drivers apart (thanks Helgi), maintainability. AFAICS this refactoring shouldn't cause any major BC break.

So how do you see the render method working? Does it call the header, row and footer methods? With the the HTML table renderer, it builds the header, body and footer into an HTML_Table object then you can access the resulting object via the getTable method, you get to the html via the toHTML method or you can just print it via the render method. How would this transfer over to the new model?

Well since the package is beta it is discourage that a BC breaks are made but if it has to happen then so be it :) Anyway I don't have much experience in SDG internals (only long time ago) but well just look at MDB2 or Text_Wiki (they are splitting of their drivers also, http://pear.php.net/package/text_wiki see the dep list at the bottom) So well, you should be able to split off renderer + datasource with out doing all the refactoring you are talking about (I mean the structure is the same, just isn't all installed at the same time) but since this refactoring is essential for the future of SDG then I guess you should finish it first and then just do the splitting :)

Late, but not too late, here are some opinions from me: - render() should behave the way it behaves now, i.e. in the HTMLTable renderer it will output the whole table and therefore call the methods Olivier described: header(), row() and footer(). If people (like me) want now to have custom header and footer rows they can extend this renderer class and overload header() and footer() - Regarding the renderer class: it should not extend the main class, but there should a base class that the renderers extend from. render() (calling the render() method in the chosen renderer) should be available in the main class for users comfort and for BC reasons. - The package split should be done like in MDB2, so there will be new packages like Structures_DataGrid_Renderer_XLS, Structures_DataGrid_Renderer_HTMLTable, Structures_DataGrid_Renderer_XML, ... and Structures_DataGrid_DataSource_DB, Structures_DataGrid_DataSource_DBQuery, Structures_DataGrid_DataSource_Array, ... including all the checks that MDB2 does (cp. factory method in MDB2/MDB2.php). With this, there won't be any BC breaks, but a lot more flexibility for using and extending SDG.

Hi all, Just to say I made a temporary workaround for those like me who want to render structures_datagrid thru a template engine like smarty. It's Structures_Datagrid_Renderer_Array, you can get it on my website. I didn't want to propose it to integrate to the current sdg release for the simple reason that I knew the refactoring was about to be done regarding the rendering system. Anyway it seems obvious to me that the an array renderer would be needed in the next release, or as a separate package depending on what you decide. The main purpose for this class was to have a renderer that would make a result similar to what is done with the array renderer used in HTML_QuickForm. IMHO the next release of structures_datagrid, while keeping the current API, should strongly inspire from HTML_QuickForm rendering API so that for the many projects that are mainly database frontends, the use of both SDG and QF in the same rendering environment sounds coherent. PS : the Structures_DataGrid_Renderer_Array I wrote is a patch made from Structures_DataGrid_Renderer_HTMLTable, in my version I removed the header comments because I was not sure what to put in while it's not part of the SDG package. What do you think about this, should I at least declare the original author and myself, the package, the licence ?

Hi, Thank you for your comment, this array renderer seems very useful indeed. I have just started to rearrange the core classes, merging DataGrid, DataGrid_Core, and DataGrid_Renderer (in CVS), as Andrew and I agreed (see above). The Structures_DataGrid_Renderer class is now becoming the Renderer drivers' base class. It should soon be easier to write a such Array driver. No, you can't wipe the copyright header this way. Article number 1 in the PHP license is : "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer." It does not matter wether this file is part of SDG or not. You can modify it, use it in some other software, sell it, etc, provided that you keep the header and copyright. Simply add your name to the list of authors.

The refactoring of the rendering layer is almost done in CVS. More tests need to be done, of course.