Re: DataObjectOnSpeed Sum-Up

Markus Wolff wrote:

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)

+1 assumeing we can sort out the name :)

- 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)

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: Since get/set is really reserved for object overloading, - these would be ::keys(), ::tableName(), ::table(), ::database()

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.

I had similar issues with my Form interpreter - which had multiple layers of inheritance.. - In the end I had to abandon the design, as It just became to confusing remember all the methods I had to override, etc. In the end, an option list with hooks for callbacks was far clearer.

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.

As I said above, having more that 2 layers of inheritance begins to cause more problems than it solves.

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...

new HTML_QuickForm_DataObjectBuilder(array( 'postFormBuild' => 'postFormBuild') ); function HTML_QuickForm_DataObjectBuilder($options) { $this->options = $options; } ... should be able to encapulate all the config in one.. While this doesnt build the form, it assumes you create templates, it does illustrate the independant abstraction. http://www.akbkhome.com:81/svn/akpear/HTML_DataObject/DataObject/Edit.php Regards Alan

So, what do you folks think about all this? ;-) Regards, Markus

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com