[Catalyst] Where should constraints go
Brian Kirkbride
brian.kirkbride at deeperbydesign.com
Fri Nov 3 18:37:54 GMT 2006
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
More information about the Catalyst
mailing list