I may have got the wrong end of the stick, but doesn't Struts overlap to some degree with JavaServer Faces and wasn't there talk of perhaps Struts evolving to be a implementation of JavaServer Faces?
Is this way off base or is this one possible direction for Struts2? Niall ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Friday, September 12, 2003 7:28 PM 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]
