struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin.Bed...@sunlife.com
Subject Re: [J2EE] Does struts follow Sun's Core J2EE patterns
Date Tue, 22 Oct 2002 19:29:57 GMT



I have copy of the J2EE core patterns book on my desk here and I took an
application to production once that was based on Sun's Pet Store app. That
doesn't make me an expert - but I have a couple thoughts...

First - here's a link to Sun's J2EE patterns:
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/

To begin with, Sun publishes a 'catalog' of patterns, not just 'a pattern',
so it's difficult to know specifically which he was referring to.

The closest pattern in the Sun catalog is probably the 'Front Controller'
pattern. I'd say the Front Controller version that uses the 'Servlet Front
Strategy' to be specific.

Looking at the sample code provided by Sun to implement this pattern, what
you find is a 'stripped down' version of the Struts ActionServlet. By
stripped down, I mean:

 - No loading configuration info from XML,
 - the 'forwards' are codified - meaning ActionForwards are not
declarative, you put them in compiled code.
 - The logging is not configurable as commons Logging is
 - The RequestProcessor isn't pluggable
 -  No support for plug-ins, datasources, message resources or i18n

In addition, the pattern has no support for encapsulating error messages,
automatic validation, view building utilities such as tiles, etc, etc, etc.

In other words, it is just a pattern - not a well-developed framework.

However, that being said, your friend is right. He could start with a set
of patterns and build each project that way. He'd even have code to reuse
from old projects to get started with. But the question is, "Why?".

Here are the reasons Struts is superior:

 1. It's much more solid. In Eric Raymond's "Cathedral and the Bazaar"
(http://www.tuxedo.org/~esr/writings/cathedral-bazaar/) he states:

      "Given a large enough beta-tester and co-developer base, almost every problem will be
characterized quickly and the fix obvious to someone."

      "Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's
Law''."

Really, this is the best reason to use Struts. So many people use it that
the bugs are found quickly. If you start with patterns and code the app
yourself, then the end product by definition can't be as robust. This is
also why the Apache web server is so solid and why Linux is much more
stable than anything MS will ever make.

But there are other reasons -

2. HE may understand all the patterns and be able to knock out code quickly
with few bugs, but can everyone on his development team do the same thing?
One of the values of struts is that it hides a lot of the complexity of
coding complex apps. Building Action classes and form beans is much easier
than designing from scratch. All members of the team can be productive
quickly and make fewer mistakes.

3. With Struts much more knowledge is retained from project to project. If
you start with patterns at the beginning of each project, then there will
be a tendency to customize the patterns to fit the particulars of each
project. In fact, many who start with patterns would call this a strength
of that approach. But the downside of this is that your team has to learn
much more each time a new project is started - the way the previous project
worked doesn't always apply.

4. It's also just a lot more work. Why, for example, write and debug code
on your own to initialize data sources when a servlet initializes? Struts
already has that and it's debugged. Why write code for error handling and
form processing and screen building and whatever.... Sure there are
patterns to follow, but why?

I guess in the end, the reasons above are the problems that Craig saw a
couple years ago when he spent all day on the Tomcat list helping people
build JSP apps (yes, you were answering my questions even back then!).
These are the reasons Struts exists.

Sorry this went a bit long and turned into a bit of a rant -

Kevin

















Rick Reumann <maillist@reumann.net> on 10/22/2002 02:14:05 PM

Please respond to "Struts Users Mailing List"
       <struts-user@jakarta.apache.org>

To:    Struts List <struts-user@jakarta.apache.org>
cc:     (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:    [J2EE] Does struts follow Sun's Core J2EE patterns


Over lunch I was discussing struts with someone that works at another
company. He hasn't implemented struts at all but only has looked at
some articles, and doesn't see what all they 'hype' is about. In his
opinion, building a j2ee controller that follow's Sun's J2EE pattern
is not that difficult and using the JSTL he feels more comfortable
using for the view (than say struts tags). He also still questions if
it follows Sun's core J2EE patterns.

I actually explained what I thought most impressive is how the
controller relates to taking in an ActionForm. He feels this breaks
Sun's standard (although I'm not sure why.. time was short).

Does anyone have comments or links to articles where Struts is
supported by those that came up with Sun's J2EE pattern? I've been
searching Google but it's really hard to get a foothold on the best/
most pertinent stuff.

Thanks for any information anyone could provide.

--

Rick
mailto:maillist@reumann.net


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







---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------



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


Mime
View raw message