[Fwd: [Html-widget] formfu - new features]

[Carl Franks]

On 12/03/07, Mario Minati <mario.minati at googlemail.com> wrote:
> Am Montag 12 März 2007 12:39 schrieben Sie:
> > Von:  Carl Franks <fireartist at gmail.com>
> > If you add another fieldset, that gets added to the form, not the
> > existing fieldset, as fieldsets shouldn't be nested.
>
> They are not allowed to be nested, realy?
> I thought of useing nested fieldsets for organizing forms.

Nope, I'm wrong! I found that out yesterday when I noticed that
radiogroup uses a fieldset, so I checked the xhtml 1.0 spec, and
there's nothing about fieldsets not nesting.
I think I must have been confusing this with forms not being nestable.

This means I'll have to rethink how it should work exactly, as I don't
want to stop the user being able to do something which is valid.

> I think the auto_fieldset is very clever and should be on by default. So if
> the user creates an fieldset everything is fine and if not formfu does this
> job for him.

Sounds a little too much like the HTML::Widget magic that caused lots
of problems!

Because config files can call 'load_config_file' themselves, and so
recursively load other config files, I'm hoping it becomes standard
practice to have an application-wide config file, which sets all your
defaults, and which you load from all your other config files.
So you only need to set auto_fieldset once, if you wish to use it exclusively.

This is also the purpose of the 'element_defaults' setting.
So, if you want all your text boxes and textareas to be 30 wide,
throughout your application, just set it in your master config file
rather than on every element:

---
element_defaults:
  text: { size: 30 }
  textarea: { cols: 30 }

> I'll remove my Webaddress constraint soon, but did you try the upper
> constraint once? Remember my comments concserning accepted urls?

I not sure exactly what you mean. Remind me?

> The auto_label option is very nice. One question is in my mind on that. I
> already have a catalyst I18N object which I can hand over during form
> creation. Do you know a way to split the en.po in multiple files or in a
> hierarchy of files?

I haven't found any built-in way to do this, except to set
Locale::Maketext's fail_with() and provide your own fallback.
This doesn't really help, because we'd generally want to check with
the user's loc() before formfu's own - so the fail_with() would need
to be set on the users I18N object, not formfu's.
And we currently only require that the user's I18N object provide a
compatable loc(), so they might not be using Locale::Maketext.

What I'm thinking of doing, is checking with the users loc(), and if
that dies, then check with formfu's own.
This could still fail if the user has set their own fail_with(), but
if they've done that, they should know what they're doing.

Carl