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

[Mario Minati]

Am Dienstag 13 März 2007 11:21 schrieb 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 this about makeing assumptions about what the user meant or wanted to 
do.
So if he starts with a not fieldset element we coud create a fieldset and put 
all other elements (even other fieldsets) inside to match the xhtml rules.
This functonallity would not be connected to the auto_fieldset function and 
would create a warning on stdout to inform the user.

> > 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!

What do you think of making the restriction that in the auto_fieldset=on mode 
you are not able to create nested fieldsets. This idea is by the asumption, 
that when useing that option yo are creating easy forms and not complicated 
ones.
A second posibility to circumvent forbidding nested fieldsets in that case is 
to create an attribut that tells the fieldset to created a nested one, 
something like "nested: 1".

> 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.

I make a lot use of load_config_file to load standard formgroups, like 
different combinations of buttons at the form bottom. So I support and 
encurage your idea of application-wide config files.

> 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?

With Regex::Common I found some address that still validate but which are not 
valid, at least I've never seen addresses like them:

https://minati.de./ 
(the point after 'de' shouldn't be valid)

On the other hand this url
https://minati.de/index.html#lkj
is invalid, but that might be some trubble with the '#' and the encoding. 
(I'm fighting with utf-8 at the moment, do you have experience in that Carl?)


> > 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.

No that doesn't help at all. I think a way would be studying how and when the 
po file is being loaded and replace or extend that logic somehow. I'll look 
into that after porting my project to the current formfu.

> 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 that is a verygood idea! So we get the best of both worlds (Catalyst and 
FormFu) Go for it.

Greets,
Mario