struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jouravlev" <jmi...@gmail.com>
Subject Re: has struts reached the saturation
Date Thu, 16 Mar 2006 01:16:37 GMT
On 3/15/06, Craig McClanahan <craigmcc@apache.org> wrote:
> I see more books about JSF that were published in the three *months* after
> 1.0 went final than in the three *years* after Struts 1.0 went final (and
> that takes some doing -- Struts got a *huge* amount of coverage).

Most Struts books paraphrase original documentation anyway, do not
discuss real-life problems and non-standard practices. By and large
they are no better than original docs.

> I see credible efforts from multiple parties to create JSF based component
> libraries ... orders of magnitude more successful than JSP was ever able to
> get people to build tag libraries.

Because people could not cook JSP properly. Currently "JSP sucks"
motto is almost as popular as "Struts sucks", especially with Tapestry
and Wicket crowd. Those who still use JSP insist on using
parameterized tags instead of includes. Why? Because it is "better".
It is the "proper way". Because it is the official recommendation
since JSP 1.1:

  http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeView.html

Why the recommendation? Because JSP designers treated JSP (and still
do) largely as pure rendering technology:

  http://java.sun.com/developer/technicalArticles/J2EE/jsp_21/

You can take a look at what happens when dead rat is pulled out from the stew:

  http://jspcontrols.sourceforge.net/

Fellow JSP developers blindly followed the path lit by Sun, just like
fellow Struts developers followed (and follow) ancient mantras, like
"storing state in session is bad", "dispatch actions are useless",
"page is the center of interaction in Struts universe, and a pair of
setup/submit actions are just servants", etc.

> I see better tool support for JSF than I see for Struts.  Again, *months*
> rather than years after the 1.0 release.

Because, thanks JCP, JSF official specs *are* specs. They are easier
to follow and implement. Most people follow the official standards and
practices very closely, so JSF is better for them. For example, the
most sucky part of Struts is de-facto String-only ActionForms and thus
need for manual conversion. Solved with FormDef. But most people do
not want extensions, they want "original product". JSF is a way to
give an original product to them, in countless reincarnations. People
can hear only one shepherd at a time, Jesus knew it like no one.

> Compare the MailReader app as
> implemented with Struts and with Shale+JSF.

Craig, can you help with the link to Shale Mailreader, could not find it.

> Compare the (upcoming)
> implementation of the iBATIS JPetStore application (implemented with Struts,
> but with a "dispatch actions" hack)

Who's making it? iBatis guys? I am interested, I am fond of "dispatch
action hacks."

> * If you are starting a new project, you owe it to yourself to evaluate the
> benefits a component
>   oriented architecture can bring to your application.  If you don't know
> that those are, shame on you :-).

I agree that a component framework has its benefits. But with upgrade
from Struts to JSF why not to upgrate the whole platform including OS?
JSF is a component framework. JSF is not the component framework.

There is no upgrade path from Struts to JSF, even JSP pages are
different. The fact that JSP is now regarded as "that crusty stuff we
brought with us to make show that JSF provides backward compatibility"
does not make JSF more appealing that other component frameworks. Oh
right, JSF *is* a standard.

Michael.

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


Mime
View raw message