Way to trade punches… loved this thread completely. Now I have made my remarks in remote posts on the web about tapestry. And it is really fine to see some nice hits take plase here. ASDF… most likely HLS. Am I a tapestry developer… yes… but everything in these posts are valid to the max.

Would love to see more.

It’s been about a year… can you guys start a few jabs for an update?

Tapernate is a project that exists to tie together Tapestry and Hibernate and to overcome the impedence mismatch between these projects. Unfortunately, it does not solve all of the issues very gracefully. Without this crutch, you can not do lazy loading with Hibernate objects and Tapestry. You can of course do a disconnected object model, but that seems like a lot of work for little or no gain to me.

So, thanks for reading the blog. I hope you can contribute a useful comment at some point.

(actually I met you in Milwaukee at one of my clients when you came in to train them on Tacos)

Yes, I’ve seen and used Tapernate - you showed it to me. :)

Tapernate is a 50% solution for Tapestry/Hibernate issues. You still have to create your own squeezers for drop-down lists, it doesn’t handle collections of persistent objects, etc. I think I’ll write a full blog post about this at some point. Tapernate is a good “inspiration” project for the kinds of things you need to do to intergrate Tapestry and Hibernate, but if you’re doing anything more than the most trivial app, it’s not going to be a full solution.

Hibernate only does persistence, but it does it pretty well. Starting by using Hibernate as your persistence framework is often pretty easy to do. Spring on the other hand is a huge framework, but the advantage of it is that you can start off using just some small pieces of it as you see a need. The easist place to start with Spring is probably using the Inversion of Control (IoC) framework to inject DAO or Service objects into your code. Spring also provides some easy ways to configure Hibernate for transaction boundaries and things like that, so leveraging that functionality is nice next step.

As for Tapestry, as I said, I’m not sold yet on it. It seems to me to be overly complex for a View technology. You need 3 files just to render a page: An XML description, an HTML layout and a Java code behind file. Providing Beans to a JSP page seems much simpler to me for the majority of projects that don’t have professional graphic designers working on them. Even the JSF route offers transparent, bi-directional mapping of Bean properties to form values without having anything but the View page and the Bean.

The combination of Spring and Hibernate offer some really good plumbing to use in an application and to get you started quickly without having to write reams of code. They make the persistence layer trivial and allow you to transparently swap in Mock objects for testing purposes.

Inclusion’s code didn’t use an ORM persistence layer, all of it had to be hand written SQL. It also didn’t map to Objects per-se but was more oriented to field/column level data. When you map to Object/row level data there is a huge opportunity for performance gains since there’s a strong probability that if you use a value from a row, you will use others from the same row and so you can collect them in a single query. Hibernate also provides a caching mechanism that often means you don’t have to explictly code caching which keeps the application logic much simpler.

As an aside, there is a Ruby on Rails inspired framework for java called Trails that is built on top of these 3 technologies. It’s supposed to be a rapid prototyping framework that makes getting up and running with this stuff really easy. It seems that every new release changes things very dramtically, so none of the examples work, and it doesn’t work out of the box on Mac OS X, but it might be an interesting project to keep an eye on.

Also, you helped develop Inclusion’s Tapestry/Hibernate/Spring-like code back in the 1990’s. How would you compare them?

-Frank