struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: Does Struts really need two frameworks? (long)
Date Thu, 22 Jun 2006 16:12:52 GMT
My 2 cents.

I agree with Don that we have created "user" confusion by having two
competing frameworks. However I think if we're going to continue to
have both then they should both be "first class citizens" - rather
than relegating Shale.

Personally, user confusion is secondary IMO to whether the developers
still think theres merit in sharing the space and opportunities to
co-operate. Since I'm not currently contributing anything to either
SAF2 or Shale I'll leave it up to others to make that assesment -
although to date there seems to have been little benefit.

If others think the confusion is the #1 issue then the only solution
IMO is for Shale to move home.

Maybe we should "poll" the current committers on what they would prefer?

Niall

P.S. I was at a Sun "java roadshow" this week - they were putting out
the message that Shale is the next Struts

On 6/20/06, Don Brown <mrdon@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message