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 <[EMAIL PROTECTED]>
> Antwort an: html-widget@lists.rawmode.org
> An: html-widget list <html-widget@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
_______________________________________________
Html-widget mailing list
Html-widget@lists.rawmode.org
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
