In this mail, I'll just address the past week's changes which will
require code changes for anyone experimenting with formfu.
Originally, HTML::Widget had a form/element stage, and a result stage(),
with the html generation muddled within both stages.
With my first pass at HTML::FormFu, I split it out to 3 stages: a form
form/element stage, a result stage, and a render stage.
I've now simplified this, so that there is now only a form/element
stage and a render stage.
All "logic", such as generating "for" label attributes, generating
IDs, etc has been moved from the result to the form/element stage.
The render stage only massages data structures into html.
For anyone who wishes to use just [% form %] in their templates, they
can ignore the render stage completely, as render() is automatically
called when a form or element is stringified.
This means there is no more $result object.
You can now just print the $form, rather than having to print $form->result.
If there's input, you need to either set the query, then call process():
$form->query( $q );
$form->process();
or pass process() a query object or hash-ref of input values:
$form->process( $q );
The methods which were previously on the $result object, such as
submitted(), has_errors(), params(), param(), add_error() and add_valid()
should now be called from the $form object.
if ( $form->submitted && !$form->has_errors ) {
my $input = $form->params
}
The only real use for having seperate form and result object that I'm
aware of, was being able to create multiple result objects from the
same form.
To replicate this, you can instead copy the form with $form->clone(),
which doesn't copy the internal $query object.
Another big change, is that the syntax for creating elements,
constraints, etc has been changed to optimise forms defined in a
config file, over those created in perl code.
The arguments varients for element() are:
elements( 'type' );
# or
elements( \%options );
# or
elements( [EMAIL PROTECTED] );
An example in yaml is:
---
elements:
- type: text
name: search
- type: submit
name: submit
label: Google Search
- type: submit
name: lucky
label: I'm Feeling Lucky
You might notice in the above, it was 'text' and not 'Text'.
I've lowercased all the element filenames.
My reasoning is, that it was giving too high a visual cue to the
element type, which isn't really the most important thing - generally
the name is.
I think in the yaml example above, the leading dash for each list item
provides enough of a cue/divider between each element.
Now, I'm not a 100% on this change, so I'm open to discussion, but I
think it's generally for the best.
The syntax for creating constraints, filters, etc has also changed. It is now:
constraints( 'type' );
# or
constraints( \%options );
# or
constraints( @arrayref_of_the_above );
To expand the above yaml with some constraints and filters, might look
something like this:
---
elements:
- type: text
name: search
constraints:
- Required
- ASCII
- type: Length
max: 100
filters: [TrimEdges]
- type: submit
name: submit
label: Google Search
- type: submit
name: lucky
label: I'm Feeling Lucky
The modules Catalyst::Controller::HTML::FormFu, DBIx::Class::FormFu
and HTML::FormFu::Dojo have been updated to take all these changes
into account.
Feedback would be most welcome!
Cheers,
Carl
_______________________________________________
Html-widget mailing list
Html-widget@lists.rawmode.org
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
