[html-formfu] self.form.has_errors in TT templates

[Steffen Schwigon]

"Carl Franks" <fireartist at gmail.com> writes:
> On 16/01/2008, Steffen Schwigon <schwigon at webit.de> wrote:
>> Steffen Schwigon <schwigon at webit.de> writes:
>> > "Carl Franks" <fireartist at gmail.com> writes:
>> >> On 15/01/2008, Steffen Schwigon <schwigon at webit.de> wrote:
>> >>>   [% IF self.form.has_errors %]
>>
>> was not about "self.form" vs. "self", but about a seemingly
>> non-working "has_errors", which still does not contain the fields
>> with errors.
>
> Hmm, now that render() returns a string, rather than an object -
> within the templates you only have access to the hashref returned by
> render_data(), so there's no longer an object that you can call form
> methods on.
>
> Although there's tests for doing things within your own templates
> other than [% form.render %], I hadn't really thought of the
> consequences of the lack of a render object for customization within
> the actual core templates.
>
> In the short term, I would suggest you use the same test that the
> start_form template does:
>     [% IF self.form_error_message.defined %]

This workaround works for me. Thanks.


> There are probably 2 ways to fix this:
>
> 1)
> We could provide the original form object through something such as
>     [% self.object %]
> this would let you do
>     [% self.object.has_errors %]
> (we'd also be best providing an {object} hash-key for all elements too).
>
> I can't think of a better name than 'object' - any ideas?
> 'source' is too close to 'src' which is already used by the Image
> element.

"object" sounds correct and ok for me.


> 2)
> When we're building render_data, set some more values taken from the
> original form object:
>     $render->{has_errors} = 1 if $form->has_errors;
>
> There are a few problems with this though:
> People might confuse it with the form method, and try something like
>     [% self.has_errors('foo') %]
> which will not work.
>
> Maintenance - more things to keep in sync.
>
> Efficiency - have to call a lot of methods regardless of whether their
> values will be used.
>
> So... I'll probably look at all the form methods now, and think about
> whether option 2) would be at all desirable, and so maybe narrow down
> my options - and in the meantime, maybe someone else will have a
> bright idea :)

I vote for option 1). It seems that would be the easiest way to
provide and additionally a correct and most generic one. It gives
templates the same abilities that are available in Perl code
(eg. controllers).

GreetinX
Steffen 
-- 
Steffen Schwigon <schwigon at webit.de>
Dresden Perl Mongers <http://dresden-pm.org/>
Deutscher Perl-Workshop <http://www.perl-workshop.de/>