Grokbase Groups Struts dev June 2006
FAQ

[Struts-dev] Does Struts really need two frameworks? (long)

Dakota Jack
Jun 22, 2006 at 10:25 am
Heh, I have an idea, since JSF is so independent, why don't you start an
open source project for JSF? Then we could see if people really want it and
we could begin to tell what in the h -- e -- l -- l is going on with
Struts.
On 6/21/06, Craig McClanahan wrote:

The short answer is that no, as long as I have any say in it, Shale will
not
morph to be dependent on Action2. SAF2 is too heavyweight and too
complexfor my tastes (see below for more about that remark), besdes the
fact
that it implements a lot of stuff that is redundant to what is already
part
of JSF (and therefore Shale) that -- from the perspective of a new
application deveoper -- just complicates the picture instead of
simplifying
it.


I agree, except for the suggestion that Struts, rather than JSF, is heavy
weight. JSF is a misguided attempt to turn HTTP into Swing.

Don't get me wrong ... SAF2 is a very elegant evolution of the
action-oriented controller paradigm. It's the paradigm that I have a
problem with.

The complete longer answer will need to wait until I finish my analysis of
what Don did (but thanks for addressing WW-1357 right away!) to improve
the
support for JSF components in SAF2. But the bottom line is that, in 2006,
I
have philosophical differences with action oriented frameworks (in the
sense
of what we see available today) as the right long term answer to designing
new Java based web applications -- Struts or WebWork or whatever. It's
wonderful that you are looking out for the migration use case, where
people
need to add a few JSF components to their existing Struts or WebWork based
apps. No matter what happens, I can be comforted by the fact that people
wanting to add a bit of JSF component wizardry to their existing apps will
have that option.

But the end result of an SAF2 + JSF based application is pretty much the
same, from an architectural viewpoint, as the result of a Struts 1.x +
Struts-Faces integration library + JSF based application. You end up
using
only part of JSF (the UI components part ... valuable, yes, but not the
whole story). Worse, though, you end up with this wierd mismash of a
front
controller in front of a front controller (mashed teogether in the
interceptor chain in the SAF2 implementation, but the same conceptually).
Leading to continual decisions during the maintenance phase of a
development
project ... do I add a new page via action-framework navigation, or JSF
navigation? Do I use the action framework's validation scheme, or
JSFs? Am
I forced to depend on Spring or whatever for dynamically created beans
with
dependency injection, or can I rely on the fact that JSF already provides
a
basic facility for this? Red Flags time!

Indeed, one could make the same argument Don makes about consolidation,
but
in favor of adopting JSF as the fundantal controller architecture, and
providing a full-up JSF implementation (probably based on MyFaces) that
also
incorporated XWork interceptors on each lifecycle phase (see SHALE-106 and
SHALE-136). At least you could test such a thing for compliance with the
JSF spec, and not have to hope that the folks that are utilizing some of
the
more critical JSF extension points are doing so in a manner that is going
to
be compatible with "pure JSF" component libraries and frameworks.


Can't people see how nuts this whole talk is? Craig is the author of the
problem that is faced here. Why would you think he can be the solution.
This is all terribly neurotic at best.

To me, it does not make sense for a framework to say "I adopt JSF"


A framework cannot adapt JSF because JSF is a framework. Lord!


but then
have *redundant* implementations of things like validation and navigation
and depdency injection and expression evaluation and .... This is fine
for
a migration story, but for new development it needlessly complicates the
architecture of the resulting aplications. JSF already supports navigation
(pluggable, if you want something completely different). Why should I be
forced into SAF2 Results? JSF already supports a validation framework
(easily extensible to client side validation, see Shale's feature in this
respect). Why should I limit myself to what SAF2 offers? JSF has managed
beans for basic dependency injection (including the abiltity to inject
beans
into a particular scope, which Spring is only now supporting in 2.x).
Why should I go back to a single execute method (plus prepare() if you
implement Preparable) as the only application events an action ever hears
about, versus the four supported by Shale's ViewController? Why should I
be
required (or encouraged) to use Spring even if I don't need all the fancy
stuff like constructor injection that Spring provides (which, by the way
"works fine lasts a long time" with pure JSF already)? To say nothing of
the fact that not using managed beans means you are passing on the
resource
injection facilities already available in Java EE 5. To say even more
nothing about the future ... keep an eye on things like JSR 299 if you
want
to see where the "mainstream" market is going ( i.e. not necessarily what
the geeks like, but where the market opportunity for consultants is going
to
be the best :-).

Heh, I have an idea, since JSF is so independent, why don't you start an
open source project for JSF?


Personally, I can look back with a lot of pride at the longevity of the
MVC-oriented concepts that Struts 1.x brought to the web application
space.
Sic years in Internet time is FOREVER! But, for me, it's time to move on.
I care passionately about a migration path for existing Struts-based apps,
and the current SAF2 approach is acceptable for that (although it's
certainly feasible to do better on "migrate to JSF' than "migrate to SAF2"
for current Struts 1.x users). You won't hear any whining about the
fundamentals from me of SAF2 -- although I reserve the right to comment on
the details :-)


Why not migrate on over to your own open source space? There's an idea if
you think that JSF is so good. Compete fairly and see whose toushckiss gets
smoked.

But, for new developers, I prefer to think of action-oriented frameworks as
"been there, done that". The understanding of O-O concepts, and the
willingness to code things in configuration files (I *hope* you guys are
thinking about annotations for things like Preparable :-) you need to
really
leverage all the cool stuff that SAF2 includes is far too limiting for my
vision of what Java as a platform needs to do in the future.


I get a real kick out of calling this dead horse with a huge history (that
is JSF) the future. The failure for the past 6 years is the future?



I want to
focus on attracting a much larger audience of developers who are *not* O-O
professionals, whose idea of "code reuse" is cut-n-paste, and who might
actually prefer to use tools (SAF2's fundamental architecture is pretty
much
untoolable, even if someone were motivated to spend the effort to build
tooling around it). For the O-O bigots around this mailing list, I can
take
comfort in the fact that the audience I'm interested in is *many times*
the
size of the audience that will actually appreciate the technical elegance
in
SAF2.


O-O bigots? What a joke. You try to sell a tool oriented kit for dummies
and call us people with a real interest in the theory bigots? Why don't you
run away and try to earn your own keep? If JSF is so good, why cannot it
find a way to succeed apart from Struts? Where is the great JSF community
out there that is not trying to survive by hopping on this framework or that
framework? Why is JSF, that old man, so devoid of any space by itself? The
reason is because it sucks.

Or, if you want it all in one sentence: for new developers, I would much
prefer to compete with SAF2 than to cooperate with it.

If that means a (hopefully amicable) divorce, then so be it. SAF2 is a
much
better (technical) approach to the problems that Struts 1.x targeted, but
the world has moved beyond those problems. I'm no longer interested in
playing on that particular playground.

Craig McClanahan
On 6/20/06, 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]
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

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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions