If I want to use Spring I use Spring MVC, but I think a lot of drive in
Struts evolution is to encorporate nice ideas that have come up as
techniques elswhere over the last years, see Struts TI. So Struts
developers won't *have to* use Spring on top or instead. (I am not
convinced that TI should use/depend on Spring).
I think CoR with Chains is great and simple for declaratively linking
things as of Struts 1.3. I also think CoR is a more beautiful pattern
than IoC for a lot of people. I also think there is a great bang in
using the execute(context) interface rather than execute(mapping, req,
res etc). I have written commands rather than actions for 8 months now
and I don't miss old actions a bit.
I still like the behavior of a class inside the class. When you have an
execute hook you probably need less understanding of the class
implementation and how possibly inject stuff otherwise. At least not
YACF (yet another config file) - cf. Ruby on Rails. Also think of
.execute(context) as an entry comparable to a main method.
If I need to create an adapter class to run particular logic, I could do
that with plain old actions.
There may still be cases where IoC is really needed, but with Struts 1.3
as tool I just I don't come across them that often.
Another advantage of using the command interface is if I find that some
command is generic to an application I can add them to the defautl
struts chain, rather than wiring through a custom base-command class.
Which really leverages the new chain architecture of Struts! Finally we
can change the default behavior of the Struts cycle. It has the
potential to wire stuff for all kinds of apps, including remote. Now
that's a great bang!
Could you imagine having rewritten the struts request processor with
spring IOC?
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
Or add that as a feature as in a type="[EMAIL PROTECTED]"
attribute. Right now I think "instance" should be the default attribute.
From the experience that non-thread-save classic Actions are a typical
newbie error, which can lead to catastrophic behavior of the application.
Wolfgang
Joe Germuska wrote:
I've recently been designing applications so that per-action-path
commands are retrieved from Spring rather than from the default
commons-chain CatalogFactory. This then makes the lifecycle of the
command an external property (based on the "singleton" attribute of a
<bean> element in a Spring beans XML file.)
Of course this required custom request processing commands, since
Struts 1.3 doesn't have direct dependencies upon Spring.
More to the point, though, I don't think there's really that much
"wow" to saying that Chain can "execute any arbitrary class" -- even
"executing a class" implies that the class implements Command, and
then its not arbitrary any more.
The best thing I think would be to write a command which instantiated
this other arbitrary class, extracting properties from the Context to
pass to the "main" method of the arbitrary class and interpreting the
return appropriately (possibly modifying the Context as well.)
This is basically how the Chain deals with Struts Actions right now;
it's an unimportant detail that the Struts Actions are pooled and not
created each time, but the point is that rather than modifying Action
to implement Command,we wrote a bridge Command. If your arbitrary
class isn't threadsafe, rather than modifying that arbitrary class to
implement Command you should write a complementary Command which knows
how to use that class in a threadsafe manner.
Make sense?
Joe
At 9:49 AM +0200 9/23/05, Wolfgang Gehner wrote:
Hi there,
I keep telling people that 1.3 allows out of the box to execute ANY
ARBITRARY CLASS via command=, catalog= and chain-config, as long as
it implements the command interface. If those classes have to be
tread-safe, like old actions had to be, that is not entirely true.
Any idea how to configure non-thread-safe commands (i.e. that have
instance variables outside methods) in Struts 1.3, even if they are
not perfect commands (Commons-chain says that catalog.getCommand will
reuse instances).
How about overriding ExecuteCommand to create new instances if some
action-mapping parameter is present, and how to (a question to
commons-chain).
That should also be made VERY evident in the Docs.
We are just deploying a 400 screens application we wrote on Struts
1.3, and it works great! of course our commands are all thread-safe.
Kind regards,
Wolfgang Gehner
---------------------------------------------------------------------
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]
