Re: FormBuilder: field rendering options
| From: | Justin Patrin | 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