Re: FormBuilder: field rendering options

On Apr 8, 2005 6:16 PM, Esad Hajdarevic <esad-public@25novembar.com> wrote: > 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. Well, this is a bit different. By putting a field in these arrays you're effectively changing the DB_DataObject type of the field. For example, putting a field in fb_dateFields is exactly the same as overloading table() and making a field of type DB_DATAOBJECT_DATE. An example: class DO_ex { var $fb_dateFields = array('dateField'); function table() { $ret = parent::table(); $ret['dateField'] = DB_DATAOBJECT_DATE; returnn $ret; } } Those two things do exactly the same thing. So really the arrays and overriding table are the same thing. Now that you bring this up I'm going to propose that we remove those type config option arrays entirely in favor of overloading the table() function (or altering the ini file). In truth, DB_DO now understands booleans and dates, at least for mysql. My point here is that changing the DO type of the field via the config arrays is not the same as specifying the QF element type. There's effectively three layers here. The DO element type is first and this type specifies the FormBuilder type which specifies the QF type. Pretty much the DO type specifies the QF type, but the FB layer also make some differences (mostly with the special types such as the crossLink). > > 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. True, and bringing it all into table() fixes this problem. > > > 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. > Now this is getting even harder to deal with. FYI there are two options which allow you to set the attributes of elements. elementTypeAttributes and fieldAttributes. They let you specify attributes for element types and specific fields. Things such as adding a regexp rule for a field should really be done in postGenerateForm or after you call getForm. Adding options for a select should also really be done in postGenerateForm...*or* you could make that an enum instead and specify the options in a callback or in the enumOptions config option. > > 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? > Yes, the current options should be brought together. And that can be done in the table() function. > 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? > It's always been our stance on file uploads that their handling is very application specific. Whether the file goes into the DB, where it's saved to, whether its renamed, what exactly is stored, this is all very hard to specify and we figure it's much easier for you to do it in your own application. You can specify the handling in a DO class which your DOs subclass (this is what I do). > 4. Date field that allows custom formatting (not sure if this is > currently supported) > Not really. You can specify the format of all of the date fields in a form with an option (dateElementFormat). If you want to specify per field you may be able to in preGenerateForm by making preDefElements, but I don't know if they'll go in the DB correctly. Now back to your original question. I'm still not sure that there are enough examples where the specific QF type needs to be specified. Given all of the above can you still think of any other times you would want to change a type where you wouldn't have to do extra configuration? For an autocomplete, for example, you have to specify the autocomplete options. If you have to do this extra processing you might as well create the element as well. -- Justin Patrin