On 6/28/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Michael Jouravlev wrote:
> Do you mean by building DispatchCommand or DialogCommand? And then
> slapping this command onto the chain... but I can replace Action as
> well. Oh I see, Action is not an interface, but Command is. Always
> keep forgetting this. I will think about it. Thanks!
Pretty much, yes (although I don't know the precise details of how you'd
implement your work in the chain, I just very much suspect it's almost
trivial). It's less about a Command being an interface though and more
about the fact that there is an infrastructure that allows you to add
steps to the processing chain with ease. You used to have to do this by
either subclassing the RP or Action, or maybe other things. Now, you
just write a simple Command and modify the chain. It's one of those
incredibly simple and obvious things that leads to great power :)
Anyway, whether Commands or Actions, I would also like to expose new
functionality in struts-config.xml file. This involves changes to DTD.
I want these features to be treated by users as an integral part of a
new release, not as a bold-on solution that uses either clumsy
"parameter" attribute or custom properties of action mapping. I want
to make events and components a core part of framework. Yes, there is
probably more marketing to it than real necessity. Yes, I can screw my
stuff together with current codebase, event with 1.2.9. But framework
will feel more integrated if new features will be treated as real core
features. Perception is a great thing. But it is not just perception,
the code is really cleaner and simpler if the features are pushed to
base Action. No plubming code in custom actions, no custom properties
in mapping.
As to having infinite possibilities with combining different Commands,
I believe that most developers do not need inifinite flexibility. They
need base use cases covered with maximum ease and simplicity. And if
they do need something different, then hey, MY PROPOSAL DOES NOT LIMIT
THEM MORE THAN THEY ARE LIMITED NOW. Sorry for shouting, seems that I
haven't stressed this enough :-)
I guess that many question not only the necessitiy of component
support in Struts1, but the very choice of it. Why my code, why not
somebody else's? Because it is here, it works, proven and I am willing
to support it, both the code and the docs.
I don't buy the idea that Struts1 should be just a bare controller in
chains, and everything else should be a bolt-on. This would not differ
much from customising standard servlets.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
