Creator of the Apache Tapestry web application framework and the Apache HiveMind dependency injection container. Howard has been an active member of the Java community since 1997. He specializes in all things Tapestry, including on-site Tapestry training and mentoring, but has lately been spreading out into fun new areas including functional programming (with Clojure), and NodeJS. Howard is a DZone MVB and is not an employee of DZone and has posted 80 posts at DZone. You can read more from them at their website. View Full User Profile

Why Choose Tapestry?

06.17.2009
| 5220 views |
  • submit to reddit
I recently had an e-mail exchange with a Tapestry user; after congratulating me on creating Tapestry, he went on with the following observation on his organization:
The company I work at unfortunately chose JSF for their big app. The reason was that Tapestry was "brittle" in the sense that, if one developer breaks something, on a page or a service, very often the whole site won't come up because the initial registry startup will fail. Or for example, if page A has a pagelink to page B, and page B is broken, then page A won't render. While I agree that we shouldn't ship unless the whole app is working, this is a thousands of pages big app with hundreds of mediocre (as in likely to break things) developers. They'd rather have 80% of the thing working than nothing at all. I never thought of this for my own projects, and haven't had the time to examine the truth of their claims. What's your take?

I provided the following response:

Early failures are absolutely, 100%, the only path towards code quality. You may have heard the phrase "no broken windows" (see "The Tipping Point" by Malcom Gladwell for more details) but the short form is that when errors go uncorrected (whether they are broken windows in an abandoned building, or broken code in an application) they tend to multiply quite rapidly.

The things that will "break" a link from page A to page B are substantial problems such as invalid templates, references to unknown properties or components, or compile errors in the page B class ... things that no other developer should ever see when page B's developer is working and checking in code. That is, problems that should never be checked into trunk, but instead kept in a local workspace or a private branch.

An organization that thinks that fail early is a problem is an organization that isn't prepared to develop a large application in any technology. The image I'm getting is one where there is no build server, no continuous integration, at best CVS for source code management (or possibly one of those "shared directory" monstrosities) .... i.e., a chaotic environment where errors are allowed to be checked in to the trunk and can go unnoticed for some time.

The solution to coding errors in pages or components is not to wait until your testers (or end users) find the bugs, but to identify and fix the bugs early. That's called "engineering discipline" and the reality is that even self-professed "mediocre" developers can do it. Tapestry helps because it fails early and has great exception reporting to guide you right the problem so that you can fix it.

Another factor here is enforced helplessness. If only Fred understands page B and he's out when it's broken, then all development stops waiting for Fred to get back. I hit this problem myself, years ago working on a large Struts application (those words give me the heebie jeebies now!). We had lots of code, a fragile and slow build process, and many little code "fiefdoms". I spent too much wasted time twiddling my thumbs.

Nobody should "own the code"; if page B is is broken, Julie (who normally develops page A) should be free to fix it. Julie will need to understand the page B code well enough to fix it, but also you need an overall environment with shared source, no repository locks (that is, nothing that says "Only Fred can change this file"), and no management PHB's getting in the way. Pair programming is the best way for Fred and Julie to share knowledge so that they can understand each other's code. Even if pairing occurs only part time, it's very effective at knowledge transfer as well as ordinary coding.

The idea that "mediocre" developers should use JSF as it is more tolerant of errors is absurd! Tapestry 5 is designed to improve productivity for all developers, by streamlining, simplifying, being smart and being concise ... not to mention live class reloading and best-of-breed exception reporting, which makes it fast to identify and fix those errors.

If your doctor tells you to eat less red meat, that doesn't mean you should switch to a diet of fried chicken three meals a day! Likewise, if you have concerns with code quality from your developers, you should not switch to a less agile, more code-intensive, less supportive development model and hope to catch all the bugs in QA. Sweeping problems under the rug is never a winning strategy.

Coming down off my soap box, I should also add that Tapestry 5.1 works a little bit differently than 5.0 in this respect, so it does (in fact) defer more of the page loading and validation until a link is actually clicked. This is more for performance reasons than to shield developers from application problems. Even in 5.0, the loading and validation was the "reach" from page A to pages explicitly referenced (usually via PageLink during the rendering of page A), so it's a highly unlikely case that a single error in a 1000 page application will keep the application from starting up, unless the start page of the application links to all 999 other pages.

Re-reading the above post I can't emphasize enough: you can't ignore quality problems. Quality problems lead to development failures, schedule slips, missing functionality, low morale and high turnover. Saying "we don't have time to fix the quality problem first" is to ignore the second law of Thermodynamics. You are expecting a miracle, literally writing it into your project plan.

Formos addresses this issue two ways: First, we use Scrum and deliver on (typically) 4 week cycles. Thus we set real deadlines and have a constant check on quality (we're providing working code constantly). We don't even try to predict what we'll be doing six months or two years from now, we just deliver a steady, manageable stream of software.

Secondly, Formos uses Tapestry precisely for all the reasons that the anonymous developer's organization rejected it, and for many, many more reasons besides.

From http://tapestryjava.blogspot.com

Published at DZone with permission of Howard Lewis Ship, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andy Gibson replied on Wed, 2009/06/17 - 2:20pm

This rather seems like responding to a complaint that a car doesn't go very fast by lecturing that nobody should be driving over 60mph. While that is usually true, it doesn't excuse a car not being able to go 80mph because of a faulty design or implementation. There are valid times in the real world when you want to deploy a project containing broken code, after all, nobody said it had to be deployed into production.

If this is the way Tapestry must work, then fine, if not, how about a configuration setting to allow broken deployments. Either way, lets not sidestep the issue by questioning the professionalism or integrity in those that dare not like it, and dressing it up as a an advantage to 'keep you legal' .

Howard Lewis Ship replied on Wed, 2009/06/17 - 3:09pm

Andy,

Tapestry lazy loads everything: services, pages, components, etc.  So, in fact, it will be quite capable of  dealing with incomplete or incorrect pages, components, templates and so forth. The only substantive difference between Tapestry and JSF in this area (beyond how much more concise Tapestry is), is that Tapestry is more likely to detect a failure in a target page when rendering a link to the page, rather than (as with JSF) when the request for the target page is exercised.

However, my basic statement stands; the organization was admitting to a significant quality problem ("mediocre programmers" and "20% of the application may be broken at any time") and not addressing the quality problem but instead looking for a patchwork solution that allows broken code to "limp along" with the hope that underlying errors will be found by QA. Further, they were choosing a technology that has sigificantly steeper developer requirements (more and more complex Java code plus additional XML configuration to implement the same use cases coupled with inferior exception reporting and no live class reloading) merely because it will defer crashing the application by a click or two.

That's just sweeping the problem under the rug. And again, an organization that disregards quality to that degree is highly unlikely to deliver an application to the projected size (more than 1000 pages) in any technology. 

David Lee replied on Wed, 2009/06/17 - 9:25pm

It's hard to argue that there is a better web framework than Tapestry 5. You see T5 and then something like Groovy and you have to scratch your head as to why Sun never hired you guys on and tossed some of the misguided efforts like JSF and JRuby(jruby is good, but groovy is a better fit for java developers). Anyways....I too tried to sell my company on Tapestry5 and failed for 1 main reason: Documentation. Simple things are extremely simple in T5, but because T5 introduces new concepts that are different in significant ways for say Struts developers, good documentation is required to bridge the gap. The website and wiki are good, but not really good enough. Examples are on the web, but .....my point is IT shops are big on support. I've seen many decisions made based on the support offerings rather than the product being evaluated. Documentation is a form of support and because T5 support is considered weak relative to others like JSF, Grails or even Wicket we (much to my disappointment) don't use Tapestry 5. T5 needs a really good book that covers going from Struts and/or Servlet API to T5. Or Follow the Grails documentation model. It's not 100% comprehensive, but imo it's good enough.

Otengi Miloskov replied on Thu, 2009/06/18 - 12:12am

Im agree with David, T5 need a book, I have saying this to HLS here and in the TSS that he needs a new T5 book from manning or even Apress. Without good docs it will fail. Of course the support should be there but for that need people that learn and support T5 and thats with Docs and Books. Wicket have a couple of books and good docs so it is what Im using right now but if T5 get a book I will jump on.

By the way there is a an awesome and easy framework incubating in Apache and it is Click framework, The docs and the examples rocks, Im playing with it and maybe in my next project, I will use Click Framework.

Howard please instead of playing with Clojure hehe better write a book on T5.

 

sub online replied on Fri, 2009/06/26 - 2:49am

Keep it down! You kids are too loud! Keep it down.links of londonYou lie.Tiffany JewelleryIt's a classic.Don't be so stubborn.links of londonBetter luck next time.Just shoot me.Shake like jelly.I've got nothing to lose.Who would be so dumb!There's still hope. A: Don't worry. There's still hope for you.How should I say this? Pick on someone your own size.You only live once.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.