Re: DB_DataObject and Structures_DataGrid integration

Andrew Nagy wrote:

I like what you have in regards to the bind method, very nice. 2 comments: 1. I would definitely break up the code from the bind method into a private method or use the idea of the source driver so that the bind method only needs to interact with 1 set of functionality. If we start adding different datasources, this method will be very long.

I totally agree. My code is quite a hack, but it works, and shows what the bind method can become. We can first make a private method, then take the somewhat longer path toward implementing global source drivers. But this is all about the internal implementation. The DataGrid users are not supposed to know how bind() is implemented. My patch, with a few improvements (private method, etc...) provide DG/DO today. Tomorrow, we can consolidate the code, as in the Enhance/Consolidate/Optimize cycle.

2. I don't like that it auto generates the columns there. The autogeneration takes place in a different spot. The idea of "bind" is to bind the data with the grid. What if i want to bind my dataobject and then define my own columns?

I'm generating column because this is the only way I found to properly set up field Labels and oderBy properties, according to the DO's fb_fieldLabels property. Additionnaly, don't forget the DO's fb_fieldsToRender property set in the DataObject : this lets you specify the data columns you want. Then, here's what looks smart to me : $datagrid->bind($dataobject); /* Adds all columns as set by fb_fieldsToRender */ $column = new S_DG_C('Edit',...); $datagrid->addColumn($column); ... $datagrid->addColumn($someOtherColumn);

And what about my event-based ideas that you wiped out in your current answer ?

I am still thinking about this :) It is exactly the way .net does it which could be good or bad. To me .net is not intuitive for the app programmer; however, i think the design of .net is very good. So my out look is keep the same premise, just make it easier to use. Using the event based model could add a whole new layer of complexity, but it may be very worthwhile.

.net may not be very intuitive, but I think the event/callback paradigm is very powerful and much more intuitive than the usual GET mess. I think this is not only related to the DG. There could even be some dedicated PEAR package for Event and Callback classes.

I won't be able to start hacking at the code until next week, then I will have been able to do much more thinking on this. Thanks for the contributions!

You're welcome. I'll see how I can improve all of this meanwhile. -- og