struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dakota Jack" <dakota.j...@gmail.com>
Subject Re: Does Struts really need two frameworks? (long)
Date Fri, 23 Jun 2006 05:29:44 GMT
Who would "they" be?  Did anyone notice that Craig resurrected the failing
JSF for Sun?  I really like Sun but this has to be the worst thing they have
managed to back.

On 6/22/06, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>
> 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
>
>


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message