Re: [Springframework-developer] MultiActionController & Validation

[Colin S. <co...@ex...>]

On 8/27/2006 10:38 PM, Tom Nichols wrote:
> Hi,  this is a post I originally sent to the springframework dev list,
> and I never heard anything back -- I don't know if I didn't send it
> correctly or what, but it appears that most of the action is on the
> 'user' list, so here's my original question:
>
> ---------------------------------------
> Hi spring devs --  I've got a suggestion that I'd like some help with.
>
> I'm using the MultiActionController's binding and validation
> capabilities (which by the way, I'd be glad to help document a
> little better...  )
>   
Help in this area is welcome. You could attach any doc patches to a JIRA 
issue.
> Anyway, I'm trying to use the 'lazy' implementation, where my action
> methods have the command object as the third parameter.  The problem
> is, if there are validation errors, an exception is thrown (when
> binder.closeNoCatch() is called on line 499 (rev 1.33).  The only way
> to handle validation errors are:
>
> 1.  Don't do it the lazy way, and manually do binding/ validation
> or
> 2.  override getExceptionHandler(Throwable exception) and create a
> custom Exception handler for a ServletRequestBindingException.
>
> Both of these could get tedious, so I'm wondering if we could make an
> extension point, maybe call it handleValidationError(...) and call it
> at the end of MultiActionController.bind(...) if there are validation
> errors.  The default implementation could then call
> binder.closeNoCatch(). (This all makes sense if you look @ the
> MultiActionController source code, BTW.)
>
> Then the problem becomes, when validation errors occur, we'd normally
> want to return to the previous view and display form errors....  That's
> where my idea fails, since we would want to be able to return a
> ModelAndView (and MultiActionController.bind(..) returns void.  Does
> anyone else see this as an opportunity for enhancement?  I was going
> to post an issue on JIRA, but I wanted to get others' input first.
>   
Fundamentally, the MultiActionController was never meant to be used with 
a form. It doesn't know anything about form lifecycles. Now it didn't 
really have to be this way; the current split is somewhat unfortunate, 
basically as far as I'm concerned, the whole hierarchy above but not 
including SimpleFormController could have supported multi-action and 
multi-command (binding to many objects) handling, while 
SimpleFormController could have limited that down to multi-action and 
single command (binding to the one form object). The current split where 
multi-action is in a separate hierarchy reflects the organic way those 
classes evolved.

That said, I think it would possibly be simpler for you to extend 
SimpleFormController, and delegate yourself to a multi action 
strategy... You would not then have to worry about reimplementing any of 
the form lifecycle stuff.

Colin

---
Colin Sampaleanu
Principal, Interface21
Spring Training, Consulting and Support - "From the Source"
http://www.interface21.com