Rick Reumann wrote:
The key thing to remember is that in Struts, ActionForm is part of the *view* tier, not part of the *model*. It only exists to provide Struts a place to store the server side representation of the input data in your fields.Bill Siggelkow wrote:
Good point, Rick. Isn't this the sort of thing that JSF allows?
Not sure haven't looked at JSF yet:) Plan to at some point. Craig?
Of course, you can bind a validation to an action mapping using the ValidatorActionForm -- however this still forces your business objects to extend this form and it doesn't solve the populate problem.
Well, I'm actually not talking about binding the validation to a "form" or any bean but binding it to a mapping. The framework then will look at the basic request parameters and validate them based on some configuration for the mapping and of course return back to the user any errors. It never gets to the population of the bean (POJO/VO whatever) until after validation succeeds. Of course you could still get an ugly conversion error there if you don't validate properly but that's the case with any system. At least with the above approach you aren't tied to having to rely on an ActionForm simply for validation purposes.
As far as the problem of migrating deeply nested VOs to Action Forms -- we have the same issues on the app that I am working on -- I feel your pain ;)
Yea, annoying - especially if you have to validate stuff that is nested:)
Validation was one of the motivations for this design, but not the key one. The primary motivation was to meet a user expectation that, when they make a mistake, the form will be redisplayed with exactly what they typed into the field, even if it was wrong. For example, if you have an integer field, and I type "1a3" instead of "123", I expect to see an error message and what I originally typed (1a3) there for me to fix. This is the reason you need string fields -- that's where Struts puts the originally typed value, so it can be redisplayed.
JSF does indeed avoid the need for an ActionForm like structure, because all the state saving and conversion logic is buried inside the component itself. If you use a value binding expression to tie the value of the component directly to a model bean property, you don't even have to worry about defining what conversion to use; the binding machinery will take care of it for you.
With JSF, I see three different idioms for hooking input fields to data objects becoming popular, depending on your background and preferences:
* Bind component values to model bean properties, and have event handlers in separate classes (since conversion errors are handled for you, the model bean can use native data types).
* Bind component values to backing bean properties, and have the corresponding event handlers in the same class (sort of an ActionForm + Action combined, similar to what WebWorks does).
* Instead of binding component values to bean properties, bind components themselves (using the "binding" attribute), which makes it easy to programmatically modify component properties (similar to what ASP.Net does if you use code behind pages).
All three models are reasonable, and are not mutually exclusive within the same application.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
