Was there all along. Funny what you see when you open your eyes. -- Norm Deane MIS Consultant Vanderbilt University (615) 322-7855 [EMAIL PROTECTED]
> -----Original Message----- > From: Mike Jasnowski [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2003 12:44 PM > To: Struts Developers List; [EMAIL PROTECTED] > Subject: RE: Where is Struts 2 going? > > > I think it?s in the sandbox area > > -----Original Message----- > From: Norm Deane [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2003 2:36 PM > To: 'Struts Developers List' > Subject: RE: Where is Struts 2 going? > > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
