Rodney Broom wrote:
I don't have the communication from layer to layer all worked out, but an
approach I've liked is to have errors (like constraint failures) communicated
with standard message identifiers and know data. For instance, failing length
of 'username' could propogate a message ID of ERR_USERNAME_LENGTH, and
include data in a list: [1, 16]. From there, the view would be able to pull
messaging based on language or other criteria and flesh it out with the data.
In TT, maybe something like:
[% IF field.messages %] [% FOR m = field.messages %] [% sprintf(
get_text(m.id), @{m.data} ) %] [% END %] [% END %]
The English message for ERR_USERNAME_LENGTH might be:
Must be between %u and %u characters
This is the approach I have taken in the past, although I hadn't included any
metadata (ie [1,16]) with the error_id. This fits into separation of business
and presentation logic nicely because the model is free to return an error that
has some semantic meaning "PASSWORD_TOO_SHORT", but the view is free to say
"Enter a longer password you submoron, you!" if need be.
For my Catalyst apps, I can either do something like:
[% c.format_error(error_id) %]
or
[% error_messages.$error_id %]
or even
[% error_messages.${lang}.${error_id} %]
to map the model-specified error to a presentable string for the view. I prefer
the first, but it does clutter the Application Context namespace somewhat.
Best,
Brian Kirkbride
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
