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

[Mario Minati]

Am Montag 12 März 2007 12:39 schrieben Sie:
> -------- Original-Nachricht --------
> Betreff: 	[Html-widget] formfu - new features
> Datum: 	Tue, 6 Mar 2007 19:25:25 +0000
> Von: 	Carl Franks <fireartist at gmail.com>
> Antwort an: 	html-widget at lists.rawmode.org
> An: 	html-widget list <html-widget at lists.rawmode.org>
>
>
>
> The following new features have been added to formfu...
>
> *** $form->auto_fieldset( 1 )
>
> This is suitable for most typical forms, and means you can generally
> ignore fieldsets.
> auto_fieldset(1) immediately adds a fieldset element to the form.
> Thereafter, $form->element() will add elements to the fieldset, rather
> than the form
> (or to the last fieldset, if there's more than 1).
>
> 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.

> Any further elements will be added to that second fieldset, instead of
> the first.
>
> Also, you may pass a hashref to auto_fieldset(), and this will be used
> to set defaults for the first fieldset created.
>
> Consider the following convoluted config:
>
> ---
> elements:
>  - type: fieldset
>    legend: The Form
>    elements:
>      - type: text
>        name: name
>      - type: text
>        name: age
>  - type: fieldset
>    elements:
>      - type: submit
>        name : submit
>
> This is much clearer:
>
> ---
> auto_fieldset:
>  legend: The Form
> elements:
>  - type: text
>    name: name
>  - type: text
>    name: age
>  - fieldset
>  - type: text
>    name: submit

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.


> *** AutoSet
>
> There is also a new AutoSet constraint.
> (The 'In' constraint from HTML::Widget has been renamed 'Set' in
> HTML::FormFu)
>
> The AutoSet constraint is only for use with 'select' and 'radiogroup'
> elements (or, specifically, anything which inherits from
> HTML::FormFu::Element::group).
>
> It ensures the input value is one of the set of values defined in the
> element options.
> (similar to HTML::Widget::Element::Select's constrain_values() setting)
>
>  - type: select
>    values: [yes, no]
>    constraints: [AutoSet]
>
> ... is the same as:
>
>  - type: select
>    values: [yes, no]
>    constraints:
>      - type: Set
>        set: [yes, no]

Very nice generalization.

> *** parent(), form()
>
> And for anyone interested in developing their own elements, constraints,
> etc, all elements now have parent() and form() methods.
>
> For any element added directly to a form, parent() will return a
> reference to the form.
> For any element added to a fieldset or other block, parent() returns a
> reference to that fieldset or block.
> form() automatically traverses the trail of parents to return a
> reference to the form.
>
> All constraints, filters, deflators and inflators also have parent()
> and form() methods.
> Unlike HTML::Widget, these constraints, etc are always immediately
> attached to the relevant form field, and never to the form or block
> element.
> This means that inside the constraint (or whatever), parent() always
> return a reference to the relevant form field element.
> This is how, for example, the AutoSet constraint works, automatically
> getting the list of valid values each time the constraint is run.

Yeah, I waited for that ;-)

> *** Regexp::Common
>
> The Regex constraint also now has support for Regexp::Common.
> So, if you wanted to check against Regexp::Common's
>    $RE{URI}{HTTP}{ -scheme => 'https?' }
> to allow both secure and non-secure url's, you can now do:
>
>    $field->constraint('Regex')->common([ 'URI', 'HTTP', { -scheme =>
> 'https?' } ]);
>
> or, in yaml:
>
> elements:
>  - type: text
>    name: foo
>    constraints:
>      - type: Regex
>        common: [URI, HTTP, {-scheme, https?}]

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

> *** Localisation
>
> Just as the field methods label(), comment(), value() and default()
> have the variants:
>    label_xml()
>    comment_xml()
>    value_xml()
>    default_xml()
> to ensure that the supplied string isn't xml-escaped...
>
> There are new variants:
>    label_loc()
>    comment_loc()
>    value_loc()
>    default_loc()
> to allow you to load your label from the I18N object.
>
> ---
> elements:
>  - type: text
>    name: name
>    label_loc: label_name
>  - type: text
>    name: age
>    label_loc: label_age
>
> Keep an eye out for an upcoming feature that will give you control
> over auto-generating the I18N key. For example, the above yaml will
> become something like this:
>
> ---
> auto_label: label_%n
> elements:
>  - type: text
>    name: name
>  - type: text
>    name: age
>
> Well, I think that's all for now, though I'm sure you can guess that
> more will be coming soon!

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?

Greets,
Mario