I'm not keen on adding init params in general, and even less keen on
adding such params that take lists of files.
I do think we need to have a mechanism for specifying global stuff,
but I think we can come up with a better way. For example, I don't
like that I have to replicate the <controller> config in each module's
struts-config.xml in a multi-module app. That's error prone.
We've talked about allowing for <extend> for things like form bean
definitions. What about having this concept right at the top of the
config scheme? So I could define a global struts-config.xml file
(which wouldn't be used directly by any module), and then <extend>
that file to provide module-specific config files.
If we added an optional section to struts-config, we could then
specify a list of Chain config files in there.
I would suggest skipping the chainConfig and chainCommand parameters
in the web.xml in favor of explicitly setting them in each
controller. Too many config options can be more trouble than they
are worth.
+1
The discussion of how to configure the Controller or the
RequestProcessor touched off a lot of talk earlier on struts-dev, but
I'd be happy to settle for two properties on ControllerConfig just to
move forward.
struts-config.xml
- The default request processor class would now be
ComposableRequestProcessor, but the legacy ones would still be available
(deprecated)
+1. One thing that I'm a little confused about, though, is that the
new request processor is (currently) in a package that includes
'legacy'. Anyone know why that is?
I don't know, but I think we should move it out to
o.a.s.chain.ComposableRequestProcessor.
Fine with me.
- The controller would have additional optional attributes:
I think the controller should simply have optional command and
catalog attributes which would be used like this:
CatalogFactory.getCatalog(catalog).getCommand(command)
if no catalog is specified, the "default" catalog is retrieved with
getCatalog(). If no command is specified, then these default values
would be used:
catalog = struts
command = servlet-complete
I believe that's what's in place now.
If catalog were specified without a command, an exception would be thrown.
I am still inclined to package most of what is now struts-chain
separately from the core.
I'm not so sure I agree here. Most, if not all, of the commands you
list below are used by the chain that you suggest as a default above.
I think if we want the ComposableRequestProcessor to be the default
for 1.3, we really need to keep the commands in the core as well.
However, I do think they should be pushed into a separate package.
Just as we have o.a.s.actions, we could have o.a.s.chain.commands for
these.
--
Martin Cooper
This may be part of why I haven't moved as
quickly. Here are all the classes in struts-chain:
org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn
becomes obsolete
org.apache.struts.chain.legacy.TilesPlugin
can be made obsolete if we remove the check in the base TilesPlugin
which insists on a specific request processor. I don't see any
reason not to do that.
org.apache.struts.chain.legacy.ComposableRequestProcessor
org.apache.struts.chain.legacy.DispatchAction
org.apache.struts.chain.legacy.ChainAction
Move these three to core and up to o.a.s.chain
org.apache.struts.chain.AbstractAuthorizeAction
org.apache.struts.chain.AbstractExceptionHandler
org.apache.struts.chain.AbstractExecuteAction
org.apache.struts.chain.AbstractPerformForward
org.apache.struts.chain.AbstractPerformInclude
org.apache.struts.chain.AbstractPopulateActionForm
org.apache.struts.chain.AbstractRequestNoCache
org.apache.struts.chain.AbstractSelectAction
org.apache.struts.chain.AbstractSelectForward
org.apache.struts.chain.AbstractSelectInput
org.apache.struts.chain.AbstractSelectLocale
org.apache.struts.chain.AbstractSelectModule
org.apache.struts.chain.AbstractSetContentType
org.apache.struts.chain.AbstractValidateActionForm
org.apache.struts.chain.Constants
org.apache.struts.chain.CreateAction
org.apache.struts.chain.CreateActionForm
org.apache.struts.chain.ExceptionCatcher
org.apache.struts.chain.SelectInclude
org.apache.struts.chain.UnauthorizedActionException
org.apache.struts.chain.util.ClassUtils
org.apache.struts.chain.servlet.AuthorizeAction
org.apache.struts.chain.servlet.ExceptionHandler
org.apache.struts.chain.servlet.ExecuteAction
org.apache.struts.chain.servlet.PerformForward
org.apache.struts.chain.servlet.PerformInclude
org.apache.struts.chain.servlet.PopulateActionForm
org.apache.struts.chain.servlet.RequestNoCache
org.apache.struts.chain.servlet.SelectAction
org.apache.struts.chain.servlet.SelectForward
org.apache.struts.chain.servlet.SelectInput
org.apache.struts.chain.servlet.SelectLocale
org.apache.struts.chain.servlet.SelectModule
org.apache.struts.chain.servlet.SetContentType
org.apache.struts.chain.servlet.TilesPreProcessor
org.apache.struts.chain.servlet.ValidateActionForm
Move all of these to a Struts TLP like "legacy-chain" or perhaps just
"struts-chain". I wasn't involved in the initial implementation, but
I don't think these are something that belongs in the core. They
work fine, but I think the Abstract classes are over-engineered.
Also, I think we should move towards actions which operate on a
StrutsContext or ActionContext rather than having such a highly
configurable mechanism for looking up context-relevant objects (like
ActionMapping and ActionForward). I think the config for setting
context keys for each important object is an example of over
abstraction which make these harder to understand. This TLP would
also include a default chain-config which works with this set of
classes in the JAR.
Is there a compelling reason to put specific command implementations
in the core? I kind of feel like it would be nice to feel less bound
to them.
If we do this repackaging, perhaps it would make sense to change the
Java package for these classes. I don't have a strong opinion.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
