Brian Kirkbride wrote:
...
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
This is pretty much what I do via the FormValidator. I convert the
'missing' or the 'invalid' messages that it produces into the flags
[% missing.user_username %]
and
[% invalid.user_username.length %]
which then result in the error messages being produced.
I still need to give some thought to internationalisation, but that is
another question. :)
_______________________________________________
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/
