Musings about Tapestry

(and facts about Warp) 

Things I dont like about Tapestry 5

(and T4 where applicable) that Warp will hopefully improve on.

I should mention at the top that I absolutely love Tapestry and am a big fan and supporter of it. I defend it wherever I can and always propose it as a serious option on projects. I dont intend this to be a flame against Howard or Tap. This is just my personal gripe sheet.

  • Case insensitive EL expressions. While I think it's ok to force case-insensitive uniqueness (with a warning or exception), and appreciate that many ppl make a small case mistakes that are an annoyance--I dislike the idea that case doesnt matter at all.
  • Too many injection mechanisms. Tap5's ioc is a bit better (only @Inject and @InjectService) but Tap4 was horrid. The contributions are also a pain to work out. Total violation of the KISS principle.
  • Not enough type safety. Tap5 and 4 make liberal use of annotations (much to my delight) but in trying to be flexible, they all end up being just wrappers around strings. To my mind @Inject("provider:Service") is as bad as using xml (without schema) and completely misses the point of why we moved from xdoclet to Java 5 metadata. Also havent seen much clever use of generics where it is just begging for it (in ObjectProvider for instance).
  • poor documentation. Where do I start on this one? first off there are hardly any docs. Then the docs that are there are often out of date with the code. Then they are wordy and confusing with few examples (why did it take me 15 minutes to learn guice from Bob & Kevin's user guide, or an hour with SpringMVC but I am still struggling with tap4 some 2 years in?). Also the examples that are there are way too basic to be of much help. 
  • this is a cribby one but why the hell does howard name fields with a leading underscore (as in "_field")? It drives me nuts. The braces on their own lines is not as bad, but another source of annoyance for me. There is a reason for the sun coding convention you know. The days of C and indian hill are over.
  • too much naming convention magic. I dont know if this is supposed to be for backwards compat to jdk1.4 (silly ideal if u ask me), but it seems like every method name I choose can be a magical callback hook (buildBlah...() is a good example) if Im not careful. I mean this is where annotations are supposed to rule the day, whats the point of having nine different @Inject annotations if you're not going to use them where they really matter.
  • fields MUST be private. What? why?
  • spring support module can only fetch singletons. huh? 
  • afaics no interception support for page objects (no I dont mean the lifecycle methods, and yes I know services have some basic interception)--I should be able to declare global listeners. Havent figured out how to do it yet if it is available which I doubt.
  • does not scan up the class hierarchy for annotated methods. I know its an annoying thing to program but if you're gonna release us to the world of POJOs we should be able to use them to their potential. Hibernate does this without much trouble, as does guice, spring and many others. It's not much to ask. 
  • apparently too many ways to do certain things. Maybe this is not entirely apparent, but for someone working his way thru tap for the first time--there are just too many options which dont distinguish themselves elegantly enough. For instance, I can't really tell why there is an ASO and an @Persist. Or why there is an ActionLink, PageLink, DirectLink (and Im sure a few others that I cant remember readily) component for generating a hyperlink.
  • This isnt really a gripe but Warp prefers to use the Yahoo UI library to and prototype (that tap uses), that I feel is a much better js library for many reasons. 
  • I am still not terribly convinced about pooling Page objects and cleaning them every request. No matter how efficient the reflection/proxying has gotten.
  • The Tapestry exception page. Yes, this great holy feature of tap is one I find annoying and abstruse. I have read in tons of places how cool and helpful the tap exception page is (mostly on the tap website =), but usually in practise I find it to be a lot of unnecessary information and very confusing. It supposedly tells you exactly whats going on but more often that not I find it gives me a misleading message for my problem. The way it unwraps exceptions is supposedly to give you fine-grained reporting of the error but I find it just ends up being another sort of exception trace I have to learn to read (I have enough fun reading regular ole java stack traces). 
  • Tap5 has this neat feature: dynamic page reloading, which means you can update your binaries (just the page classes) and have tapestry auto-reload them on-the-fly (analogous to JSP reloading). I think its a cool feature, but it means I have to structure my webapp in a specific way for tomcat which took me HOURS to discover (should have gone to the mailing list archives!), which I dont like. And it doesnt work for anything except existing page classes (cant add pages for instance). Not griping--its still an alpha feature after all.
  • Tap5 is built by maven. Oh god do I hate maven. If you want to build tap5 from scratch (as of beta) you have to do awful things with maven that only the bileblog can accurately describe. I had a hard time even building an app that USES tapestry from my IDE (IntelliJ Idea) or by ant. 

Read more: Fun facts about Warp.