Re: thoughts on form building w/ or w/o DB_DataObject_FormBuilder
| From: | Markus Wolff | Date: | Sun, 12 Sep 2004 22:57:38 +0000 |
| Subject: | Re: thoughts on form building w/ or w/o DB_DataObject_FormBuilder | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-33360@lists.php.net to get a copy of this message | ||
Norbert Mocsnik wrote:
Bertrand Mansion wrote:Hi Norbert, Bertrand hit the point quite precisely: FormBuilder really is all about Rapid Prototyping. However, if you need more flexibility, you're always free to put a getForm() method in your DataObject, where you can construct a QuickForm object as you please and return it - the form generation process will then be completely omitted, but you can still use the auto-processing FormBuilder provides. I've sometimes found myself using QuickForm directly in the past and I even recommend using it instead of letting FormBuilder do the form generation for you to gain speed once the application is in a state where it won't change much anymore. To make my life easier, I've also written a small class that automates all the page processing logic for me - it will take a DataObject, a template object and a third parameter that determines the type of the template (static/dynamic) and do everything else on its own - a whole database-driven page can become a four-liner this way. Another approach to somehow use a future QuickForm version might be to use a markup similar to that of ASP.NET, which could look like this: <qf:form name="myForm" datasource="variableName"> <fieldset> <legend>Just to say that normal HTML can still be used here</legend> <qf:label for="element">My label</qf:label> <qf:input name="element" type="text" valueMember="sourceFieldName"> <qf:rule type="required" /> <qf:rule type="minlength" param="3" /> </qf:input> </fieldset> <qf:button type="submit" name="submit" </qf:form> Something like this could be achieved with either PHPTAL or XML_Transformer. Downside: You'd need to do all your templates entirely using one of these packages or you'd need to have extra templates for all forms. CU MarkusFormBuilder is aimed at rapid prototyping (thanks to DB_DO and QF) but also allow some nice customizations that are more than enough for most users. But if you need more complex stuffs, I think going directly with QF is more appropriate.Thanks for the thoughts Bertrand! I was thinking about using QuickForm directly but if I do that I loose the features offered by FormBuilder: auto-filling from a db, populating <select>s from linked tables; auto processing of crosslinks and triplelinks (which means handling 3 or 4 tables at the same time) etc. On the other hand, using QuickForm directly gives really more flexibility (knowing that you can still access & manipulate the form when using FormBuilder).