Comments on Tapestry for a Struts user?

Hello all,

I have used Struts for the last two years. I am very fond it as a mvc framework. I have come across many positive reviews of the tapestry framework. Many say they have converted from Struts and aren't looking back.

Anyone who has used tapestry care to share their opinion? Whats the advantage?

Regards,

Joshua

I've done Struts (and Tiles) coding as well as Tapestry over the last couple of years. You don't always get to pick your technology when you come into a project late!

Obviously, Tapestry coding is a perfect match for my style, since I created Tapestry, so take my observations with a grain of salt.

I constantly have problems with Struts, even when using XDoclet, manging the configuration. The same artifact is given different names in defferent places ... to include the ".do" suffix or not is often a matter of guesswork.

Certainly, Struts exception reporting doesn't compare to Tapestry's. Struts gives you an NPE and a stack trace ... Tapestry takes you to the line that's in error.

Tiles is worse, an error inside a Tile is often swallowed and you get a blank space where your tile should go and no clue what went wrong.

I found I had a lot of code duplication in Struts. Often, a page would have several different Actions for different purposes (clicking different links or submitting different forms). To redisplay the page required setting up some amount of transient information and storing it into the HttpServletRequest as attributes. In Tapestry, this would simply be well-typed transient page properties and perhaps an implementation of pageBeginRender().

In Struts, I first tried chaining together Actions, so my main Action's forward would be another Action that did the setup. This caused a number of problems and I eventually create a little framework and matching tag library to invoke singletons (that lived in the servlet context) to do the necessary database access and setup.

My co-workers were sloppier than me, and just pushed everything into HttpSession attributes, even when the data was fundamentally transient.

Anyway, basic things like this consumed a huge amount of my time and were difficult to test. No good exception reporting, no good management of transient and persistent server side state, lots of code necessary to move data out of ActionForms (or DynaForms) and into my domain objects ... lots of uncessary pain.