Confusion : Usage of Struts

["Tewathia, Atul" <at...@hpsglobal.com>]

I am new to struts. I have gone thru the theoretical part of struts and
found the concept interesting. Even read thru some examples. 

But there are some doubts like... 

What happens to javascript validations? Where do we fit them in the comlete
picture?
Who takes care of whether is it a normal application or struts application.
does the container do this ?
If we have to code the struts-jsp and a corresponding bean for every form
then where is the convenience ? Are we not trading one problem with another.
Under what circumstances do I need to extend ActionServlet and use that ? 
I have a gut feeling that struts application will be slow as it involves one
extra component at the server side for every single GUI developed ? 

Can some body who is deeply involved with struts development reply.

Thanking you in Advance.

Re: Confusion : Usage of Struts

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

> "Tewathia, Atul" wrote:
> What happens to javascript validations? Where do we fit them in the
> comlete picture?

Client-side validation using Javascript is on the list for Struts 1.1. 

David Winterfeldt has a very nice start on a package that does this at 

< http://home.earthlink.net/~dwinterfeldt/ >.

I'm using it myself now. Highly recommended. It uses regular expressions
to create a Javascript that checks fields in the client (via onsubmit),
and then uses them again on the server-side, in case Javascript is not
available. 

After that, you can subclass the standard validation method and do any
other server-side validation in the usual way.

> Who takes care of whether is it a normal application or struts
> application. does the container do this ?

The Struts framework is used to create standard Web applications. Struts
provides a number of services internal to the Web application, many of
which you would otherwise have to write yourself, and the container
handles the rest. 

> If we have to code the struts-jsp and a corresponding bean for every
> form then where is the convenience ? Are we not trading one problem
> with another.

In practice, you usually end-up writing code for the equivalent of a
form bean anyway. Struts helps you focus that work to get the most out
of it.

> Under what circumstances do I need to extend ActionServlet and use
> that ?

People sometimes decide to do that for one reason or another, but in the
normal course it is not usually necessary.

> I have a gut feeling that struts application will be slow as it
> involves one extra component at the server side for every single GUI
> developed ?

In practice, you may actually have less code and fewer components in a
Struts application than an equally robust Web application using another
approach. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/

Re: Confusion : Usage of Struts

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 21 Mar 2001, Maya Muchnik wrote:

> Craig,
> 
> 1/ If we will have one extra servlet whose main functions are init and destroy
> how this concerns computer resources?

The only extra resource is the fact that this servlet class is loaded,
normally for the life of the web app.  In the case of DatabaseServlet,
that is roughly 6kb.

You can minimize this by subclassing ActionServlet and overriding
init() and destroy() yourself, although you are still going to be
increasing it's size slightly.  You'll only be saving a few bytes.

> And this servlet will be idle?

Yes.

> 2/ Who is calling doGet () method of DatabaseServlet? There is no mapping for
> "database" servlet. Maybe it is automatically?

The doGet() and doPost() methods of this servlet are never called.  All
the important stuff is done in the init() method (which is called when the
web application is started because of the <load-on-startup> setting) and
the destroy() method (which is called when the web app is shut down).

NOTE:  Although most current servlet containers behave as described above,
they are not required to -- it is legal for the servlet container to take
a servlet out of service any time it wants to.  Therefore, using a
separate servlet like this has a slight risk.  It is unlikely that the
controller servlet would ever be removed, because it will be accessed a
lot.

In a servlet 2.3 environment, the recommended approach would be to use the
new application event listener API, because your context listener is
guaranteed to be called at webapp start and webapp shutdown.  However, the
current use of Struts is almost totally on containers that support 2.2, so
this isn't an option for now.

> 
> Maya
> 

Craig

Re: Confusion : Usage of Struts

[Maya Muchnik <mm...@pumatech.com>]

Craig,

1/ If we will have one extra servlet whose main functions are init and destroy
how this concerns computer resources? And this servlet will be idle?
2/ Who is calling doGet () method of DatabaseServlet? There is no mapping for
"database" servlet. Maybe it is automatically?

Maya

"Craig R. McClanahan" wrote:

> > Are we not trading one problem with another.
> > Under what circumstances do I need to extend ActionServlet and use that ?
>
> The answer is application dependent.  Basically, there are two common
> cases:
>
> * I want to initialize some application scope beans that Struts does
>   not already take care of for me.  You can do this by overriding the
>   init() method.
>
> * I want to do some extra processing on every request flowing through
>   the controller servlet.  This can be done by overriding the appropriate
>   processing method to add the extra logic.
>
> In general, I suspect most Struts-based apps will not need to worry about
> this.  The Struts example app gets around the first problem, for instance,
> by creating a second servlet (DatabaseServlet) to do the extra
> initialization and finalization work.
>
>
> Craig

Re: Confusion : Usage of Struts

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 21 Mar 2001, Tewathia, Atul wrote:

> 
> I am new to struts. I have gone thru the theoretical part of struts and
> found the concept interesting. Even read thru some examples. 
> 
> But there are some doubts like... 
> 
> What happens to javascript validations? Where do we fit them in the comlete
> picture?

Current versions of Struts do not automatically generate code for this,
but you can do it yourself by using things like the "onchange" attribute
of an <html:text> element.  The TODO list for Struts 1.1 includes a
feature that can optionally generate JavaScript validation code for things
like required fields, correct date formats, and so on.  Several advanced
Struts users have also done some experimenting along these lines already.

> Who takes care of whether is it a normal application or struts application.
> does the container do this ?

In what respect does it make any difference?  To a servlet container,
every web application looks the same, and Struts just uses all the
standard servlet and JSP APIs.  There is nothing special about it from the
container's point of view.

> If we have to code the struts-jsp and a corresponding bean for every form
> then where is the convenience ?

There are lots of answers to that question.  Two of them are:

* Consider what else the form tags do for you (redisplay the
  previous values on errors).  Now, try to write out the plain
  JSP code it takes to do that, and compare.

* What alternative design are you considering?  For most people,
  it is something like "put the processing code into the same
  page as the form".  Now, if you ever have to change the visual
  appearance you also are messing with the business logic.


> Are we not trading one problem with another.
> Under what circumstances do I need to extend ActionServlet and use that ? 

The answer is application dependent.  Basically, there are two common
cases:

* I want to initialize some application scope beans that Struts does
  not already take care of for me.  You can do this by overriding the
  init() method.

* I want to do some extra processing on every request flowing through
  the controller servlet.  This can be done by overriding the appropriate
  processing method to add the extra logic.

In general, I suspect most Struts-based apps will not need to worry about
this.  The Struts example app gets around the first problem, for instance,
by creating a second servlet (DatabaseServlet) to do the extra
initialization and finalization work.

> I have a gut feeling that struts application will be slow as it involves one
> extra component at the server side for every single GUI developed ? 
> 

JSP pages are translated into servlets by the container, and then compiled
into normal Java bytecodes.  A custom tag, then, is translated into a few
property setter calls, followed by calls to the tag's doStart() and
doEnd() methods - same as calling any other object's methods, and
(depending on what technology you might use instead of JSP) probably
roughly the same number of method calls as whatever else you might be
doing.

The overall performance of a JSP page, though, is most influenced by how
much optimization the code generator does.  Tomcat, for instance, is at
the simplistic end of the scale, and does almost no optimization.  Some
other containers have been benchmarked to run exactly the same page, on
exactly the same hardware, 3-5 times as fast.

Of course, one advantage of using JSP technology in the first place is
that you have this choice of alternative implementations competing for
your business, without having to change your code at all.

> Can some body who is deeply involved with struts development reply.
> 

The best way to address your concerns would be to try a small pilot
project using Struts, along with whatever other technologies you are
considering.  For some folks, Struts won't be the right answer -- but
there are no blanket rules that really defines the difference.

My bet is that, after you've done this, it will be what the old
TV commercial says, "try it, you'll like it".  :-)

> Thanking you in Advance.
> 

Craig