Where the heck is this new Commons-Chain? I don't see it in CVS or on the website. Sounds like the next big thing from Jakarta.
-- Norm Deane MIS Consultant Vanderbilt University (615) 322-7855 [EMAIL PROTECTED] > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2003 12:28 PM > To: Struts Developers List > Subject: Re: Where is Struts 2 going? > > > Personally, I'd like to start the work on 2.x by defining the > use-cases > or stories that we'd like the framework to realize. Ideally, > we should > be able to trace each feature back to its use-case. Then, I'd > suggest we > build the framework up, story by story, test by test. > > Here's some early work along those lines: > > http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsUseCases > > Of all possible *features*, the one I would emphasize the most is > testability. > > The second, which is a corollary to the first, would be > decoupling the > core framework from http, while allowing direct access to the > underlying > protocol when needed. > > Though, if we base the core around Commons Chain of > Responsibility, both > should follow naturally. > > > "If every controller function can be done in Faces or > > other frameworks, what do we gain by using Struts 2?" > > > > "Using Struts 2, our applications can cruise across > > modules built from different vendors or teams. And > > we could also develop modules for others." > > > > Could we realize this dream? I know there are many > > challenging problems there. Could we think about it > > in terms of defining characteristics of Struts 2? > > Personally, I'm uncomfortable defining an open source product > in these > terms. We're not a retail product looking for a market. We're a > community of developers building the everyday tools we each > need to use. > > If the Java platform did ship with everything everyone > needed, then it's > true that we'd have nothing to do here, and we could all focus on our > paying jobs. <hurrah!/> > > But it is unlikely that such a day will ever come <sigh/>. In all > likelihood, there are always going to be vacuums for open > source to fill. > > If people need Struts to be an integrator, then people will > contribute > integration code. Of course, that's already true. Stxx > integrates Struts > with XLST. The Velocity Tools integrate Struts with Velocity. Some of > Don's packages integrate Struts with Cocoon and BSF. And so on. But > people didn't do this because we put it on a whiteboard. > People did this > because it is functionality they needed to do their jobs. > > IMHO, the role of the Struts Committers is to ensure that generally > accepted best practices are followed, so that the codebase > remains easy > to maintain and improve. For new development, especially, that means > using techniques like test-driven development and technologies like > Maven and IDEs that help us write cleaner code. For > frameworks, it also > means using patterns like Context and Chain of Responsibility > to loosen > coupling. But as to where the specifics of development take > us, IMHO, it > should be "from each according to their need". > > > Now we have the Struts chain. I like the ideas of the chain. > > Amen to that brother. =:0) But, it's not *Struts* chain -- it's the > *Commons* Chain. The true power of this package is that it gives us > common ground upon with to build *business layer* frameworks. > Right now, > many of us are abusing Actions because Strut is the only controller > framework we got. :( > > But 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. :) > > -Ted. > > > Jing Zhou wrote: > > I believe this topic has been discussed hundreds of times > > in different subjects. One of important tasks for a new > version is to > > identify concept leaps. This is the place I would like to entertain > > your brain - hope everyone to have a brainstorm on what are > really the > > innovative ideas to be built in Struts 2. > > > > To start, let's review what the innovative ideas are in Struts 1.0. > > Struts is called a MVC framework. But that is not enough, actually > > there are many other frameworks also called MVC ones. What > made Struts > > unique at its early time is its defining characteristics > between form > > beans and web forms. They are symmetrical entities. > > > > In Struts 1.1, another concept leap is introduced, we > > called it application module. With this concept, > > the developments of Struts applications scale up. There > > are some other concept leaps, someone could add more. > > Struts 1.0/1.1 is recognized as a Controller in general. > > > > Now we have the Struts chain. I like the ideas of the chain. In > > particular, I see the possibility we could transform the Controller > > into an Integrator based on the chain and the application module. > > > > Integrator is a higher concept than Controller in my > > opinion. Struts 2, as an Integrator, should be able to > > 1) Integrate faces components from different vendors. > > 2) Integrate other non-faces component easily, including > > existing 1.x tag libraries. > > 3) Integrate expression engines from different vendors. > > 4) We could add more... (like portlets) > > > > The general expectation I have with the Integrator is > > that application flows can smoothly move around modules > > while underlying module-wide settings for a particular > vendor, say a > > PropertyResolver in one faces module, can be switched to a > different > > PropertyResolver in another module (Expression engines can > be switched > > too). > > > > This is a whiteboard idea. I like to see the idea to be > unfolded. One > > of reasons is that a Struts user may be asked by his/her > boss in the > > future "If every controller function can be done in Faces or > > other frameworks, what do we gain by using Struts 2?" > > > > "Using Struts 2, our applications can cruise across > > modules built from different vendors or teams. And > > we could also develop modules for others." > > > > Could we realize this dream? I know there are many challenging > > problems there. Could we think about it in terms of defining > > characteristics of Struts 2? > > > > Jing > > Netspread Carrier > > http://www.netspread.com > > > -- > Ted Husted, > Junit in Action - <http://www.manning.com/massol/>, > Struts in Action - <http://husted.com/struts/book.html>, > JSP Site Design - > <http://www.amazon.com/exec/obidos/ISBN=> 1861005512>. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
