[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Adding a global validation message to a form?
From:       Bruno Dumon <bruno () outerthought ! org>
Date:       2004-05-29 12:51:02
Message-ID: 1085835062.7991.62.camel () yum
[Download RAW message or body]

On Sat, 2004-05-29 at 13:13, Upayavira wrote:
> Bruno Dumon wrote:
> 
> >On Fri, 2004-05-28 at 23:58, Joerg Heinicke wrote:
> >  
> >
> >>Moving this to dev list. Find the original thread at 
> >>http://marc.theaimsgroup.com/?t=108559109700004&r=1&w=4.
> >>
> >>On 28.05.2004 20:13, Bruno Dumon wrote:
> >>
> >>    
> >>
> >>>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.
> >  
> >
> At the mo  only want one message but I can see times when multiples 
> might be wanted. So +1 for addValidationError
> 
> >>So +1.
> >>
> >>    
> >>
> >>>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"/>
> >
> >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).
> >  
> >
> Sounds very useful.
> 
> >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).
> >  
> >
> +1 from me! Except I wouldn't know where to start to implement it!

Just open the class Form, add an instance member to it to hold the list
of validation errors, add addValidationError(...) and
getValidationErrors() methods.

Then on the template side, open the EffectWidgetReplacingPipe, react to
the ft:form-errors element, and do what needs to be done (ie call
getValidationErrors on the form object and stream some sax events for
them). You can skip the all=true case for now if you don't need it, but
it shouldn't be too hard either.

But I'd wait a day or two in case anybody finds the above a bad idea.

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

[prev in list] [next in list] [prev in thread] [next in thread]