[html-formfu] Re: Prototype && HTML::FormFu

[Carl Franks]

On 10/09/2007, Brian Cassidy <brian.cassidy at nald.ca> wrote:
>
> This thread kind of got warnocked. Perhaps a re-post will help? :)

Always worth a try...

> > I decided to start with a simple auto-complete element. I can envision
> > the yaml file looking something like this in it's simplest form:
> >
> > - name: foo
> >   type: Prototype::Autocomplete
> >   url: /foo
> >
> > Q: to set the url programatically, say, via the catalyst context, would
> > the best practice be to override the element with a custom one that does
> > just that? (in new() perhaps?)

Remember that there's now support for __uri_for()__ in config files.
It supports ($path, @args), but it doesn't support the final
\%query_params argument.

Other than that, it's down to you whether you want to keep such code
out of your controller's action routine (strict MVC).
I don't normally mind doing something like
    $form->get_field( $name )->uri( $something );
in my controller before using the form - but if you want to keep it
separate, then yes, you'll probably have to make a custom class.

> > Further to the above config, you can set the update_id, and also a
> > generic set of "options" to be passed along.
> >
> > With respect to the update_id, if it's not specified then it is auto
> > generated as "${id}_auto_update" -- this element most likely does not
> > exist and much be created.
> >
> > Q: (more of an api question...) If update_id is specified, should i
> > assume the user will generate that element themselves?

Is this something like a hidden field that gets given the value, so
it's submitted properly?
That might make things a bit harder - will this need to be a subclass
of Block, so it can have child elements?

If you pass the given 'name' to that child element, will Constraints,
etc. which are added at form-object construction be handled correctly,
and attached to the 'real' field element?

If somebody did
    $form->get_elements({ name => 'foo' });
instead of get_fields(), would they get returned both the
Prototype::Autocomplete element, and the hidden_field you add?

It's certainly possible a user might want to explicitly set the
update_id() for css or scripting reasons, but would still like the
update field automatically generated.
I would probably say it's best to have a update_id() value, and a
separate auto_install_update_field() (or something similar).

And if I've completely gotten the wrong idea of how this is
constructed, do tell!

> > Q: What's the best practice for injecting elements into the form from
> > custom elements?
> >
> > I see the the Dojo::Repeatable element, you're adding some elements to
> > _custom_elements() -- should i copy that practice?

If it's something simple like adding a hidden field, you could simply
check for it's existence with
    $self->get_field({ type => 'Hidden', name => 'foo' });
(assuming it's a Block subclass), and skip if it already exists.

Otherwise, it might be good to stick to a convention such as _custom_elements().

Carl