Description: ------------ (This was originally an email. I post it as a feature request, so this does not get lost. The links include updated versions of the diffs against current CVS versions.) I have finished a first version of the new class. - the new class file Header.php (using the new comment header format [maybe with wrong license text]) http://www.markwiesemann.de/php/Structures_DataGrid/Header.phps - diff for Core.php with new functions: - setHeader() - setFooter() - getColumnCount() (useful not only for the header but also for other things) http://www.markwiesemann.de/php/Structures_DataGrid/Core.diff - diff for HTMLTable.php including: - the suggested change (return PEAR_Error) I have mentioned in my last comment in feature request #4379 (Header::getStartColumn() also returns a PEAR_Error object ==> adding this is also needed therefor) - the change of setTableHeaderAttributes() as described in my last mail http://www.markwiesemann.de/php/Structures_DataGrid/HTMLTable.diff Very simple usage: $dg->setHeader(new Structures_DataGrid_Header('Test header')); $dg->setFooter(new Structures_DataGrid_Header('Test footer')); With background-color: $dg->setHeader(new Structures_DataGrid_Header('Test header', array('style' => 'background-color: red;'))); With number of columns (default: span over all columns): $dg->setHeader(new Structures_DataGrid_Header('Test header', null, 3)); And finally, with the name (fieldName in Column object) of a column as the start column: $dg->setHeader(new Structures_DataGrid_Header('Test header', null, null, 'date')); I have tested the different usage types described above and also other combinations of them. There is also no change in functionality in HTMLTable renderer when using allowEmptyRows == true: the footer is appended after the empty rows.

Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PEAR. Well... Is it really necessary to include this in Structures_DataGrid ? If you simply want to give a title to your datagrid, why not simply echo a "My Datagrid" before or after it ? Is it necessary to put this inside header or footer cells ?

This request is not only for a simple title. One can also you use it for an multi-column header (currently only one, but this could be easily extended to allow more of them, for example via an array of Header objects). I'm currently using it this way: - header row: an information like "page x from y, record a to b from c" - footer row: paging links (from renderer->getPaging()) This way the paging information and links fit optically very nicely, and the user sees all the relevant table data alltogether. And finally: The code and the way it is integrated into SDG was developed after an discussion with Andrew. I can provide updated patches against current CVS code. If request #4709 is accepted, I can combine the patches, as they are very much related.

To me, the key idea is : - adding renderers or extending the renderer layer may bloat SDG. - Instead we should make it _easy_ for people to write their own rendering drivers, and properly _document_ how they can do it. That's what I tried to do when I wrote the DataSource layer, and according to the many new drivers submitted, it worked... People got familiar with writing their own driver. For example, I personally need a stats table to have the following header : +-----------+-------------------+---------------+ | | Mean hits per day | Total | | Period +---------+---------+--------+------+ | | Visits | Hits | Visits | Hits | +-----------+---------+---------+--------+------+ Is your implementation design compatible with what I need ? Wouldn't it be better for me to extend the current HTMLTable renderer in one way or another, overloading a couple of method ? Unfortunately the HTMLTable renderer is not designed to be extendable by the user... Neither is the whole rendering layer. The problem comes from the fact that the renderer driver interface consists in one render() method where a pretty obscure process happens. Additionally, I'm not very attracted by the idea of adding a new class, and instantiate extra object(s) just to add a few header and footer cell(s). From my point of view, the rendering layer needs to be rewritten.

> For example, I personally need a stats table to > have the following header : > +-----------+-------------------+---------------+ > | | Mean hits per day | Total | > | Period +---------+---------+--------+------+ > | | Visits | Hits | Visits | Hits | > +-----------+---------+---------+--------+------+ > > Is your implementation design compatible with > what I need ? You have two (three) multi-column headers (the first one with colspan 1) - this is currently not supported. But it can be easily added (I already thought about it, but didn't add it to the code yet). The "Period" column would need to be a one-column header with rowspan 2. > Wouldn't it be better for me to extend the > current HTMLTable renderer in one way or > another, overloading a couple of method ? I agree, but with the current design this would be a only little addition ("little" related to the lines of code) with a useful effect for the users. > From my point of view, the rendering layer needs > to be rewritten. The structure is not optimal, yes. But a full rewrite of the rendering structure and all the renderers would be a lot of work, especially regarding full backwards compatibility (not needed in beta state, but expected) and testing all the changed stuff.

>>Wouldn't it be better for me to extend the >>current HTMLTable renderer in one way or >>another, overloading a couple of method ? > > I agree, but with the current design this would be a only little > addition ("little" related to the lines of code) with a useful effect > for the users. I see your point, but instead of trying to provide workarounds for the current deficient design, we should refactory the rendering layer before it's too late, that is : stable. >>From my point of view, the rendering layer needs >>to be rewritten. > > The structure is not optimal, yes. But a full rewrite of the rendering > structure and all the renderers would be a lot of work, especially > regarding full backwards compatibility (not needed in beta state, but > expected) and testing all the changed stuff. It is not exactly a full rewrite, just a design modification which should be quite easy to perform. Here's the renderer driver interface I propose : class Renderer_FooBar extends Renderer { function header($labels) {} function row($content) {} function footer() {} // optional } Second point : calling column formatters has NOTHING to do with renderer drivers. That must happen in the Renderer base class. Then, once this base class has all the contents, it sequentially calls the driver's header(), (multiple) row() and optional footer() method. Please note that the Renderer base class I'm talking about would be quite different from the current Renderer class. It would be designed as a driver abstract class, and as such would never be instantiated directly. There could be a Renderer::create() method similar to DataSource::create(). Conclusion : Whatever complicated headers I'd need, I'd simply have to overload the header() method. This is by far the most flexible architecture : - need to highlight some rows if their content match a specific pattern (like search results) : simply overload the HTMLTable's row() method - need a footer ? Overload the footer() method. - you don't want any table ? You prefer a more verbose result (looking like Google results for ex) ? Simply write a custom renderer driver that generates raw HTML.

Olivier, I agree to both your arguments and the structure of the renderers. With this, it should be also very easy for me to add my header/footers. So, if you want to restructure the renderers, I'm willing to help you with testing the "new" code.

This request did not just include the header/footer rows but also a new function called getColumnCount() in Core.php. This was especially useful for the needs of my SDG_Header class but I can think of other cases where this could be useful. Maybe you want to add it to Core.php? The function can be found in this diff (at the middle, ignore the parts before and after it): http://www.markwiesemann.de/php/Structures_DataGrid/Core.diff

For now, this method is not needed, and the new rendering layer may do this in a different manner. The discussion continues in bug #5859

Maybe better to leave this open, even if the conclusion will come from bug #5859.

getColumnCount() is in CVS, fill() provides enough flexibility for my header/footer needs. ==> closing this