Re: thoughts on form building w/ or w/o DB_DataObject_FormBuilder

Hi, all,

Bertrand hit the point quite precisely: FormBuilder really is all about Rapid Prototyping.

Agreed; so is the use of automated HTML_QuickForm generation through DB_Table.

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.

That's a pretty big downside. :-( There's another downside, which has bothered me of late: the form itself (i.e., at the client) should not be doing the validation for any serious purposes. For purposes of giving the user some instant feedback without reloading the page, it's great, but probably not for validating and sanitizing data. With that in mind, it appears there is a need for two separate components in the forms question. I think it turns out to be the same as with templating: you need a form-model and a form-view. Combining the two is great for prototyping (HTML_QuickForm, FormBuilder, et. al.). But for extended use and maintenance, especially when you are distributing the workload, I think it becomes less-great. Not sure what that means in light of future development, though. -- pmj