[Jakarta Tapestry Wiki] New: MovingToTapestry

[ta...@jakarta.apache.org]

   Date: 2004-10-18T15:42:51
   Editor: JordanRedner <jr...@shopping.com>
   Wiki: Jakarta Tapestry Wiki
   Page: MovingToTapestry
   URL: http://wiki.apache.org/jakarta-tapestry/MovingToTapestry

   no comment

New Page:

!!Decision to Migrate to Tapestry

This is from an email I sent today (2004/10/18), someone asked me to post this to this Wiki... so here it is...  I may elaborate and add some more structure to this page at a later date, time permitting...

We are about to release a major rewrite of a legacy app and chose
Tapestry as the framework over Struts.  This was a big move because we
have many Struts developers.  It seems that developers who like to learn
new things, will welcome using Tapestry.  It is true that the spin-up
time is hard for someone that is so used to doing something a certain
way.  In this sense, it might be hard to ever move away from something
if you don't try.

As far as functionality, I don't think there's anything you can't do in
Tapestry that you can do in Struts, it just comes down to the simplicity
of the design behind your application.   

I decided to use Tapestry instead of Struts after a very long design
phase where I was trying to look at things we can do to really gain
development efficiencies.  We have an application to rewrite that has
many pages (50+) with a lot of functionality to implement.  Frankly I
didn't look at too many frameworks other than Struts and leveraging the
use of XML/XSL heavily on top of Struts.  .NET was out of the question.
I didn't want to select something that wasn't tried and true.  Some
friends who I trust pointed me at Tapestry and it didn't take me long to
realize the gains.  I also considered Echo and Wicket but punted due to
maturity.  The fact that Tapestry is a Jakarta project doesn't hurt
getting buyoff either.

I hope this doesn't sound like I've really drunk the cool-aid, but...

The productivity gains and benefits of NOT using JSP seems considerable
to me since your designer/CSS person (if you choose to break that
resource out) can make the mockups and these become the final templates
that are part of the code base.  Last minute design changes, which
always come up, are a non-issue.  In JSP, these would have to be
re-factored.  It seems to me that there is more risk in having last
minute design change in a JSP application.  This alone would have
extended our timeline on this project.

As far as pure code scaling...in terms of an application that may have
hundreds of pages and classes, and having to maintain that code base for
a long period of time by many developers; I believe that a large web
site code base in Tapestry will scale better (in terms of sheer number
of classes and pages) than a JSP Struts application, but only IF your
JSP/Struts discipline is not the greatest.  Collectively over time with
many developers, this seems difficult if you don't use something to
enforce the discipline.  From what HLS says in his book, a primary
design goal of Tapestry was, make it easier to do the right thing than
not.   The maintainability aspect is a benefit of achieving this kind
design goal in my opinion.  Taking JSP out of the equation is a big step
toward this end.  

Like .NET, I really like the design paradigm of backing a Web page with
a Object/Class that extends the framework's base Page class.  The
Tapestry design does this quite directly.  Since I threw .NET into the
mix, I do like Tapestry over .NET because of the template language, it
enforces better separation in the model and the view code (aspx is
analogous jsp).  I've managed a large scale .NET application
(www.quote.com), so I can speak from experience.  To me, the design of
using Actions in Struts doesn't seem as intuitive to me as does the
notion of a class backing a pure Page.  Submits invoke methods on the
class, etc...

After doing a somewhat large multi-lingual Tapestry web app, I believe
it would have taken about 30-50% more time in JSP/Struts due to the JSP
re-factoring of UI requests we would have had to do late in the game.
In Tapestry design changes are non-issues since the mockups are the
templates.  Another reason for taking longer in JSP/Struts would have
been the localization features that we leveraged in Tapestry.  Page
templates themselves can be localized.  Our designer resource quickly
came up to speed in using property files for strings so all of the UI
was done by a design resource, not a traditional web developer.  You can
also do Localized page flow in Tapestry by just populating the next page
as a property.  Since the page property files are localized, you can
have a different next page property for a different locale.


Jordan


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org