One keeps hearing that "Struts is dead." (At least, in French http://www.zdnet.fr/builder/commentaires/0,39021559,2134284-3,00.htm
:-) This notion seems predicated on a few facts: * Craig McClanahan is the lead developer for both Struts and Java Server Faces * there is a Struts-Faces Integration Library * there was a loonnngggg lag between Struts 1.0 and 1.1. (This was due to Struts spinning off a _lot_ of code into Commons, then becoming dependent on a few Commons projects that failed to take off.) Au contraire! McClanahan et al are gearing up for Struts 2.x. There's a lotta talk about features and usecases (portlets seem to be something they're gonna try to do), but also about more fundamental architectural change. The most likely basic change appears to be pipelining. Cocoon http://cocoon.apache.org/ has always had a lotta mindshare, but IMHO this has not translated into usage since XSLT is too {regexp, Lisp}-y even for most Java geeks. (Even for Andy Oliver, I was shocked to hear !-) So McClanahan has started a Commmon Chain project (think Chain of Responsibility from GoF) which pipelines using Java classes: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons-sandbox/chain/PROPOSAL.html?rev=HEAD&content-type=text/html > the proposed API models a computation as a series of "commands" that > can be combined into a "chain". The API for a command consists of a > single method (execute()), which is passed a "context" parameter > containing the dynamic state of the computation, and whose return > value is a boolean that determines whether or not processing for the > current chain has been completed (true), or whether processing > should be delegated to the next command in the chain (false). > The "context" abstraction is designed to isolate command > implementations from the environment in which they are run (such as > a command that can be used in either a Servlet or Portlet, without > being tied directly to the API contracts of either of these > environments). For commands that need to allocate resources prior to > delegation, and then release them upon return (even if a > delegated-to command throws an exception[)], the "filter" extension > to "command" provides a postprocess() method for this cleanup. > Finally, commands can be stored and looked up in a "catalog" to > allow deferral of the decision on which command (or chain) is > actually executed. and a Struts Chain subproject http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/README.txt > Initial check-in of a library that decomposes the Struts 1.1 request > procoessor, using the newly checked in Commons Sandbox project > called "chain" supporting the Chain of Responsibility pattern. None > of this code has been tested at all yet ... it should be considered > incomplete and conceptual, but it also serves as a proof of concept > that decomposing RequestProcessor seems pretty feasible. > Nightly builds of jakarta-commons-sandbox/chain should show up as of > tonight at > <http://jakarta.apache.org/builds/jakarta-commons/nightly/chain/>. > If this idea works out in practice, I'm going to propose an > architecture based on the "chain" concept to be the fundamental > architecture of Struts 2.0. Among other things, it lets you build > the Cocoon concept of a "site map" with Java classes rather than > XSLT transformations being the key element to creating and modifying > dynamic content. An interesting aside: Ted Husted Fri, 12 Sep 2003 14:28:09 -0400 > Chain is opening the door to another framework -- one that lives > below Struts and manages all that nasty business logic -- the way > Struts (and friends) now helps us with all the nasty presentation > logic. :) FWIW, Tom Roche, IBM WebSphere Studio Model2 Tooling, abbotforswt admin _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
