tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vy Ho <>
Subject Re: <If> STRUTS</If>
Date Thu, 10 Apr 2003 07:48:27 GMT

Thanks all for your comment.

No doubt in my mind that Struts is better to use than unstructured JSP. 

There are couple things in my mind though:

1) Can I create MVC app without using Struts, such as separate my logic 
out from the JSP (I know, there was an example that show there are cases 
using struts reduce the code down dramatically, so this lead to a 2nd 

2) With the complicated web nature, and the complicated Struts (with my 
thought on the first post), isn't there some room for easier to learn, 
and quicker to adopt technology than Struts (Which may not exist yet).  
This question is silly by itself, but please give me time to explain.  
What I try to ask is that is there a currently existed technology that 
is much better than struts, or is it very forseeable that such a 
technology can be develope in a near future.  (Sure, Struts is not 
perfect, and can be improved, but I am talking a big change, not an 
improvement here).

3) Can you give me a good example of use for Struts?
My list of guesses (please comment on each, and give extra if you have time)

a) The follow can be easily done by JSP without Struts:
    - Reservation system web app?
    - Email app (such hotmail)?
    - Shopping cart?
    - Corporate website (such as customer support area).
b) No, the above are too simple:
    - Nuclear explotion simmulation (or extraterrestrial life search)
    - Multi player (webase) app (like dungeon type, or sim)
    - Webase collaboration (such as 1000 people working on a same document)
c) No, it's the ability to easily add GUI functionality to IDE that 
generates Struts apps
d) It depends on  how the app works:
    - Application that uses alot of sessionings
    - Application that uses alot of customization (personalization)
    - Application that changes all the time (like a news service such as
    - Application that is extremely large, and structural (not a list of 
1000 pages, but 1000 pages structurally, and display depends on the 
current state).
    - Application that is highly interactive (with users)
    - Application that was moved from desktop client to the web client.

Please don't say all of the above, because I know Struts can do all 
that.  Just the one that makes Struts a big differentiator.

Again, thanks all.  If you have time, please share.  If not, please 
ignore.  I know, I just want to discuss ideas, and learn a bit from your 
experience.   You can always ask me to search for the information on the 
web.  But getting information interactively from people who knows it 
best is something I don't like to pass up.

Dan Tran wrote:

>I once b4 got introduced to WEB using JSP.  It was a horrible year of my
>life supporting a jungle of code mixing presentation and bussiness logic
>When I read about MVC, then MVC2 with Struts, I never turn back.  The speed
>that I can crank jsp screens becomes unimaginable.
>Of course I paid some high price at the begining but with confident since I
>have ton of smart ppl on struts-user list to back me up.
>----- Original Message -----
>From: "Dan Allen" <>
>To: "Tomcat Users List" <>
>Sent: Wednesday, April 09, 2003 7:17 PM
>Subject: Re: <If> STRUTS</If>
>>Vy Ho ( wrote:
>>>This maybe off topic a bit.  However, I think the audience of this
>>>mailing listing probably the best place to ask.
>>>First, I am sorry to those who feel offended by this.  This is just pure
>>>technical discussion, no mean to offend any one.  Opposite view is
>>>I tried out couple tutorial of STRUTS. My feeling is that this technolog
>>>is overly complicated.  It's like killing an ant with a machine gun.
>>>It takes so much to just output a "hello world" web page the STRUTS way.
>>>Yes, one may argue that "hello world" example is just an illustration,
>>>you reap the benefit when the project is big.  Yes, I see.  But, my
>>>impression is that STRUTS does not scale well in the learning curve or
>>>amount of work.
>>>Here is what I mean:
>>>If you look at C, C++, Java, Model View Controller, SQL, database (such
>>>as JDBC) techonologies, they scales very well with the learning curve.
>>>If you want to do little, it's little to learn, and very little to do to
>>>get it to work (couple lines of code, couple things here and there).
>>>Struts is different.  In solving the real world problem, no question
>>>about it (because I don't have much experience with it), but in learning
>>>curve, and amount of work, it does not scale well for small app.
>>>This implies:  if you want to build a hello world, then use perl, or
>>>simple jsp, dear.  But once your app get biggers, then use Struts.
>>>I wonder if there's other technology that makes this easier.  (tutorial
>>>from Sun's new tag support does not seem to alleviate much).
>>>In summary, killing an ant, or an elephant, struts would do it.  But
>>>learning to hold the strut gun won't be easy or simple or quikc  for
>>>whatever you want to do.
>>What you have to understand is that it isn't struts that is
>>complicated, it is that nature of web services, namely browser
>>requests.  Since this type of model is more random then a
>>well-defined desktop application, it is necessary to take more into
>>consideration when dealing with one.  You can of course forget all
>>that and write a very insecure, very non-extensible page which might
>>be good for a homepage, but it just won't do for an app.  For those
>>of use used to programming in the web environment, struts is a
>>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>Daniel Allen, <>
>>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>Microsoft's Law of Software Engineering:
>>Don't worry if it doesn't work right.
>>If everything did, we'd be out of a job.
>>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message