RE: Struts vs. custom controller servlets

Disclaimer: I'm one of the Struts developers, so I'm a little biased. ;-)

Some other points to consider, in addition to those Gabe mentioned:

* The Struts config file isn't useful only for tools. It allows you a great
deal of flexibility in (re-)configuring your webapp without having to change
Java code or JSP pages. For example, you can change the action a form
submits to without having to edit any JSP pages which reference that action.

* Form beans provide a good place to do validation of user input before it
ever gets to an action. If you determine that the input is invalid, Struts
will automatically take the user back to the input page, prefill the form
with the original values, and display any error messages. With Struts 1.1,
you can use dynamic form beans and the validator, which means that you can
define the form beans and the validation rules entirely in XML.

* Struts can automatically detect the user's locale, and transparently pick
up the appropriate resource bundle(s), with no code required on your part.

* Struts has an integrated package (Tiles) which allows you to templatise
your JSP pages in a very flexible manner, allowing for easy reuse of page
layouts, and portions of them, across your application.

* Your company has a much higher probability of being able to hire people
who have experience with Struts. The struts-user mailing list is the second
most populous mailing list in all of Jakarta, with almost as many members as
the tomcat-users list. If you roll your own framework, you'll have to train
anyone you hire in the use of that framework.

Those are just a few things off the top of my head. If you want to know why
so many people *do* use Struts, I'd suggest asking the folks on the
struts-user mailing list. ;-)

Note that we are currently committed to supporting Servlets 2.2 and JSP 1.1
environments for Struts. There are certainly many things we could do
differently in a 2.3/1.2 or 2.4/2.0 world, but there are many people who are
not in a position to migrate to those yet. Also note that many of the JSTL
tags (core and fmt) were heavily influenced by the Struts tags, so without
Struts, you may not have seen a JSTL of the same maturity first time out of
the box. And Commons BeanUtils originated in Struts, too. :-)

--
Martin Cooper
> -----Original Message-----
> From: Hoeller Juergen [mailto:juergen.hoeller@xxx.com]
> Sent: Wednesday, August 14, 2002 7:08 AM
> To: resin-interest@xxx.com
> Subject: Struts vs. custom controller servlets
> 
> 
> Hi MVC fans,
> 
> For a while, I have been studying Struts quite thoroughly. 
> And frankly, I am still not convinced that it is really 
> superior to a custom controller servlet approach with JSTL as 
> tag library.
> 
> OK, the well-defined struts-config.xml might be well-suited 
> for tool support. But basically, writing a Struts action is 
> as much work as writing a custom controller servlet. Instead 
> of mapping each action in struts-config, you just have to map 
> each controller servlet in web.xml.
> 
> You can easily handle form beans without Struts ActionForms. 
> You can use Jakarta Commons BeanUtils for populating your 
> beans. And you are free to use any existing bean without the 
> need to derive from ActionForm, you can even use more than 
> one bean per form if you want. The only drawback that I can 
> see is that you have to code the form including form bean 
> getters yourself instead of using Struts tags, but that is 
> not too hard using JSTL and its expression language and even 
> less code with direct EL support in JSP 2.0.
> 
> ActionForward definitions can easily be replaced by init 
> parameters for the forward URLs of your custom controller 
> servlet. Global forwards, if you need them, can be put into 
> context parameters. For convenience, a controller servlet 
> super class with an abstract "ActionForward 
> performAction(HttpServletRequest)" (ActionForward being just 
> an inner class of this super class, consisting of path and 
> redirect flag) and a populateBean method is just a few lines of code.
> 
> In the meantime, due to refactorings because of their new 
> "modules" (?), Struts 1.1 has a lot of deprecated 1.0 code. 
> Besides, there are some definitions and helper classes that 
> IMHO just don't make sense in a Servlet 2.3 + JSTL 
> environment, like the application resource bundle (use JSTL 
> i18n instead) or DataSource support (use your container's 
> JNDI instead). Why bother with all this stuff if I can also 
> use custom controller servlets with just a single base class 
> to care about?
> 
> A word about WebWork as an alternative to Struts: The basic 
> arguments still apply. And why use WebWork's expression 
> language if there is JSTL's EL (which will soon become JSP 2.0's EL)?
> 
> Did I miss something? Do I stick to KISS too much? I'm 
> currently trying to lay down basic guidelines for web app 
> development in my team, and I'd love to hear your comments!
> 
> Regards,
> Juergen
> 
> ----------------------------------------
> Juergen Hoeller
> Senior Software Engineer
> mailto:juergen.hoeller@xxx.com
> 
> INFONIQA Informationstechnik GmbH
> Traunufer Arkade 1
> A-4600 Thalheim bei Wels
> Tel.: +43 (0) 7242 9396 3419
> Fax:  +43 (0) 7242 9396 3312
> http://infoniqa.com * http://ec2use.com
> 
>