On Sat, 26 Jul 2003, David Graham wrote:
Date: Sat, 26 Jul 2003 11:35:23 -0700 (PDT) From: David Graham <[EMAIL PROTECTED]> Reply-To: Struts Developers List <[EMAIL PROTECTED]>, [EMAIL PROTECTED] To: Struts Developers List <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: ActionServlet init parameters [WAS] Re: cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
What is the overall strategy for servlet parameters vs. struts-config <controller> attributes? We moved most of the init parameters to the <controller> element so I'm inclined to say that this should be defined there as well. Are there any reasons that it *must* be a servlet init parameter?
The informal policy I applied on the initial migration was "anything specific to a module goes into struts-config.xml, anything global to ActionServlet stays an init parameter." I think that rule still makes sense, but obviously it's worth reviewing.
I am **assuming** the configFactory and the implementing ModuleConfig implementation class could add more info
to the struts-config.xml. It seemed easier,
to specify that in the ActionServlet parameters. If a parameters were changed/added then a new DTD would need to
be registered with the digester, this seems like something you would want to do before processing of the
struts-config.xml. Thus the factory would need to be know before hand, or the struts-config.xml
would need to be processed twice. Once non validating, to pull off the
<struts-config className="org.apache.struts.config.impl.NewModuleConfigFactory">
</struts-config>
class info. That class would then register any new DTD and ConfigRuleSet() items.
Right now the ModuleConfig is just a container populated by
the rules setup in ConfigRuleSet().
Long term it might be useful to work towards a set of api's, so
the ModuleConfigImpl or some other class under impl class registered the DTD for the
struts-config.xml it needs.
-Rob
David
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Rob Leland
