struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Cryder" <christi...@enhydra.org>
Subject RE: Barracuda vs. Struts [LONG]
Date Tue, 28 Aug 2001 18:46:11 GMT
Hi Ted,

Here are some followup questions (I decided to go ahead and post these to
the list so as to avoid duplicating explanations to others in separate
emails...besides, others might benefit from you educating me ;-)

> In the diagram, replace "Struts-config.xml" with a box labeled Action
> Mappings. These are accessed by the Controller and the View via tags.

For background, the diagram I'm using came from an IBM article on Struts
(http://www-106.ibm.com/developerworks/java/library/j-struts/)

a. Would it be acceptable to change the description to "Action Mappings
(struts-config.xml)"? I wanted to convey the idea that the mappings were
specified declaratively.

b. Could you explain what you mean by "These are accessed by the Controller
and the View via tags."? I'm assuming you are NOT saying that the Controller
accesses them via tags. But I'm unclear how the View accesses the
ActionMapping stuff...doesn't the view just grab data from a) ActionForms or
b) beans which are set up by the Action classes?

> Disconnect the arrow from the Model to the view, since Struts does not
> encourage this (although our comrades at Jakarta Taglibs might).
...
> 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.

I think maybe we have different definitions here. Let me try to clarify
where I'm coming from...

>From my perspective the term "model" means different things depending on how
its context. For instance, there is certainly a sense where the data portion
of an application (ie. EJBs, a database, flat files, whatever) acts as a
"model" for the rest of the application. This is what I'd call a 'small m'
sense of the word.

However, in the case of Model 2, we are primarily talking about a
presentation pattern that has several basic roles--a "Controller" shoves
data into a "Model" (capital m) which is just some structure that holds the
data, and then a "View" is created by pulling data back out of the "Model"
and arranging it in a manner suitable for the client. The implementation
specifics of this arrangement are usually quite irrelevant (this is after
all a pattern); just about any object can be viewed as a "Model", "View" or
"Controller" as long as it performs the basic roles associated with such
entities.

The key point I would make here is that the "View" must always interact with
the "Model" if we intend to dynamically put data into a response that is
returned to the client. That said, the "View" generally should not directly
access the "model" (small m)...instead, the "Model" layer should act as a
facade to the specific underlying "model" that backs the application.

The document was written from this perspective (so perhaps understanding my
definitions will make it easier to understand the content therein). Using
this definition, its quite proper to view a bean as a "Model" (capital m).
Thus I'd argue its essential for the View to be connected to the Model layer
in the diagram.

> 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.

I'm afraid I don't follow this at all. The point I am attempting to make in
#2 is that even if developers don't use scriptlets, the use of tag-libs (at
least if you use conditionals or iterative tags) effectively mixes
"programming logic" in with your markup. While I have heard this justified
by calling it "presentation logic" (thereby it's ok to mix it in), in my
mind its not compelling--the tags logic is evaluated and processed on the
server, the markup on the client. To me this breaks the clean separation
(and as such its a valid criticm).

> 3. Respectfully, this is gibberish. The Struts tags are "minimalistic"
> and do not support or encourage looping and other such programming
> constructs.

Perhaps I misunderstood...Struts includes a Logic taglib, yes? In addition,
it also includes an HTML taglib that allows the actual markup to be
manipulated/generated by tags. These to me go beyond merely inserting "data"
into the presentation layer, and introduce "logic". And from my perspective,
if you are putting logic into templates you are effectively introducing a
scripting mechanism (ie. the tags you reference effectively using the
underlying tag library to "script" how the presentation layer should be
generated).

> 4. Custom tags are valid markup, and provide a TLD to prove it ;-)

Hmmm...I think we have a different definition of "valid markup". For me,
valid markup is HTML or XML that can be validated by a DTD. Templates which
remain "valid markup" in this sense of the word can be easily manipulated by
any standard markup tool (Dreamweaver, FrontPage, etc).

> Barracuda - While most editors and clients will ignore the Barracuda
> extensions, this doesn't make it "valid" markup.

Actually, Barracuda templates remain valid markup at all times since all
they use is id or class attributes (validated by the HTML 4.01 strict.dtd).
For XML, WML, etc. you can specify an attribute name (ie. if 'id' or 'class'
is not a valid attribute).

> 7. Support for skins
>
> The template package bundled with Struts can be used for this, and the
> capabilities are enhanced in the Tiles package.

I would be interested in hearing more about how this actually works. What
I'm especially interested in is how the Action classes would specify the
View...in other words, my conception of "Skins" is that the Controller code
says "render this view" and has no knowledge of what skin actually gets
used. In other words, the skins logic ("for this view use this skin") should
be decoupled from the application logic ("for this action generate this
view"). I'd love to hear how you guys handle this.

> 8. Client capabilities.
>
> Struts itself does not provide any specific features that address this
> area.

I'll throw this out just as an idea...I've been looking a BrowserHawk4J
(http://www.cyscape.com/products/bhawk/javabean.asp), thinking that it'd be
really nice to have an open source implementation of this. Seems like just
about every presentation framework out there could benefit from it...might
make a nice little standalone project  that everyone could work together
on...

> 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.

I'd actually like to take some time and benchmark this...Would you be
willing to help me develop a set of criteria that might correspond to a
typical Struts application (ie. how many reflection calls actually get made
for a typical page). Maybe we could even put together a very simple app (ie.
one screen that pulls data from a statically defined JavaBean) in both
Barracuda and Struts just to see how they compare. I'd be very interested in
trying to quantify just how much of a hit there is (and if there's not, then
I'd like to update the document accordingly).

Thanks for your feedback...
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/


Mime
View raw message