[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