The point I was trying to make is that using "command" and "catalog"
to look up a per-action-path command to execute should leave Struts
out of any concern for the lifecycle of the Command classes; the
implication of those attributes is that the command will be looked up
from a CatalogFactory, and it's not up to Struts how that
CatalogFactory manages its commands. Those are concerns for
commons-chain.
Re the singleton issue: I think you suggest to override the "bridge"
ExecuteCommand class that will do singleton/non-singleton based on
an input parameter that could be specified in ActionMapping.
Flipping out old ExecuteCommand is a cinch with 1.3 struts-chain.xml
Yes, this is more or less what I have in mind. I would probably use
the arbitrary config property feature new in Struts 1.3 to set a
property on an ActionConfig, and then have ExecuteCommand or another
command look at that property for a potential class name. If it
found one, it would instantiate the class and cast it to Command, and
then execute it with the active ActionContext.
I'm just not sure that I believe this belongs in Struts right now.
Struts 1.3 is setting up to be so flexible that it would be possible
to throw a million different ways of doing things into the core, and
I think that would just confuse things; however, I believe that its
flexibility is such that users who want that kind of behavior will
find it extremely simple to implement it themselves. For now I think
we should let that kind of experimentation go on amongst users and
watch for a while to see which solutions really catch on. I'm
particularly hesitant to go adding new details to the DTD while
things are so fluid and subject to change, but again, those arbitrary
config properties mean that we don't have to.
What we should do in the Struts core is make sure that things are
properly designed for easy extensibility. In this case,
ExecuteCommand has a protected getCommand(ActionContext) method which
provides a good place for this kind of customization, roughly as such:
// override base impl
protected Command getCommand(ActionContext ctx) {
String type = context.getActionConfig().getProperty("COMMAND_CLASS_NAME");
if (type == null) return super.getCommand(ctx);
return (Command) ClassUtils.getApplicationInstance(type);
}
I encourage you and lots of other Struts 1.3 explorers to go off and
do things this. Where Struts 1.3 will need to be bolstered is not in
making a lot of specific changes to the core command set, but rather
in finding where Struts 1.3 makes doing this yourself harder than it
should be. It looks like this one is good, but perhaps some other
commands could be refactored to better expose specific behavior as
extension points, and I suspect over time people will become a bit
annoyed at manually maintaining a chain-config.xml which diverges
from the Struts base distribution. I'm sure there will be other
things that I haven't even thought of, and I'm really excited that
people are starting to build 1.3 apps and will be providing more
real-world feedback about it. We've got three in production right
now and more on the way, but they are all designed in basically the
same way, so I'm looking forward to seeing where other people go with
it.
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]
