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
