Re: FormBuilder: field rendering options

Justin Patrin wrote:

I assume you meant 'Pass' => 'password'?

Yes. My bad.

It's an interesting idea...you can already do things like this by overriding table() and setting the data type of a field, but of course this doesn't help with password fields as they're the same type as a normal text field.

As far as I could see, FB now has four (or more) different arrays for partialy solving this problem: fb_booleanFields, fb_enumFields, fb_timeFields, fb_dateFields. I think that one should use one array to specify behaviour for the whole form, it makes no sense to keep separate arrays (internally maybe, but extern no) for every field type.

The problem with allowing an option to set types is that the different fields do things differently. Using 'password' here makes sense as it only needs those 3 parameters to cerateElement. However, what if someone puts 'select' in there? FormBuilder obviously won't know what to do with that and you'll get an empty select box.

We can do something like this "Country"=>array("select",...) That would enable to specify further options for the given element For example normal text fields could also be configured: "Name"=>array( "text", array( length=>10, regexp="(.*)?\s(.*?)" ) ) Such attributes are of course in domain of QuickForm, and as of now they don't exist in this way, but we could use this mechanism to pass this attributes to QuickForm renderer.

The only real reason I can see for this option is to make a text field a password field. If you can give enough other examples where this would be useful I'll consider implmenting it.

Also, I think this should be done because of following: 1. It will simplify the current approach where one has separate array for each type of form element. What happends when QuickForm introduces new element? Or why not support the rest of QuickForm elements? autocomplete,textarea for example? 2. It will enable users to configure the elements in a easy way, if attribute passing to QuickForm renderer is possible 3. Maybe (this is somewhat complicated) file-upload processing? 4. Date field that allows custom formatting (not sure if this is currently supported) Greetings, Esad