Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: struts-user@jakarta.apache.org
From: "Christian Cryder" <christianc@enhydra.org>
To: <struts-user@jakarta.apache.org>
Subject: RE: Barracuda vs. Struts [LONG]
Date: Mon, 27 Aug 2001 21:03:41 -0600
Message-ID: <NEBBLPHFPPPJLHEGKLHIGEMCJFAA.christianc@enhydra.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3B8AF49A.7686B553@apache.org>

Thanks for taking the time to respond Ted! Its going to take me a bit to
digest all of this...I will try to do this tomorrow. May I email you offline
if I have questions about any of your comments?

tia,
Christian
------------------------------------------------
Christian Cryder [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
        "What a great time to be a Geek"


> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Monday, August 27, 2001 7:32 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Barracuda vs. Struts [LONG]
>
>
> First, this is a very impressive document, Chris. I personally consider
> "Surveying the MVC Landscape" required reading (along with Jason Hunters
> "The Problems with JSP"), and am glad to see that the tradition of
> high-quality documentation continues at Barracuda.
>
> Though, I personally can't justify the idea that Struts is page-centric
> framework. It is not the case that Struts encourages developers to write
> tags that access the model. Quite the opposite. The Struts tags are
> designed to obtain data from JavaBeans, or from the Controller's
> mappings. When people on the list mention using tags that access the
> view, most of will make a point of mentioning that it is not considered
> the best practice.
>
> The "Struts approach" is for developers to use the Action to obtain
> information from the model, encapsulate it in a bean, and pass it to the
> view. We do not encourage the view to access the model directly.
>
> Given this, I would say that Struts today is primarily a developer's
> framework. It is our hope that as GUIs like DreamWeaver and Homebase
> increase their support for Custom Tags, it will blossom as a
> team-players framework. Developers will expose the model to Page Authors
> through standard and custom tags that will be supported directly by the
> Page Author's GUI.
>
> Here are some specifics for your consideration. These will only make
> sense if you have a copy of the article handy.
>
> 2. Struts
>
> In the diagram, replace "Struts-config.xml" with a box labeled Action
> Mappings. These are accessed by the Controller and the View via tags.
> Disconnect the arrow from the Model to the view, since Struts does not
> encourage this (although our comrades at Jakarta Taglibs might).
>
> 2.1 Controller.
>
> + uses a XML configuration file to map URIs ..., (the default name is
> struts-config.xml, but its not
> hardwired).
>
> + when a requestis received, route it to the appropriate Action
> - identify from the URI the appropriate mapping for this request
> - use this mapping to select the corresponding action class
> - if this is the first request for the action class, instantiate the an
> instance of that class and cache it or future use
> - ...
> - call the perform() method of the action object, passing on a reference
> to the mapping that was used, and the request and response objects. The
> action also has access to the underlying ActionServlet and
> ServletContext.
> + Actions may take data from the request, may access the Model, handle
> any errors, and return a forwarding to the Controller. The forwarding
> may be a page, another Action, or be redirected to a URL.
> + The Controller returns the Response to the container, which may invoke
> a JSP, fetch a HTML page, or whatever else is required.
> + The JSP may display data from a JavaBean in the request, or from the
> session context, access the Struts mappings to render a URL, and/or
> access message resource to display internationalized text.
>
> 3. View ... Views are typically rendered with JSPs, which use Java
> Taglibs to pull data from JavaBeans in the request or session contexts,
> and insert it into the page.
>
> 4. Localization - Struts uses the standard Java localization mechanism,
> augmented with a standard Message Resource that can be accessed by
> various custom tags. The tags can automatically display the appropriate
> text for the user's locale.
>
> Collections - (The collections have been migrated to the Commons. You
> might want to skip mentioning them altogether.)
>
> Digester - You might mention that "The digester is now available through
> the Jakarta Commons project as a standalone utility. "
>
> 5. Future Directions. A "ValidatorForm" is being integrated with Struts
> that offers client and server side validations from the same XML
> configuration. It is now available as a plug-in.
>
> An advanced templating package called "Tiles" that is appropriate for
> building portals and other complex layouts
>
> 1. UI Issues -
>
> 6. It would be better to say this sooner, or later, and cleanly separate
> the criticisms of JSP from the "comparisons" with Struts. To quote Jon
> Stevens: "If you must use JSP, use it with Struts". It's my feeling that
> Struts demonstrates how JSP can be used responsibly. Which is to say,
> JSPs don't violate Model 2, developers do ;-)
>
> 1. Personally, I don't see being able to use scriptlets as a "flaw".
> Developers should have the freedom of choice. Many of us choose to say
> no, but it's nice to have the option if we need it.
>
> 2. References to taglibs in a JSP are VIRTUAL and defined in the
> web.xml. Many developers simply use the same path for the location and
> the URI, but any reference can be used. The taglibs can be moved
> anyplace on the server without changing the JSP. It is not a reference
> to the server-side unless you want it to be.
>
> 3. Respectfully, this is gibberish. The Struts tags are "minimalistic"
> and do not support or encourage looping and other such programming
> constructs.
>
> 4. Custom tags are valid markup, and provide a TLD to prove it ;-)
>
> 5. I would say that the given even the minimal support provided by
> DreamWeaver and UltraDev, custom tags are as easy for HTML authors as
> anything else. The developers do not need to work on the same file as
> the authors, developers simply need to provide an API for the custom
> tags.
>
> 2. Page Design
>
> Barracuda - While most editors and clients will ignore the Barracuda
> extensions, this doesn't make it "valid" markup. I would argue that
> Taglibs+HTML do constitute a valid markup, since the syntax for both are
> defined, and can be independantly validated.
>
> 7. Support for skins
>
> The template package bundled with Struts can be used for this, and the
> capabilities are enhanced in the Tiles package.
>
> 8. Client capabilities.
>
> Struts itself does not provide any specific features that address this
> area.
>
> Reflection
>
> Every recent report I've seen says reflection is no longer a point of
> concern. Ditto for object creation and garbage collection. The latest
> advice is that is can be more expensive to cache an object that recreate
> it.
>
> Syncronization - Also minimal in Struts.
>
> ---
>
> Anyway, keep up the excellent work, Chris. As mentioned, I think
> Barracuda is an important project, and has a lot to offer to the
> development community.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/about/struts/