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. Even if you liked XML for procedural configuration, I'm not sure chain's dtd would be a good idea either. 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.
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 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.
Don
Joe Germuska wrote:
Since there was so much coming out of the ApacheCon summit, I decided to split my responses up a bit.
I think long-term, the way in which Struts is configured is one of the most important factors about its ease of use and maintenance.
At 9:37 AM -0600 11/21/04, Vic wrote:
So I say no combined DTD in favor of chain DTD, and no IoC, because CoR , similar in purpose, is better than IoC. If IoC always had same signature - you'd have CoR. I know IoC is fashionable, but CoR is better, I put both in production.
There is definitely something to this. I don't think I would agree that the Chain DTD would subsume any other configuration, but it's possible to imagine, at least in many cases, scrapping the struts-config.xml and instead having each command configure itself with whatever it needs.
The problem comes when multiple steps in the chain need to reference the same configuration information. For example, form beans need to be looked up to populate them from the request, but they also need to be looked up if you want to pre-populate a page with application data. You wouldn't really want to push the form-bean configuration into the "CreateActionForm" command; instead, you'd want both "CreateActionForm" and (some as yet non-existent) "PrepareViewContext" command each to look up something in the StrutsContext which had that expertise.
The other problem (if it is a problem) comes with explaining just what Struts is, if there's no struts-config file! I wouldn't let that stop me, but it is interesting in a way.
If we were to use some kind of IoC, what would be the collaborators? I have often thought it would be nice to replace all those config classes with some more intelligent classes that have config but also do things (especially form bean and action instantiation), thereby centralizing some of the logic. Furthermore, I do prefer, in general, the idea of initializing one (or very few) objects for each relevant scope (in this case, particularly, the application scope) and then populating properties on those objects, rather than trusting everyone to use the right attribute name for fishing those out of contexts.
I'm still trying to go through actual Struts code looking at it with these ideas in mind to validate whether there are really places where Struts would benefit from this, or if it's really just a matter of taste that isn't worth trying to impose on Struts.
Joe
At 8:47 AM -0500 11/21/04, Ted Husted wrote:
-1.4 considerations-
One we get past 1.3.x, there are some other things that we might consider.
Consider combining DTDs. Right now, using "standard" extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration.
Consider adding catalog element. Depending on how the work goes with the experimental ActionCommand interface, we might identifiy a need to add a catalog element to the Struts configuration, to support using a Chain of ActionCommands.
Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
