cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: Adding a global validation message to a form?
Date Tue, 01 Jun 2004 21:43:15 GMT
On Tue, 2004-06-01 at 23:02, Joerg Heinicke wrote:
> On 29.05.2004 11:14, Bruno Dumon wrote:
> 
> >>Moving this to dev list. Find the original thread at 
> >>http://marc.theaimsgroup.com/?t=108559109700004&r=1&w=4.
> 
> >>>I'm not sure if this is a good
> >>>solution, since those messages are not specifically recognized as being
> >>>validation errors, and so this wouldn't work together with
> >>>fi:validation-errors. Maybe the best would be to allow adding validation
> >>>errors (multiple ones) on the form itself.
> >>
> >>The form itself becomes ValidationErrorAware? I searched for it when 
> >>thinking about a solution, but unfortunately the form is not 
> >>implementing the interface.
> > 
> > 
> > No, I would rather have a method like addValidationError on the form,
> > not setValidationError. One global validation error message seems to
> > limitting to me.
> 
> I agree.
> 
> >>>fi:validation-errors would
> >>>then better be replaced with a ft:validation-errors (which can crawl the
> >>>widget tree), since otherwise it wouldn't find the errors attached to
> >>>the form.
> >>
> >>Hmm, I guess it is also possible to add a fi:validation-message to the 
> >>form widget as it is done for all other widgets. It must be possible to 
> >>differ between form widget (= global) validation errors, collected 
> >>"somewhere" and widget specific errors. In other words I do not want to 
> >>be forced to collect all errors at one place just because of using 
> >>ft:validation-errors for the global errors.
> > 
> > This behaviour could be made configurable via an attribute on the
> > element:
> > 
> > <ft:form-errors all="true|false"/>
> 
> fi:validation-errors vs. ft:form-errors - was this renaming intended?

yes, since this tag would retrieve the errors of the form, which can be
multiple ones, and have the extra functionality of the 'all' attribute.
However, maybe this kind of functionality would potentially be useful
for all types of container widgets. Need to think some more about it.

> 
> > all=false would give only the errors added directly to the form, while
> > all=true would give all errors from all widgets (including those added
> > to the form).
> > 
> > Once we have this kind of functionality, we can drop the fd:messages
> > widget which was introduced as a temporary solution.
> > 
> > OTOH, from monitoring the users list, it seems a fd:message widget
> > (singular) would be useful since many users are now using the fd:output
> > widget for outputting messages (and then need to do special things to
> > get i18n working for that).
> 
> Hmm, not every form message must be necessarily an error, maybe they are 
> just info (without the need for a failing validation). So we need a 
> mixture of fd:message and the described functionality for the form 
> itself. Maybe even this makes the fd:message not superfluous because the 
> messages can be placed more fine-grained with it.

you mean fd:messages ? (with the 's')

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message