Re: Proposal - HTML_DataGrid - Again

Hi -

I haven't yet had a chance to play with PHP5 much, I hope that someone will be able to help me with this. I also REALLY want to port this to a PECL package so that it offers a strong competitor to c# datagrid. Yeah, I would think that PHP5's interfaces and in particular the SPL Iterator / IteratorAggregate interface would provide a great benefit to a tool like this. Of course having it in C would be cool too :) -- but I'll be quite content to use a PHP version.

The datagrid will automatically set the field names if you don't specify any, but will show all of the fields. This way you can use the quick and dirty bind method to bind an associative array and be off and running with just a few lines of code. If you specify any columns, then only the columns you specify will show up. That's perfect. :)

I haven't spent too much time looking at the code, but I was going to also suggest that things like links (href) should not be specified using the API; instead (IMHO) these should be part of a template or something.

I have implemented a column "formatter". This IMHO is really cool and an invention of one of my co-workers. Basically you define a function that you want to display the results of in the cell, and you can pass in elements from the dataset. So I can have a printLink function or a printImage function (shown in my example), or a printDropDown, etc. to show whatever you want in the cell. As a quick and dirty way of printing a link, I have that hardcoded into the column object so you can make a link easily with little code. I have not yet finished the formatter method, I still need to implement the passing in of variables to the formatter function. I hope to finish this soon. That's an awesome solution. While I know that this is an HTML tool -- and therefore specifying HTML attribs in API should be completely acceptible -- it seems to me that having the href stuff as part of the API might not be flexible enough. E.g. if I wanted to use a button instead of the text as the link ... would I run into trouble? It sounds like this formatter idea takes care of all those issues. I wonder also whether it would make sense to have a subclass like EditableDataGrid which had its own methods that apply to editing (and things like specifying links would be part of that clas rather than base DataGrid class). Seems like creating editable datagrids would be a common task & it may make sense to have special (easier) support for that. Maybe not -- just thinking out loud.

As you can see, I am a big proponent of "Quick and Dirty" methods. The app programmer should be able to implement the DataGrid with just a few lines of code and get something very effective, this tends to damper the design of the code a bit, but is nicer in the long run. I agree -- these tools should all make it as easy as possible to get results. As a programmer, though, I'm also willing to do a little more work to accommodate an underlying library that is going to provide more long-term flexibility. I used to think that flexibility in things like output format was really nice in theory but rarely used in practice; however, I've found myself recently using tools like XSL more & more as I have projects that need to output to HTML, XML, and create Excel spreadsheets, etc.

BTW -- Great tool! :) Hans