This is the same thing except giving the real problem, JSF force fit into Struts, more importance. This intensifies rather than solves the problem. Action and JSF are two different web frameworks. That is the bottom line. Adroit talk, fancy speeches, etc., cannot change that and only serve to diminish the little confidence people have in those who try to talk the problem away instead of solving it. Let JSF make its own way.
On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote:
As Shale and Action zero in on their first GA release, I don't think it is too late to ask the question, "Does Struts really need two frameworks?" We have been putting out the message, "two frameworks, one community", for almost a year now, but I still sense a lot of confusion and even rejection from the Struts community. The problem is for our whole history, Struts was a single framework, what you went to if you wanted to structure your web application according to Model2 principles. Our attempts to turn Struts into an umbrella project, I feel, have failed. Struts Action 2 is seen, by some, as a simple rebranding of WebWork 2, and to be honest, it really is at this stage. Struts Shale is seen as non-sequitur, milking the Struts brand name. While these opinions are most extremely expressed by our more radical members, they are also held to some degree by some very smart, sensible people [1]. From a Struts committer perspective, Wendy made a good point to me the other day saying that Struts lacks the single purpose or vision of most Open Source projects. Despite our recent attempts to find common ground, Shale and Action are still positioned as competing frameworks with no overlap. This division leads to conflicts that suck the joy out of Open Source development. Recently, Struts Action 2 unified the programming models of action-based and component-based development by allowing the developer to adopt an action-based approach for an application, yet use JSF components and abilities where needed. We have always said the desired end state would be to return Struts into a unified framework, and I think we should jump on this chance now. I propose Struts return to its roots as a unified framework through building on three libraries to make JSF and pure Servlet/JSP development easier. Namely, I propose the Struts project to be the following subprojects, each with their own release cycle: - Framework: Struts 2 - Libraries: Struts Action, Shale and Struts Tags Struts would be the single framework the world would see. It would contain support for Action-based, JSF-based, and hybrid applications. Its documentation would promote the Struts Action controller as the preferred entry point, even if only to be used for AJAX services. Its JSF library, Struts Shale, however, could be used with a regular FacesServlet. JSF components and Struts Tags would be equals when describing how to tackle the View of an application. Struts Action would be the core library driving Struts 2, replace Struts 1.x. This library would be everything now known as Struts Action 2, but without the UI components. We would aim for a solid Action-based library independent of the view, much like Action 1.x. When we talked about what an Action JSR would look like, this would be it. Struts Shale would be repositioned as a library, which I think is a better fit. A framework to me is a comprehensive, one-stop-shop solution to create an application. A library is a collection of independent features that can be used in piecemeal. Therefore, I think a library is a better definition for Shale's collection of JSF extensions. While Struts Action would definitely support Shale, it would continue to be able to be used with pure JSF applications. Struts Tags would be the WebWork UI components, a library of re-usable, stateless tags that can be used in Velocity, Freemarker, or JSP. They would include current and future AJAX tags. These tags would most likely remain tied to Struts Action 2, but not necessarily. How would this benefit Struts Action? By splitting of the tags, we can focus on the core project and get it out the door quicker. By publicizing our JSF and Shale integration, we would open our framework up to a broader audience. How would this benefit Struts Shale? Shale would also be opened up to a broader, Action-based audience and wouldn't be seen as a competitor to Struts Action. It wouldn't lose its autonomy or pure JSF support. It would gain developer support as more Action-based apps would start to use JSF and need Shale. How would this benefit Struts Tags? The tags could evolve quicker with faster releases due to less code. They would be free to add new marginal features without worrying about bloating Struts. This project would be analogous to MyFaces Tomahawk as a library of components. How would this benefit the Struts community? Finally, Struts returns to its roots as a single framework. While pieces of it may be usable outside the Action-based controller like Shale, it becomes the single place you go to solve your application development needs. The documentation would be unified and the supporting committer community in step. If you wanted the whole framework, you download Struts. If you just want one of the libraries, they are available ala carte as well. This proposed change is primarily one of message and vision, and should have minimal impact on current development activity. With the next generation of books and conferences in the works, I think it is important to develop a clear message to the Struts community and minimize any confusion. The bottom line is we want Struts to be the place to go to make web development easier, faster, with less hassles. I think this proposal provides the vision to make that happen. Don [1] http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
