On Tue, Oct 23, 2007 at 01:27:17PM -0400, John Siracusa wrote:
> OTOH, the server often needs the labels in order to construct good
> error messages. An alternative is to pass error codes to the
> templates, but IME that tends to result in templates with a lot of
> code dedicated to figuring out which of several dozen error messages
> should be displayed based on the error code passed.
Do you to be able to display the error message along with the field's
lable? For example:
Please correct the "Email" field.
Error: input doesn't look like an email address
My form templates look like this:
[% WRAPPER form_wrapper %]
<fieldset>
<legend>User Info</legend>
[%
field('First Name', 'first_name' );
field('Last Name', 'last_name' );
field('Email', 'email' );
field('Timezone', 'timezone' );
field('Is user active?', 'is_active' );
field('Is user an admin?', 'is_admin' );
field('User Roles', 'roles' );
%]
</fieldset>
[% END %]
The field() macro is generating (and localizing) the field's label and
the html widget. It also displays and field errors.
It also sets the field's label in the field object. It does that so
when the wrapper, eh, wraps the form the field label is now known and
can be displayed with the summary of error messages as above.
> But just passing a code is rarely sufficient, since good error
> messages will have more request-specific information in them (e.g.,
> "Could not delete the 'Foo' group because it still has 9 members.") so
> an error object or structure of some kind is required.
Is that a form validation error? Could be. But to your point a
validation error can't easily be localized outside of the form
processing (need to know what text can be localized and which can't).
So one option is to pass out error messages as a list:
[
'Could not delete the '[_1]' group because it still has [_2] members.',
$group_name,
$current_count,
]
but then that's depending on the extern code to know how to localize.
So, I opted to pass into my form object a Locale::Maketext language
handle from Catalyst, which of course is what knows what language to
use for that request.
BTW -- Another reason why I don't think YAML is much help is I'm not
sure how I might use YAML to do complex validation and generate a
message like above.
> What's returned from $field->error is actually an object
> that knows how to stringify itself based on the error id, parameters,
> and current locale. All the actual Perl code deals only with message
> ids, never strings, and all the templates do is stringify the objects
> they're passed.
That's probably a better approach.
> So, in the end, all the actual message text ends up not in the Perl
> code or the templates, but in the big localized strings file or
> whatever you're using for managing your localized messages.
Yep, although I prefer to use English as the key to the language files
instead of an ID. Easier to understand when looking at specific
validation code. I can also fall back to using the ID (the English
error message) if the lookup fails in the language file.
--
Bill Moseley
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
