Re: New package: DB_DataObject_FormBuilder (was: Re: [PEAR-DEV] Re: DataObjectOnSpeed Sum-Up)

<wolff@21st.de> wrote : > Bertrand Mansion wrote: > >> Here is a suggestion, I don't know how this could be adapted to your package >> as it seems to extend DB_DataObject. >> >> I would like to add a Builder object to the QuickForm package. Its role >> would be to build the form using addElement() and addRule() calls. It will >> use helper objects a bit like it is done already in the Config package. So >> there could be a HTML_QuickForm_Builder_DataObject that would help Builder >> build its form based on the structure of a DataObject. >> >> Do you get the idea ? > > I guess, actually until now it sounds pretty much like what my class > does. It doesn´t extend DB_DataObject by the way - not anymore. It now > takes a DataObject-derived class as a parameter, extracts its > structure and settings and builds the form according to that information. Yes, sorry, I had reviewed and tested your previous proposal, I just recently discovered you changed your code, not to extend DB_DataObject. It's much better now, so you can forget about my HTML_QuickForm_Builder proposal, it will work just fine with our coming Controller class. >> Of course, this will need some more work. With Alexey, we have worked a lot >> on QuickForm lately. We have refactored the validation process to use a new >> HTML_QuickForm_Validate class that will call HTML_QuickForm_Rule(s) objects, >> like in the Strategy pattern. > > I´m not very familiar with the strategy pattern... is there already > something in CVS that you can point me to so that I can have a look? I had to modify the Strategy pattern a bit to fit our needs. It uses Singleton and Factory too. This Strategy pattern is easy to understand. You have a 'Context'. In our case, the context is the QuickForm object because it contains information about the validation rules added and the values of our form elements. Then you have a 'Strategy'. In our case, the strategy is Validate. It is supposed to be an abstract class, but I changed the concept. It is now some sort of validation rules manager. It will get the validation rules upon request, store them and call their validate() method. Finally, you have the 'Concrete Strategies'. In our case, those are the Rules. They all extend an abstract class HTML_QuickForm_Rule. They are created by our Validate object upon request. Their behavior can be changed at runtime using one or two parameters. They also generate the javascript code needed. QuickForm::validate() ---> Validate::validate() <-------- RuleA::validate() <-------- RuleB::validate() <-------- ... Same thing for the javascript generation. At the moment, you have rules for Regex (regular expression), Callback (callback functions/methods), Range (min/max length, range), Email, Required. The cool thing is that using this pattern, you can add any other validation rule to QuickForm now. You can design your rule which extends HTML_QuickForm_Rule and has a validate() method and that's it. I'll commit that this afternoon. Bertrand Mansion Mamasam