This is essentially the standard approach. Your code leaves out the
possibility that the form already exists (and that it may be in the
session scope). This may be practical for your cases, but might lead
to confusion should someone change part of the flow in your
application.
In Struts 1.3, there are actually a few places where this basic
operation (check a scope for existing form, if not found, create it
and place in scope, and return either pre-existing or new form) are
done. I haven't seen a path to encapsulate it into one single
operation, although I haven't actually thought about it for quite a
while; it could probably just be put into a static util method on
some class, but I was sort of down on static util methods for a while.
Anyway, Struts does this for you in the CreateActionForm class. This
isn't appropriate to prepopulation, though. If you want to do it
yourself, there are two ways to get at it, but both involve newer
features of Struts 1.3.
First, and probably best, would be to use the CopyFormToContext
command as part of a chain of commands; it can actually do the lookup
so that all you have to specify is the path of the destination action
and it will look up the form name and scope, much as <html:form>
does. This provides for clean configuration. You can make a chain
which uses this command and then has a subsequent command retrieve
the form from the context and do the population.
This behavior is also implemented in the ActionContextBase class, in
the method findOrCreateActionForm(String formName, String scopeName).
This method is not part of the ActionContext interface. Perhaps it
should be, but I thought it best to figure out a way to put this code
in one place rather than three before adding it to the interface.
Still, if you have an ActionContext instance which inherits from
ActionContextBase then you can cast and use the method. However, at
this time a typical Struts Action class does not have a reference to
an ActionContext object; we have not yet committed to changing the
Action interface to receive one, and we haven't yet settled on a
potential place to offer static access to a ThreadLocal which might
store the ActionContext, although I'm using this basic pattern in a
custom implementation of ActionContext and finding it workable, and
there was some interest in having this last time it came up on the
dev list.
I've seen people using the "input" attribute point to an prepopulate
action?
the "input" attribute is only used when form validation fails. In
some approaches, some page prep needs to happen here, although what I
usually consider "prepopulation" (seeding with persistent values) is
not relevant because the form should be refilled with whatever was
submitted in the HTTP request. However, if you have dynamic menus or
other form elements, of course you need to arrange for those to be
restored.
Hope this helps,
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
