My thoughts, based on my experience, with ActionComand(Map/Context) which is full of benefits which I will list:
I did something like this before Ziff, mostly to avoid a common Struts user mistake (putting properties in action class and creating a thread safety issue) such as pseudo code impl:
Class abstract ActionCommad extend Action {
final Forward execute(req,resp, maping… ) {
Map.put(“req”,req);
Map.put(“maping”, maping);
…
execute(Map);
Forward = map.getForward();
return Forward;
} // exec
abstract execute(Map);
protected Request getRequest(Map) {
return Request Map.get(“req”);
}In essence this is the second “user” chain (1st one is the system request process chain)
So very simple impl.
1. As pointed out the Context/Map allows to break from Servlet API, which does not have to be forced on people, but it did allow me to do Laszlo easily. (Now it also allows me to “Bypass the Browser for RiA”.)
2. It lets you use Collections/Map to pass arguments, one or many and return one or many WITHOUT changing the signature. (I also sometimes have an internal _map for Command instances … I do not know how to explain it better but it’s handy)
3. It is inevitable that users will use Commands once introduced 1.3. The commands and the userchain.xml are very configurable; users end up with “same size bricks” to build with (as opposed to IoC, which every signature is different).
The userchain.xml is very configurable, lets you put properties in xml.
So, this is a bit of a jump but, I do not think Struts XML DTD should be changed 2 times.
Yes I know currently elements are repeated, but the Chain.xml is VERY configurable. My developers surprised me when they re-configured something just in chain, no code.
For example once can make a Validate Command My “Struts-config” was replaced by ChainConfig.
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.
For example, lets say you want to add JMX to request chain… easily! With IoC… you need to think a bit and rearrange.
Or lets say there is a Validate Command and you want to use it else where? Trivial. Mix and match. So… lets do simple Chain and see if IoC ads something other than coolnes.
4. Lets bring up FormBean. I had “BaseBean” (which I named company after )
extend FormBean implement Collection. This made it easy to do complex muti row operations. (There is an implementation of this on sf.net in apache license http://www.sourceforge.net/projects/infonoia )
I think FormBean should continue evolving and it’s not listed in ApacheCon ideas.
5. More Collections, 1st to pass arguments and … the “latest” BaseBean does not extend FormBean, it’s just a collection. So I no longer use beans! (thus I am changing the name of company to something else from baseBeans). The FormBean does… nothing.
For a single row I use a Map extension. For muti row, I use an ArrayList of Maps. (I find it superior to RowSet and JavaBeans). It is loosely typed and if users add UI columns or dba changes model, my “Controller” part is still solid, no more get/set and cruft code.
So the new “FormBean” is a Collection that “maps” to the “form”/screen.
Simpler. When you need beans or VO/DTO/Dynabeans, a collection can act as any as needed.
Later you can present the collection as XML (just like iBatis returns rows from DB as XML).
6. I also have this dynamic dispatcher that lets you execute a DAO map, and CRUD operation or even any Command, without ANY code (based on the chain). One just creates a DAO map or a Command, and just pass in arguments to the dispatcher.
So I have leaned on Chain and it took me far, and I do not see limits. Just like Struts, Chain is simple and gets out of the way when I need to do something but still provides a structure and a mapping for other to be able to follow the code.
Struts 1.3 chain will be amazing. Action Command will add a lot also.
So those are my thoughts,
.V
Ps: my personal project is to leverage JDNC to use a Struts like chain dispacher, more here:
http://www.javadesktop.org/forums/thread.jspa?threadID=6668&tstart=0
Oh and my 3rd book is on the way, based on "NEW Swing for CMS", since JDNC will be a part of Mustang.
Ted Husted wrote:
While at ApacheCon, Don, Martin, and I had a chance to chat about refinements to the Struts Roadmap <http://struts.apache.org/roadmap.html>. Here are my notes for everyone's review and comment.
As planned, in Struts 1.3.x we would integrate Struts Chain from config and add an "extends" attribute to all the configruation elements (a la Tiles). While we're at it, I'd also like to add a Ant-style properties file to make variable substitutions within the XML elements. We use this in iBATIS, and it can be a helpful way to configure applications and reduce redundancy.
-Experimental Members-
Those items by themselves seem like enough for a release, but we might add a few "experimental" classes and interfaces to give us a chance to play with Struts Chain in our own applications. We came up with two experimental classes and an experimental interface: ActionCommand, ActionContext, and ViewContext.
* ActionCommand - A Chain Command-like interface with one method:
void Execute(ActionContext context)
Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API.
* ActionContext - A Chain Context that implements the Action class API. Existing code could be converted by changing references to context.* and so forth. Don suggested constructing this on Struts Chain so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface.
* ViewContext - A Chain Context that implements the "Velocity Tools" API. In a later release, we (meaning I) could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.)
After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3, they could be marked "experimental".
The WebContext we now pass around Struts Chain could be called the "StrutsContext" to differentiate it from the ActionContext and ViewContext.
[Are we now starting to call everything "Context" instead of "Action"? Not really. We use the "Context" suffix when a member extends Chain Context. This convention is unlike the current "Action" soup, since "Context" is a suffix that identifies a member's "family" history.]
-Subproject Distributions-
Also as planned, we would extract the Taglibs package into its own subproject. (Giving us a chance to make the Taglibs 1.0.1 release utilize the ViewContext.) We might also consider extracting "Actions" (plural) and "Plugins" into a separate "Extras" subproject. While the members here are popular, they are optional, and not essential to the core.
We've mentioned that each subproject should have its own release cycle. We've also mentioned the idea of "bundling" subprojects into a master distribution. We might consider taking that idea a step further and utilize the "Linux" approach. The Struts "1.3.0" distribution could be an aggregation of "Core 1.0.x", "Taglibs 1.0.x", and "Extras 1.0.x".
Later, if we end up with a Taglibs 1.0.1 GA before there is another Core 1.0.x GA, we could assemble a "Struts 1.3.1" distribution that aggregates (for example) "Core 1.0.0", "Taglibs 1.0.1", and "Extras 1.0.0".
The Struts aggregate distribution doesn't have to be complicated, perhaps just a ZIP of whatever subproject GA distributions work with the "best available" core.
-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.
-1.5 considerations-
Based on our own work with the "experimental" members inroduced in 1.3.x, we might consider some other changes.
Consider a "smart" action type. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even support placing an ActionCommand interface on ActionForm, so people could skip having a sepate Action or ActionCommand class. The ActionForm could do it all.
Consider a "populate" method on ActionForm. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on an "god" class to populate it from the outside.
Consider a "FormContext" mechanism. Rather than "throw-away" a request-based ActionForm, the object could be seralized as a hidden-field or session-object and restored on the next request. Many other frameworks support this behavior now. Struts would have a slightly different spin, since we look at the form as an named entity rather than as an anonymous aggregation of other objects.
-1.6 considerations-
Consider multiple controllers. One reason we introduced modules was because "there can only be one" Struts controller in an application. With the context-based changes we making, we might be able to introduce a mechanism to support a collection of Struts controllers, each identified by its servlet or filter name, each with it's own URI pattern. The key to being able to do something like this is for view members to look to the ViewContext rather than the various servlet contexts. Each Struts controller would place the appropriate ViewContext in its own requests.
Consider an alternate configuration file. There are idiosyncrasies in the element/attribute names of the struts-config which often confuse new developers. By either supporting alternative configuration loaders, or applying a stylesheet to a XML configuration, we could support both the "classic" and a new configuration.
Thoughts?
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
