The list's been quite quiet the past couple weeks, so here's an update
of what's been happening in svn...
To complement $form->javascript(), there's a new method;
$form->javascript_src() which accepts a URI, and renders as a script
tag with a src="" attribute to load an external javascript file. It
accepts a single URI, or a list of URIs which renders as multiple
script tags.
When render_processed_value() is used to display the result of the
value after being processed by any Filters, Inflators and
Transformers, the value is now also run through any associated
Deflators.
All constraints which have an others() method now share a common base-class.
They now have new methods:
attach_errors_to_base(1)
attach_errors_to_others(1)
attach_errors_to([EMAIL PROTECTED])
which determine which fields any errors should be associated with (see
POD for details).
Each constraint has it's own defaults for these methods.
There's a new force_errors() method which can be set at the form-,
block-, element- or constraint-level.
It makes error messages be displayed, regardless of whether or not
there were input errors.
Forced errors are only returned by get_errors() if a true 'forced'
argument is supplied.
$form->get_errors({ forced => 1 });
Forced errors are ignored by has_errors(), valid() and submitted_and_valid().
When using the render object, field.errors is actually just a hash
key, so it returns both real and forced errors.
The MinMaxNeeded constraint has been renamed to MinMaxFields to make
its intent more clear.
It's also been changed so that by default, errors are only associated
with the base field.
You can restore the old behaviour by setting
attach_errors_to_others(1) in the constraint definition.
What might be a nice feature; though I'm not sure yet of an interface;
would be associating the error message with the base field, and
allowing the other fields to have a CSS error class set, but not an
error message. This would provide a visual prompt for where there
errors are, but not complicate things by needlessly repeating the same
error message more than once.
$form->render->field('foo')->as('text');
With the changes to constraints / errors now largely complete, I've
fixed field->as() so it once again correctly handles field errors.
Several of these additions to formfu have been with client-side
validation in mind, so...
The client-side/javascript constraint proof-of-concept has been updated:
http://www.fireartist.com/tmp/client-side-constraint.html
It demonstrates the use of filters, multiple constraints, and multiple
forms on a single page.
There's still some way to go until this is actually generated by
formfu, but the work is progressing :)
Carl
_______________________________________________
Html-widget mailing list
Html-widget@lists.rawmode.org
http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget
