Re: Datagrid class in PEAR?

[As it seems, I accidentially sent my replies only to the sender instead of the list, so now I repost them, hoping that some more people joing the discussion] Am Fri, 19 Apr 2002 10:32:07 +0100 schrieb Peter Bowyer <reywob@f2s.com>: > >Also, I don´t want and don´t like having custom tags in a template that > >add any logic to the template itself. That´s why I use a simple template > >class like IT[X] and not Smarty. I´m always trying to achieve a 100% > >separation between design and code. Designers design, coders code. It > >shouldn´t be mixed. > > I'm going to have to disagree with you on that one. I believe Smarty > allows much better separation as the coder has to no nothing about the > presentation, and merely has to pass the data to the designer. By contrast > in IT[X] it is up to him to set blocks etc in the PHP code, and if the > designer decides that this isn't going to be a repeating block any more > then he has to change the PHP code. Okay, so what we have is this situation... Smarty: - The coder has to know nothing about the design - The designer has to know about the template language syntax and the functions that the coder offers to him IT[X], phpLib templates, FastTemplate etc.: - The coder has to define some basic rules (e.g. what data is to be repeated and what is one-occurence-only data) and to pass out a list of placeholders to the designer - The designer has to learn a minimum syntax for the block definitions and then designs the template as he likes, using the placeholder list given to him. While having logic inside the template might(!) make sense in something like a content management system where the structures are not strictly predefined and you can have lots of different components within one page, I think this is total overkill for a grid template. What is a datagrid anyway? Basically, it´s a collection of columns and rows. Every row has the same number of columns. At the top and bottom of the table, you usually have one fixed row for each the table header and footer. This structure is the same for all datagrids. Why fire a template engine with a dynamic scripting language at a non-moving target? In the class that I have written so far, a most basic grid template can look like this: <table> <tr> <!-- BEGIN headerColumns --> <td>{fieldName}</td> <!-- END headerColumns --> </tr> <!-- BEGIN rows --> <tr {rowStyle}> <!-- BEGIN columns --> <td {colStyle}>{data}</td> <!-- END columns --> </tr> <!-- END rows --> </table> Notice the {rowStyle} and {colStyle} placeholders? The designer does not have to use them, if he can live with a fixed design for each data row. If he wants changing styles for odd/even rows, he can use these placeholders. He can still define what styles are being used for the placeholders by editing a grid configuration file. Because the configuration file class is designed to be able to load settings from different files while overwriting previously set values with the ones from the last added file (I hope this is clear, I don´t know how to express this better) the designer can have a configuration file with only the configuration options needed for the visual appearance of the grid, so he can´t break anything. Also, this file can be well-documented, so it´s obvious to him where to insert what. No learning, no brains needed ;-) The configuration file method also allows for other possibilites: As my config file class allows using either arrays, .ini files or .xml files for the input, it should be easily possible to write a visual editor for the grid configuration that produces these files and provides a direct preview of the finished grid, so the designers life can be made even easier ;-) It´s all about acceptance and ease of use ;-) Regards, Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1