You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Bryan Field-Elliot <br...@netmeme.org> on 2001/04/12 05:12:07 UTC

A quick Struts project post-mortem

I'm just wrapping up a fairly major project which was built on top of 
Struts (thereby giving me a chance to learn it). I'm a little mixed 
about the experience, not being entirely sure the value add was there. I 
definitely feel "helped" by Struts' form validation infrastructure, and 
I would probably appreciate the message resource bundling more if my 
application needed to be internationalized (which it didn't). On the 
flip side, the Action/ActionMapping system, while elegant, only covered 
about half of my application (since I had to write roughly as many 
custom JSP tags as I did Struts actions). Lastly (and this last comment 
is independent of Struts), I've come to the conclusion that a strict 
adherence to the MVC pattern is by no means a magic pill to perfect 
application manageability.. that is, plenty of worms still manage to 
crawl out of the woodwork, and I have a sense that the Java community 
needs something more than just a good MVC system in order to build an 
elegent (and robust) web application.

The application was also based upon EJB, for even more fun and complexity.

On the tags vs. actions dilemma - I took the approach recommended in 
various other publications etc., which is:

1. if the Java code will alter your Model, then put it in an Action (or 
equivalent).
2. if the Java code is only reading your Model to aid in rendering some 
portions of it, the put it in a custom JSP tag.

Some quick metrics and "factoids" about my project:

1. 19 Struts actions
2. 18 custom JSP tags (for which I could find little in Struts to add value)
3. 15 ActionForms
4. 13 database tables
5. Since the application uses EJB session beans for all business logic, 
virtually all of the Struts actions as well as JSP custom tags ended up 
being very shallow pass-throughs of parameters to the EJB bean, and 
return values back to the JSP pages.

I'm wondering if there are others out there who have finished projects 
and reached similar conclusions as mine (in particular, about having to 
implement lots of Tags and not finding much value-add in incorporating 
Struts classes into them).

I am also interested in someone graciously providing a birds-eye view of 
Struts and Turbine, with relative strengths and weaknesses. I'm sure 
that, on the whole, Turbine probably has a completely different "central 
focus" than Struts (apples and oranges), but as someone who is just 
coming off a Struts project and is a bit daunted by the Turbine "welcome 
literature" (as I was initially with Struts), I would sure love 
someone's overview from a Struts-centric perspective.

Lastly, I'm not leaving this group, as I am responsible for managing the 
lifecycle of the application I've described above, even though 
development is basically "done" (for now!).

Thanks,

Bryan


RE: A quick Struts project post-mortem

Posted by Christian Cryder <ch...@enhydra.org>.
Bryan,

> I am also interested in someone graciously providing a birds-eye view of
> Struts and Turbine, with relative strengths and weaknesses. I'm sure

You might check out these
http://barracuda.enhydra.org/Barracuda/docs/landscape.html
http://barracuda.enhydra.org/Barracuda/docs/events/sample_presentation_flows
.html

but keep in mind they're a little dated and may not provide the level of
detail you're looking for. If anyone can make these better please let me
know and I'd be happy to update it...

> I have a sense that the Java community needs something more than just
> a good MVC system in order to build an elegent (and robust) web
> application.

I would contend that there's a big difference between Model 2 (which is
"MVCish") and MVC (in the Swing sense, where you have strongly typed "model"
interfaces, etc). In Barracuda we're trying to provide both: Model 2 event
dispatching for flow control, plus strongly typed MVC UI components for
actually manipulating/rendering client views. Whether or not it yields
better mileage probably depends on your specific problem domain...

Christian
------------------------------------------------
Christian Cryder
christianc@enhydra.org
Barracuda - Open-source MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
        "What a great time to be a Geek"

> -----Original Message-----
> From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
> Sent: Wednesday, April 11, 2001 9:12 PM
> To: struts-user@jakarta.apache.org
> Subject: A quick Struts project post-mortem
>
>
> I'm just wrapping up a fairly major project which was built on top of
> Struts (thereby giving me a chance to learn it). I'm a little mixed
> about the experience, not being entirely sure the value add was there. I
> definitely feel "helped" by Struts' form validation infrastructure, and
> I would probably appreciate the message resource bundling more if my
> application needed to be internationalized (which it didn't). On the
> flip side, the Action/ActionMapping system, while elegant, only covered
> about half of my application (since I had to write roughly as many
> custom JSP tags as I did Struts actions). Lastly (and this last comment
> is independent of Struts), I've come to the conclusion that a strict
> adherence to the MVC pattern is by no means a magic pill to perfect
> application manageability.. that is, plenty of worms still manage to
> crawl out of the woodwork, and I have a sense that the Java community
> needs something more than just a good MVC system in order to build an
> elegent (and robust) web application.
>
> The application was also based upon EJB, for even more fun and complexity.
>
> On the tags vs. actions dilemma - I took the approach recommended in
> various other publications etc., which is:
>
> 1. if the Java code will alter your Model, then put it in an Action (or
> equivalent).
> 2. if the Java code is only reading your Model to aid in rendering some
> portions of it, the put it in a custom JSP tag.
>
> Some quick metrics and "factoids" about my project:
>
> 1. 19 Struts actions
> 2. 18 custom JSP tags (for which I could find little in Struts to
> add value)
> 3. 15 ActionForms
> 4. 13 database tables
> 5. Since the application uses EJB session beans for all business logic,
> virtually all of the Struts actions as well as JSP custom tags ended up
> being very shallow pass-throughs of parameters to the EJB bean, and
> return values back to the JSP pages.
>
> I'm wondering if there are others out there who have finished projects
> and reached similar conclusions as mine (in particular, about having to
> implement lots of Tags and not finding much value-add in incorporating
> Struts classes into them).
>
> I am also interested in someone graciously providing a birds-eye view of
> Struts and Turbine, with relative strengths and weaknesses. I'm sure
> that, on the whole, Turbine probably has a completely different "central
> focus" than Struts (apples and oranges), but as someone who is just
> coming off a Struts project and is a bit daunted by the Turbine "welcome
> literature" (as I was initially with Struts), I would sure love
> someone's overview from a Struts-centric perspective.
>
> Lastly, I'm not leaving this group, as I am responsible for managing the
> lifecycle of the application I've described above, even though
> development is basically "done" (for now!).
>
> Thanks,
>
> Bryan
>