Ian Beaumont wrote:
> Wouldn't it make more sense to have a pre-initialisation action on the
> action that is actually connected to the form. This pre-initialisation
> would then populate the form.
Many forms are initialized differently for different purposes. One way
for a new record, another way to update a record. So we'd need a way to
resolve that too. (Though, I suppose it could go into the
ActionMapping.)
Personally, my concern with a separate initializer is that it would be
called from the presentation layer. It's usually better to keep any
calls that might go up to the model in the controller layer, otherwise
things start to get away from you.
We'd also be turning things around a bit. Right now, the idea is that
the controller assembles all the data and hands it to the view as a
thing accomplished, and all the view has to do is display it. With a
form initializer, we're muddling the seperation of concerns, and now
saying that forms should populate themselves. IMHO, that's a step back
towards Model 1, and contrary to why Struts was created in the first
place.
I know some developers really like to do that sort of thing, but it goes
against the grain of the architecture.
> This would also sort out the problem that I've seen posted about how you
> would populate multiple forms on one page.
The ActionForm will kindly create one ActionForm bean for you, but you
can create as many as you like on your own. Given the ActionForm name
from the Struts config, you can just call new, and set it as a request
attribute under than name. If you would like to do it by the name of the
ActionMapping, here's a utility method that would help with that:
protected ActionForm createActionForm(String path) {
ActionMapping mapping = findMapping(path);
String name = mapping.getName();
ActionForm form = null;
ActionFormBean formBean = findFormBean(name);
if (formBean != null) {
String className = null;
className = formBean.getType();
try {
Class clazz = Class.forName(className);
form = (ActionForm) clazz.newInstance();
} catch (Throwable t) {
form = null;
}
}
return form;
}
You can also use coarsely-grained ActionForm beans that have properties
for all the forms in your application, and just reveal whichever are
appropriate for a given ActionMapping. This can qlso simplify the
casting and whatnot. The downside is that you have to be more careful
with the validation, and look at which ActionMapping is in use to decide
which fields to validation (or skip the form validation and do it all in
the Action).
-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services
> I'm sure there is a reason why it doesn't work like this, but I can't see
> it.
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
