Vic wrote:
Don Brown wrote:
When you start looking at configuration for defining procedures, it
can get messy quick - just look at Jelly. Many would argue XML is
just not a good fit for procedural code/definitions.
Good argument.
Even if you liked XML for
procedural configuration, I'm not sure chain's dtd would be a good
idea either.
I think Chain XML files are self describing, you can put in ANY
properties, as long as it's valid XML. (so it's not a real DTD, it's
open).
It only can only be used to define a linear process - no
braches, loops, or iterations. Instead, you'd have to code that
logic inside your commands, further complicating them and making it
even harder to deduce flow.
Great argument, same point as above. When developers wrote something
for me, it was harder to follow.
Personally, I like the approach of using XML to define items, then
letting how those items are processed be defined with chain or
whatever else. Even then, I like using chain and CoR for defining
one pretty static process like how Struts
That is a good practice, Agree.
handles requests, but leaving it up to
Java or scripting languages for defining more dynamic, complex
processes.
Inversion of Control, however, is really a different beast as it
seeks neither to define processes or conceptual elements, but rather
*configures* actual classes which may be different.
Key word is "configures". You can configure chain and commands a lot
in XML same as IoC and random proerties, declare xml elments in xml...
(I do have chain dispatching based on a "DispatchCommand" that looks
at the string passed, and then executes that Command from the Catalog,
a bit like LookupDispatchAction- I think that's what its called)
Adding IoC jar would add complexity for users (sometimes you use IoC,
sometimes you use CoR - harder to teach), Struts would be heavyier
(like Spring is popular, but they have 2 of everything in there).
Struts I would like to be a light "C" (of MVC).
Now back up..... I agree that declaration is a good practice and
"process" in XML is a bad practice BUT.... users should be allowed to
use Struts "wrong". No 2 Struts production are the same out there.
So just becuase you can put your rope arround your neck in chain xml
should not prevent user chains.
I think once ActionCommand() is released, then it will be easier to
see issues.
On another topic, when convinient, try to keep Context clear of View
API, so that many views are supported. (like formbean knows nothing of
DAO)
For example if we can have same "UserAction" that a user wrote be able
to hanlde TilesAction request(5 arguments), Portlet requests, Jabber
Request, JMS request, JSF request, etc.
Imagine a user has a TilesAction or regular actions and updates to
Struts v"1.4". Then... same action... supports Portlet (or SoA in my
case). Not sure how this would work out but...
For what ever reason Struts is very DAO agnostic, but somehow Servlet
API is in there. (I do not need JDBC to build Struts).
Of course without breaking HTML tag. :-)
In general Saint "Something- st augstine" said: "perfection is achived
not when you have nothing more to add, but when you have nothing more
to remove"
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
