Blast from the Past: Tapestry 3.0.5

My current task has put me in an odd mood. A client of Jesse's (Kuhnert) contracted him to make some changes to the Tapestry 3 code base, with me auditting those changes. Jesse has backported some ideas from Tapestry 4 and Tapestry 5: mostly the use of a backported version of java.util.concurrent to improve Tapestry 3 throughput by replacing single-thread synchronized access with concurrent access.

Many of these files haven't really been touched since 2004. It's brought back a lot of memories, such as working on TheServerSide's application.

To my jaundiced eye, the code looks almost primitive; no IoC container, no dependency management, heavy reliance on base classes, a lot of rather naive multithreading.

Overall, I'd say that Tapestry 5 is as far advanced over Tapestry 3 as Tapestry 3 was advanced over Struts. Probably more so. Looking back over this code has given me some perspective.

IntelliJ: Paste...

I discovered this one on the flight home. The Paste ... menu item (Shift-Command-V) raises up a window of recently copied selections on the clipboard.

Handy!

Making Java EE Suck Less

Ben Gidley has posted a medium length blog praising Tapestry 5. He took an interesting tack ... describing the requirements of a useful, useable web framework ... in terms of what Tapestry 5 does. I especially liked "Not require a large bespoke framework to be assembled around the framework."

He ends with:

This is the framework that could save J2EE from being a 'dull' and slow corporate tool and eventually fading as other toolsets come and replace it.

This, to me, hearkens back to how Dave Thomas defined Ajax, early on: It's whatever makes the web browser suck less.

To paraphrase, Tapestry is what makes the entire Java EE platform suck less.

Last week, when I was training in Cambridge, UK I saw a bit of this. The client was gearing up to create a full REST interface around their database access. They were starting to evaluate servers and APIs and think about integrations as well as how to represent object hierarchies and updates inside an XML or JSON structured REST query and response ... and how many more Java representations of entity objects would be required.

... but after working on the examples in the Tapestry Workshop they have abandoned the REST approach (until some external system actually needs access). Instead, they are modeling more of their application on the same light principals as the Tapestry Workshop:

• Inject the Hibernate Session directly into pages, to perform simple queries
• Use the @CommitAfter annotation to handle update operations
• Move common queries (used on multiple pages) to a central, injectable service

This way they are able to leverage a single Java object representation of their database entities, as managed by Hibernate. They can use Hibernate features such as lazy loading and update cascading (things that would be prohibitively more difficult if there were a REST layer between the presentation tier and Hibernate) . This is all possible because Tapestry isn't just a web framework, it's also, because of Tapestry IoC, an integration platform. This allows the integration with Hibernate to be "light and tight".

Coming to Cambridge, UK

I'll be flying into Cambridge, UK for a week of Tapestry training. I'll be there from Sunday through Thursday night before returning to sunny Portland on Friday. Drop me a line if you are a Tapestry enthusiast in the area ... it's always fun to get together for a drink and talk tech.