> 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. >
Use-cases are very easy to be visualized and understood. I could try to draw something to clarify the ideas, if possible. > 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. Perhaps I put my expectations too high. But we *need* some terms for average users or non-technique people to understand quickly. For example, I see such statement or similar ones in many places: "Struts is all about controller." Here is not about marketing a product in these places, it is about what Struts is. Of course, we could say, Struts 2 is to be a business logic integrator and a view technology integrator. I expect both to be true. > 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. That is the driving force for us to consider a *common* mechanism to allow different view technologies to live peacefully in one web application. The *problems* I envision now is that many view technologies assume application-wide settings (with sub-settings adjustable by programs). If an end user chooses one of such view technologies in a web application, then the user would not be able to use a different view technology in the same web application. For example, the PropertyResolver and the RenderKit could be very vendor specific, once the user chooses that vendor, the web application is tied to that vendor life time (or very hard to configure a different PropertyResolver). That is really bad for a component industry and bad for that user too. To solve the *problem* (maybe not for all), I think the sub-settings for PropertyResolver and/or RenderKit should be module-wide. We create a ModuleContext, which is responsible to switch the sub-settings when application flows run across module boundaries. For example, when an application is landed in a Velocity module, the module context for Velocity is prepared by Struts automatically. So the Velocity engine could perform its rendering jobs. When the application leaves the Velocity module and is landed in a Faces module, the module context for that particular Faces' settings is prepared. If this scenario could be materialized, we also need to find a way to generalize the ActionForward and have a command to execute the generalized ActionForward. For example, if it finds the target module is Faces enabled, it will use the path as a tree id. If it finds the target module is Struts 1.x module, it just does the regular forward as it does today. (Something should be figured out how to make the transition transparent between Faces and non-Faces, from what I read and understand about JSF, it is very likely doable. Could the same be done for Velocity and Cocoon?) I am not sure the white board drawing could be proved true or not. But I hope through healthy discussions maybe someone could bring us a much better idea to integrate a variety of view technologies, including the current Struts tag libraries. Please regard this message as a user feedback, feel free to express your opinions, useful or not, from the usability point of view, and then doable or not, from the feasibility point of view. Jing Netspread Carrier http://www.netspread.com "Entertain your brain with different band widths." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
