DataObjectOnSpeed Sum-Up

Hi there, to sum up the thoughts and comments on my proposed package "DataObjectOnSpeed" (working title!) so far: - Number of +1´s so far: Two (Yavor, Arnaud) - Two more positive comments without clear vote (Lukas, Alan) - Three "official" votes still missing - Naming suggestions: * DB_DataObject_Utils (me, but if we´re going for the adaptor

    solution, I´m all for HTML_QuickForm_DataObjectBuilder)

* DB_HTML_FormBuilder (Yavor) * DB-Auto_Form (Yavor) * HTML_DB_Form (Yavor) * DB_DataObject_FormBuilder (Arnaud) * DB_DataObject_Prototyping (Arnaud) * HTML_Quickform_DataObjectBuilder (Alan) * DB_DataObject_QuickformBuilder (Alan) - Change suggestions: * Do not extend DB_DataObject, make an adaptor/wrapper/visitor class

    instead (Alan)

I like Alan´s suggestion in principle, but as he hinted himself, this would mean that some things in DB_DataObject and most of the new options in the DataObject-derived classes that are considered "protected" right now, must be officially public in the future. Also, it would complicate customization of the derived classes at some points. Here´s a list of things that have to become or to remain public: - DB_DataObject::_get_keys() method - DB_DataObject::toArray() method (already is, has to stay that way!) - DB_DataObject::__table property (alternative: make getTableName() method) - DB_DataObject::_get_table() method - DB_DataObject::_database property (alternative: make getDatabase() method) - DB_DataObject::getLinkArray() method (already is, has to stay that way!) - DB_DataObjectOnSpeed::_preDefElements property - DB_DataObjectOnSpeed::add_form_header property - DB_DataObjectOnSpeed::form_header_text property - DB_DataObjectOnSpeed::_select_display_field property - DB_DataObjectOnSpeed::_fieldLabels property - DB_DataObjectOnSpeed::_dateFields property - DB_DataObjectOnSpeed::_textFields property - DB_DataObjectOnSpeed::_submitText property - DB_DataObjectOnSpeed::_primaryKey property (whoops, I´ve just seen that I forgot to document this one :-)) Aside from the encapsulation problems, the downside is that you couldn´t easily override some of the form building methods in your DataObject-derived classes. Example: You want to predefine some form elements before the _generateForm() method creates the form - this prevents the overhead of letting it create some rudimentary fields, remove them again and finally re-add them to the form. You don´t want to do this in the constructor though, because you don´t always need to build a form with your DataObject and this would simply steal performance away at each invocation in such situations. Having an adaptor class for the form building, you can´t override the form building methods in your DataObject class anymore. A possible solution would be to be able to define callback functions within your DataObject, that are being triggered before/after important events such as generating or processing a form. This of course implies having even more public properties for configuration purposes... So, what do you folks think about all this? ;-) Regards, Markus