- Multi protocol support, with a "default" implementation/support for XML-RPC. HTTP/HTML is ... so 80's. Light Services will be big in 2K.
- Multi container support. Ex: PicoContainer. Servlet containers web.xml is so ... 90's. (Maybe make Pico or IoC the "default" container.)
- Built in Interface for app. monitoring / managment. (3 tiers used to mean Presentation, Data and Management back in the 80's). Right now I use JaMon in action to monitor time/ip/parms and exec time, etc. Anyone could implement a monitor engine, but building in "monitoring" api, basically start(String s) and stop(String s), would be nice.
There are also few ideas that can be shared from Commons HiveMind I think.
But... basically I think Pico + XML-RPC is very powerful and I am beginning to use it. Imagine DAO (iBatis) on back end, XML-RPC as protocol (talk to ANYTHING) listening to requests, processing them in IoC, and "binding" to a "formBean".
btw: What is business layer relay? To me it is peopleware, or the "actor".
.V
Ted Husted wrote:
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
