Re: FormBuilder: field rendering options

From: Date: Mon, 11 Apr 2005 16:56:11 +0000
Subject: Re: FormBuilder: field rendering options
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-37173@lists.php.net to get a copy of this message
On Apr 8, 2005 7:59 PM, Esad Hajdarevic <esad-public@25novembar.com> wrote: > Hi, > > > 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. > > I notice that you advocate using post- and pre- GenerateForm, which is > IMHO not what the FormBuilder should be - it should try to be as > intelligent and as much as developer-friendly as possible while at the > same time not becoming bloated with unnecessary functions. Yes, this is true. And this is what we want it to be. However, you still have not given me any other examples where this feature would help. If this is a one-use thing, then it's a pice of bloat that FormBuilder doesn't really need. > > My ideal is to get FormBuilder build complex forms without writing > long pre and post Generate procedures, which sometimes really makes > using FB at all pointless. Yes, it should be able to do this. Then again, it's meant to do what it does and *you* have to handle the rest. Having pre/post functions allows you to customize the form. I don't see how that's pointless. If you have more possible features to add, please let us know and we can talk about them. > > Writing few lines for a password field each time you need one is not in > nature of code reuse. I agree. > > On the other hand, FormBuilder is very monolithic and is hard to > subclass, so that I could implement the behaviour discussed without > modifying the FormBuilder code. Again, I agree. Hopefully we'll fix that in future versions. > > I didn't try out Structures_DataGrid, but how does this package deal > with these issues when displaying a DBO? Does it, for example, display 1 > and 0 for boolean value or a regular checkbox? I assume it displays whatever DB_DO gives it. There is very little realy DO integration with SDG. I added a bit to handle FormBuilder stuff as well. Check out the DataObject data source. > > Please have in mind that some people are developing heavy form-driven > applications with forms containing up to 20 fields (arranged in a > friendly UI, of course ;-) that would drastically benefit from such a > behaviour. > And I'm developing these things as well. Why do you think I love FormBuilder so much. Again, he's why I don't see this as particularly useful. It's a *one* use thing. It's only for changing fields to password fields. Now, of course, you *could* use it to change some other fields to another type, but I don't see how elementTypeMap couldn't do this for you in most other cases. Also, as I have said time and again, you can always create your own class which extends DO and which your DOs extend. You build your password field thing into that class's preGenerateForm and *poof* it's automatic, exactly as if it was implemented in FB. In truth of fact you can re-implement and change a lot of what FormBuilder does with pre/post generate/process Form. If you make your own class to extend you can have all of your own customizations. I have done this to deal with file uploads, permissions, and many other things. I *could* have implemented some of it in FB, but it's application (or at least system) specific and so it didn't belong in FormBuilder. -- Justin Patrin

« previous php.pear.dev (#37173) next »