Craig R. McClanahan wrote:
> * The number of different forms and actions implies that there is a
reasonably
> large number of Java classes in the overall design (usually at least one
per
> form plus one per action). In the cases where Struts manages things, it
> strives to use just one instance, as in the case of actions, to avoid
object
> creation and garbage collection overhead. You have the opportunity to
do
> this as well, because your ActionMapping implementations include a
factory
> method to "create" form bean instances.
I was aware of the single instance actions. I guess I missed the ability to
do my own thing with form beans. Thanks for pointing that out.
> * Large numbers of actions mean large numbers of "names" for those
actions,
> which the servlet container has to know about. My general
recommendation
> is to use a single mapping for the controller servlet -- either a path
map (i.e.
> "/do/*") or an extension map ("*.do"), with the "*" part replaced by the
logical
> names of the actions. Adding new actions requires no changes to the
> web.xml file.
Yes, following your example, extension mapping would be my preferred
approach.
> * All of the actions for all aspects of your application are ultimately
configured
> by a single "action.xml" file, which can be problematic when you have
different
> developers doing the different portions of the app. One way to deal
with this is
> to have each functional area of the app provide a portion of the
ultimate
> "action.xml" file -- the actions relavant to that functional area -- and
assemble
> them together when building the app.
This is largely where my concerns arise. I have been trying to figure out a
way to partition the application space so that I could avoid one central
resource that everyone needs to modify. For some reason, creating the
action.xml file dynamically had not occurred to me. Sometimes I feel
incredibly dumb...
> * The internal mechanics of the controller servlet are available to your
> actions for runtime modification. For instance, it would be relatively
easy to
> build an action that added a new action mapping on the fly, or changed
the
> name of an action class being used by a different mapipng. Thus, there
is a
> set of configurable things that can be changed dynamically, without
having to
> restart the entire application.
This is a very interesting idea. I'm not sure that it would be useful in my
current scenario, but it certainly gives me some interesting possibilities
to think about.
> * We've been talking so far in the context of a single web application to
handle
> your entire functional needs. It may also be reasonable to look at
segragating
> the functionality into multiple web applications (although you'd need to
keep
> several things in mind at design time, like the fact that sessions do
not cross
> web app boundaries).
Multiple web apps is not an option for me.
--
Martin Cooper
Tumbleweed Communications
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
