Craig R. McClanahan wrote: http://www.geocities.com/fullback_21_csca/index5.htmlhttp://www.geocities.com/fullback_21_csca/index5.htmlhttp://www.geocities.com/fullback_21_csca/index5.html
* I'm interested in decoupling the controller part of Struts from its current heavy reliance on the Servlet APIs. Among other things, that would enable easy use of Struts in portal servers that will support the emerging portlet API (JSR-168). You've also heard Ted and others talk about the need for a good controller paradigm in the business tier as well as the view tier. We know how to build such a thing :-).
Yes we do!
The more I think about it the more I'm convinced that Struts is a primarily a very effective application framework, that just happened to use web apps for its first implementation. We just need to continue to abstract out the HTTP semantics (as we did for Messages) and "expose the framework within".
Another good example is the pluggable Request Processor. I could easly see this same object model applied to a business architechture. You wouldn't use a HTTP request, but you could pass around a business context for the same purpose (a la Velocity). Likewise for the response and a CommandMapping (err, ActionMapping).
I find that the whole command/semaphore thing that Struts uses with the ActionMapping and ActionForwards works just as well on the business layer. "Success" is success. The business controller can decide *what* to do, and the Struts controller can *map* that to where the JSP lives. ("Standard obit, navigator.") The business layer can define what commands it may pass back ("success", "failure", "annualReport") and then its up to the presentation to decide which pages relate to those commands.
IMHO, in the end, a lot us will be building business applications using components from the Commons, and then just exposing that application to Struts for the web-layer stuff. Most of the Struts sub-systems, like validation, messaging, workflow, data access, can (and do) live at the business layer. Our business applications won't use the Struts ApplicationResources: Struts will use business layer's ApplicationResources.
A key pattern underlying Struts, and most of the other HTTP application frameworks, is the idea of deploying an object-web from a XML document. Right now, our servlet has two major responsibilities.
* Process requests
* Deploy the object-web
The former responsibility is now fulfilled by the Request Processor. It might be interesting to look at abstracting the Deployment Processor into a pluggable object (or even a sub-framework).
Right now, there are a lot of people reading in DTDs and deploying object-webs (including us - for Tiles and the Validator). There would seem to be a need for some type of base processor object, with handy extension points, that could be plugged into a servlet as needed. This could also make it a lot easier for teams to plug-in their own configs and deploy their own object webs.
I still need to look and see how Cedric does it, but I think the idea of getting XML elements to "extend" each other is very imporant. We should be able to do with in all of our config files, and open up the capability for other products as well.
While there's been some pressure to build more elements into the struts-config, I would argue that we need to go the other way. We need to be able to share things like validations with the businesss layer. Separate config files for discrete components reduces coupling and increases coherence.
The real solution here is better tools. The Struts Console already reads struts-config and validator files. It's easy to envision a tool like this that could read in multiple configs and provide a single view to the developer. And there's a bunch a ways we could make something like the Console a very cool way to write these documents (picklists for valid options, dynamic picklists of most often used values, and so forth).
The endgame would be if one Common Console could also read Hibernate and OJB configs, and maybe even help us synch DynaBeans with the data beans. Not to mention editing JXUnit files to create unit testing scripts, or, gosh, Ant buildfiles.
Back on the homefront, we already fixed a number of design issues in 1.1. Two remaining hotspots seem to be
* Uneven use of the action/page/path properties, * Presumption that ActionServet is the one-and-only ActionServlet, and * Action lock-in
action/page/path
We added the "action" property to the link tag in 1.1 (<head-slap/>). This small change makes a *huge* difference in clarifying the original intent of the API. It may also be helpful to add "action" to ActionForward and deprecate "path" in favor of "page", to agree with the taglibs (and remove the semantic conflict with "ActionMapping.path"). We might also think about whether "ActionMapping.input" should be able to indicate another "action". (Since many applications use "page controllers" to seed the request before displaying a page.) I'd see this as evolutionary for 1.1.
one-and-only ActionServlet
The work we've done on the modules is very cool, but another reasonable approach would be to allow multiple ActionServlets. As we develop 2.0, we might work to remove this constraint.
When we move forward on 2.0, the things I would like to see most are iterative/test-driven development. We might to decide which parts of the framework need to implemented first, devise tests for those parts, and adopt/adapt our existing code to prove the test. I've done some preliminary doodlings about a sequence of iterations here:
http://husted.com/struts/usecases.html
Action lock-in
Struts 1.x only supports one Action type. Some other frameworks, like JPublish, support Java classes as well as "any scripting language which can be plugged into the Bean Scripting Framework". (JavaScript, VBScript, Perl, Tcl, Python, to name a few.) I think someone has also mentioned the idea of using JSPs for Actions. I know other people are already using Actions to run Jelly scripts.
Again, I have study it more closely, but David did an interesting thing with the Validator in that you can specify the signature of the plug-in method. This would be an interesting thing to do with Struts 2.0 Actions: roll your own interface.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]