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

[Carl Franks]

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:
> >>> However, I'm somehow unable to find the replacement of something I did
> >>> before:
> >>>
> >>>   [% IF self.form.has_errors %]
> >>>   ...
> >>
> >> It's fixed now
> >
> >> - it's not strictly necessary because "self" in the
> >> form template is the form, so "self.form" is a bit redundant - but
> >> anyway, I've fixed it in svn so it'll work.
>
> Damn :-), in the meantime I tried svn version. Now I see my problem
> 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 %]

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.

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 :)

Carl