struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Does Struts really need two frameworks? (long)
Date Tue, 20 Jun 2006 18:26:03 GMT
Just last week I was talking to another senior architect at my company, 
and he was asking me how a developer knows what they should get when 
they go to the Struts site?  He was asking me what "Struts" was at this 
point.  It was more than just a navigation issue, he thought there was a 
very confused message.  I agreed with him, and have for some time... 
I've spoken on this in the past, but I hope I'm not counted as one of 
"our more radical members"! :)

I personally came to grips with how things were a while ago, but it's 
nice to see someone on the Struts team tackling the same issue. 
Clearly, as evidenced by that conversation last week, it's still 
definitely an issue that could use some discussion.

My one thought when reading your proposal Don is that I'm not sure what 
answer I would have been giving him if things were the way you 
describe... I'm not sure, to me anyway, that it really clarifies anything.

I'm also not sure I agree that Shale could be considered a library. 
People tend to think of a library as something relatively lightweight, 
and with all that Shale offers, I'm not sure I could ever consider it 
that.  Your point about it being able to be used peace meal makes some 
sense, but I'm not sure something ceases to be a framework just because 
you can swap pieces in and out, or not use pieces at will.  To me, that 
just makes it very flexible :)

I'm also concerned that building such a "hybrid", as you describe, would 
lead to even more confusion, even though it's one framework.  I happen 
to agree with you, and similarly have changed my thinking a bit, in 
terms of frameworks being wider in scope than Struts historically has 
been.  On the other hand, coming to something like Webwork is, I think, 
more daunting than "classic" Struts precisely because there is so much 
more to take in, and I think such a hybrid would only be that much more 
daunting.  Struts has been the success it has been largely because it's 
been pretty easy for people to pick up and go (we're only starting to 
think otherwise with the advent of things like Rails, which makes it 
even easier purportedly, but before that, Struts was pretty good!).

While I'm not sure about the details of your proposal (nor am I honestly 
sure how to do any better), I do think it tries to address the root 
problem: the Struts "umbrella" idea, from what I've heard talking to the 
people I talk to, has lead to more confusion than anything else.  I 
think it disregards a key historical point: that "Struts" meant a very 
specific thing: a framework, for a long time.  That's what people know 
it as.  I don't know if the umbrella idea was a good one or not, and 
that probably doesn't matter any more anyway... I get the sense that the 
message of that conceptual change didn't get translated very well to a 
lot of people outside the Struts team, and that's where the confusion 
comes from.

Just some initial thoughts anyway... your underlying principal is one I 
can get behind, although I'm not sure yet if I quite like the 
particulars :)  In any case, I'm glad it's apparently not a taboo 
subject, as it sometimes seemed in the past.


Don Brown 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] 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
AIM: fzammetti
Yahoo: fzammetti
Java Web Parts -
Supplying the wheel, so you don't have to reinvent it!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message