advantages of Struts

[Iraklis Kourtidis <ik...@covia.com>]

Hi fellow Struts users,

I wanted to start a small discussion on something very general: what Struts
gets you over embedding scriptlets in your JSPs (i.e., Struts vs. no
Struts). I know, it's Friday, so we should all be going home... anyway, here
goes it:

Given my (limited) experience in developing a small application, what I
personally see as the biggest advantage is the following:

* Action classes can run the code that would normally get executed as a
scriptlet in a JSP (or as glorified function calls through tags).
* The Action classes place a bunch of beans on the request/session.
* The JSP then runs and displays the information stored in these beans,
possibly using logic:iterate.

One disadvantage that I see is that all the communication from the action
classes to the JSPs happens through beans placed on the request/session. A
JSP-only solution would display the information directly without making
beans out of it (and without the necessary java bean classes to represent
information that gets sent to a JSP in the form of a bean.)

At any rate, I like the fact that Struts makes it possible to completely
remove any code from the JSP files, which makes it easier for the design
staff to modify layout etc. etc. I know, you don't need Struts to do this,
but in reality if you look at most JSPs out there, you'll find a ton of
scriptlet code in the JSP (I've been heard of threads being started inside a
JSP...) So Struts makes it easier for me to separate the presentation from
the code behind it.

I am curious about how (and why) the rest of you gain from Struts.

enjoy the weekend,
Iraklis

Re: advantages of Struts

[Ted Husted <hu...@apache.org>]

I think the best discussion of "Why we need Struts" is summed up in
Jason Hunter's. article regarding the difficulties with JSP Model 1
applications. 

< http://www.servlets.com/soapbox/problems-jsp.html >

What all this boils down to is that Struts gives you a place to stand. 

Without a controller, a Web application is a breathless stream of views. 

With a controller, a Web application is a series of requests and
responses, as HTTP intended. The views request and an action responds
with another view. Ideally, your views become scriplet-free "JavaBean
Pages", that could be easily edited with a visual Java 2 Web editor (at
least as soon as we get one!). 

A MVC application like Struts does force you to be more organized, and
does compels you to define objects that in a model 1 application may
only be implied. But the objects are still there and so is the work.
It's just whether you want to spend your time defining JavaBeans or
cutting and pasting code snippets between JSPs. 

The next big step will be to integrate rowsets into Struts. If we can
use rowsets where we use JavaBeans now, we can drop a layer of
abstraction, and actually gain both flexibility and functionality. Many
actions then become very simple adapters that just retrieve a rowset and
pass it to the request. The Struts forms could then read and set the
fields on the rowset, and the rowset could be used to update the model
directly when it was returned. No additional hand-offs. The best thing
here being that rowsets can work with any tabular data, not just JDBC.

< http://developer.java.sun.com/developer/earlyAccess/crs/ >

Sadly, the current Sun implementations require transactions to update a
JDBC table, and the (default) MySQL tables still don't support
transactions. I tried turning transactions off       
(setTransactionIsolation(TRANSACTION_NONE), but it just laughed and
tossed the exception anyway. So right now, I'm using rowsets for
retrievals, and conventional connections for insertions. In between, I
dump the rowsets into JavaBeans, but hope to skip that step soon and
send the rowsets directly to the JSPs.

Iraklis Kourtidis wrote:
> 
> Hi fellow Struts users,
> 
> I wanted to start a small discussion on something very general: what Struts
> gets you over embedding scriptlets in your JSPs (i.e., Struts vs. no
> Struts). I know, it's Friday, so we should all be going home... anyway, here
> goes it:
> 
> Given my (limited) experience in developing a small application, what I
> personally see as the biggest advantage is the following:
> 
> * Action classes can run the code that would normally get executed as a
> scriptlet in a JSP (or as glorified function calls through tags).
> * The Action classes place a bunch of beans on the request/session.
> * The JSP then runs and displays the information stored in these beans,
> possibly using logic:iterate.
> 
> One disadvantage that I see is that all the communication from the action
> classes to the JSPs happens through beans placed on the request/session. A
> JSP-only solution would display the information directly without making
> beans out of it (and without the necessary java bean classes to represent
> information that gets sent to a JSP in the form of a bean.)
> 
> At any rate, I like the fact that Struts makes it possible to completely
> remove any code from the JSP files, which makes it easier for the design
> staff to modify layout etc. etc. I know, you don't need Struts to do this,
> but in reality if you look at most JSPs out there, you'll find a ton of
> scriptlet code in the JSP (I've been heard of threads being started inside a
> JSP...) So Struts makes it easier for me to separate the presentation from
> the code behind it.
> 
> I am curious about how (and why) the rest of you gain from Struts.