On 10/23/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> 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:
Was that supposed to say, "do you want to be able to"? If so, then
yes, and I can :) I have my own set of macro-like thingies ("escapes"
in Mason parlance) similar to yours. An example can be found here:
http://lists.scsys.co.uk/pipermail/catalyst/2006-November/010251.html
I tend to keep the field and label separate because the HTML designers
like to put them in separate places in the markup, but they could just
as easily be combined. (The error message (if any) is combined with
the field output in that example; it appears below the field it
belongs to.)
The difference in our approaches is that there's no English text in my
Perl code or in the templates for my forms, just field names and
(occasionally) message ids.
>> 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.
Doesn't matter, really. It could come from any code.
> 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.
Wrap that in an object and link it to a localizer and you have an
RHTMLO localized message object, more or less.
> 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.
Yeah, I just tend to use YAML for really simple configuration, not
complex validation specs that may require loops, conditionals,
awareness of the environment, etc. The bottom line is that you'll
always need validation code in the app itself (if only for cross-field
validation), so trying to get it all into YAML is doomed to failure.
>> 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.
We have quite the existing translation system here at work (all our
business is overseas and we do 16 different languages), and using
English as the key is pretty much a non-starter in our system. (It
also makes it a bit harder to change the English text.)
> I can also fall back to using the ID (the English
> error message) if the lookup fails in the language file.
I implemented that in the localizer object itself: ask for message id
123 in locale de and it'll look for de, and return you en if it can't
find it. (Actually, it's a cascade of fallback languages, but in
practice we usually just default to en.)
-John
-------------------------------------------------------------------------
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
