BaseCommandController or MultiActionController?

[pedrodx]

Hi all!! First of all, I didn't know where to post this topic, if was here or in the web forum, but, let's go!!

I have a form with several actions and so, a MultiActionController to handle multiple actions to it.....

But the deal is that I need to register a custom property editor for a property of type Long (detail: in three properties of type Long, there are three dropdowns with the same name that generate a string list separated by comma, if you have a suggestion......) in the DataBinder.... so I need to override the initBinder method..... that's why I need to subclass BaseCommandController....... or not??

Any help is much appreciated!!

[Colin Sampaleanu]

You've got a few options I guess. One would be to add and use your own MethodNameResolver in a subclass of BaseCommandController, forgoing MultiActioController. You'd have to duplicate some of the behaviour, but would gain in terms of things like the form lifecycle support in classes like AbstractFormController.

(Note that I've actually just checked in an enhanced ParameterMethodNameResolver for Spring 1.2 so it can handle some other variations of method resolution, the main intent being to handle the multi-submit button case better).

Alternately, you could just subclass MultiActionController and override bind(...), calling your own implementation of initBinder there.

I'm actually going to add an initBinder() method in that class (which will be there for 1.2), can't see why it was never added.

[Colin Sampaleanu]

There are now (in CVS) createBinder() and initBinder() methods in MultiActionControlller...

[Alef Arendsen]

Dude, you're *too* fast ... I was just about to add this .

regards,
Alef

[yfmoan]

Hi , since there is a command in MultiActionController , why there is no validator inside ?

moon

[carlos_santiago]

Good question !!!

[Colin Sampaleanu]

I've added the ability to set an array of Validators in MultiActionController.

So the current sequence is that the method that is being (dynamically) dispatched to is examined to see if the last param is a command object type. If so, the command object is created, and params are bound. If there are any validators, then the list of validators is iterated through, and each validator that indicates it supports the command object type is asked to validate it.

This code is now in CVS and should be in Spring 1.2.4, coming out next week.

[jnizet]

I've added the ability to set an array of Validators in MultiActionController.

So the current sequence is that the method that is being (dynamically) dispatched to is examined to see if the last param is a command object type. If so, the command object is created, and params are bound. If there are any validators, then the list of validators is iterated through, and each validator that indicates it supports the command object type is asked to validate it.

To me, who have a strong Struts background, a MultiActionController is primarily useful to be able to place different actions in the same class, but all using the same command class. So this way of validating seems a bit unuseful. We should be able to specify a validator (or a list of validators) per method.
For example, I would like to code all the CRUD operations of a given business object in the same class. Obviously, the read, delete, create and update methods don't need the same validation.
Another thing that bothers me is the lack of support for errors in the MultiActionController. Why can't the binding errors be passed as an argument to the methods, as in the SimpleFormController methods? Why are the bind and validation errors discarded by the bind method? How can a method inspect validation errors and build a ModelAndView based on the presence of errors, and containing the errors?

JB.

[Colin Sampaleanu]

The MultiActionController has always been seen as a way of handling multiple actions for non-form scenarios. It's often used to handle actions even without a command object, and where the command object exists, the expecation is that the data is not coming from a form (so that it makes sense to send the user back to that form), but rather as a way to gather together and convert some of that data. And now to provide some way of validating too.

If you only have one command object, then I would normally work off the SimpleFormController. You can override the
onSubmit(Object command, BindException errors)
method, and dispatch yourself to the appropriate handler method. You can still use a MethodNameResolver to do this for you, just inject a property of type MethodNameResolver, and in the onSubmit, get it to do the method invocation, same as done by the handleRequestInternal method in MultiActionController. Now it's true that you can not register multiple validators for different scenarios for the same command object in this case, but to tell you the truth I'm not sure I see the value proposition there most of the time. An external Validator class implies some basic validity check for an object type, that can be shared over and over. In this case, where each method implies a different sort of validity check needed, it seems like there is not much chance for reuse, and I would just do the validation in the methods themselves.

Now all this said, if there was ever the chance to rework the whole Spring controller hierarchy, I would definitely make the whole hierarchy multi-action, all the way down to the form controller, with single-action being just a simple subset, and I would make everything above the form controller (but not the form controller) multi-command as well...

Regards,

[jnizet]

I must be biased by my Struts background, but in fact, after playing a little bit with Struts MVC, I've realized that I always use a form controller, even for the simplest case where the data comes from parameters in a simple link, and where there is no form, no validation and no form view. The reason for this is that I like my data to be bound automatically, and found in a command object, with the right type, rather than in the request, as Strings.
Playing with the validators, the bindOnNewForm property and the isFormSubmission method, I make Spring work as I like it to work. The only exception is the MultiActionController, which doesn't make it easy to work as a Struts DispatchAction. Nothing blocking, though. I just have to implement the dispatching by myself in a SimpleFormController.

JB.