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]
