Date: | Mon, 18 Jul 2005 13:13:14 -0500 |
From: | Mark Stosberg <mark [...] summersault.com> |
To: | Cees Hek <ceeshek [...] gmail.com> |
CC: | dfv list <cascade-dataform [...] lists.sourceforge.net> |
Subject: | Re: [dfv] Re: [cgiapp] name and 'err_' flags |
On Mon, Jul 18, 2005 at 01:35:08PM -0400, Cees Hek wrote:
Show quoted text
> Hi Michael,
>
> This is very similar to how I setup my error messages as well. I like
> them in the template, because I don't care what the message actually
> says, as that should be up to the designers.
>
> And I ran into the same issue as you with multiple constraints for a
> single parameter, so I ended up rolling my own solution that works
> pretty much exactly as C::A::P::VRM, except that it creates a
> multi-dimentional hash for multiple constraints. It usually looks
> something like this:
>
> errors => {
> invalid ={
> foo => 1
> bar => {
> length => 1,
> duplicate => 1,
> },
> },
> missing => {
> foobar => 1
> }
> };
>
> This structure works really easily with Template Toolkit because of
> the magic dot notation:
>
> [% IF errors.invalid.bar %]There was a problem with bar[% END %]
>
> or I can get more details about what was actually wrong with bar:
>
> [% IF errors.invalid.bar.duplicate %]That bar already exists[% END %]
>
> It is a subtle difference from the way DFV builds the structure, but
> it is enough that I can't use C::A::P::VRM. I've tried to come up
> with ways to patch CAP::VRM or DFV to overcome this, but I haven't
> thought of anything worthwhile.
I really like this (and I see it as a benefit to using TT).
I would to add something like this to DFV. I'll think more about this
might be possible.
Mark