cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Adding a global validation message to a form?
Date Tue, 01 Jun 2004 21:02:47 GMT
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?

> 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.

Joerg

Mime
View raw message