Nov 16th, 2006, 05:52 AM
IMO, tapestry sucks at almost any level.
1. non-surprisingly it uses Hivemind ( *embedded* IoC container) where the DI happens based on a CGLIB code enhancement of your abstract classes making the later quite difficuilt to unit-test
2. the API is bound to the HTML only. You could find a method description like: "this method prints out the text in RED"!!!
3. All *low-level* servlet-API objects are wrapped into some bizzare tapestry classes, which appear to be almost useless.
4. The promised ease of HTML-coding wears out immediately, if you start divide you templates into re-usable parts. For a Java-unaware web-designer it turns into a nightmare, as soon as he would need to mock each and every module.
The conclusion: the tapestry is good only for trivial HTML-based apps.
Unfortunately, we are employing it now, but I'm struggling to getting rid of it and switch to Spring MVC + WebFlow.
Nov 16th, 2006, 11:25 AM
I'll stick up for Tapestry (a bit at least). It has problems, but I don't think the ones that Injecteer mentions are terribly significant. Unit testing is actually quite easy with the tools provided by Tapestry / Hivemind, and in fact it is easier given the abstraction from servlet domain which gives the "bizarre tapestry classes" some context.
However, I totally agree that HTML templates do not deliver on the advertised goals. Any reasonably complex component or component library will quickly bring the HTML back into the domain of the Java developer again. Plus it doesn't even produce valid HTML, except possibly against the very loosest DTD, which these days is a drag.
The most interesting feature of Tapestry is shared with JSF, viz: it is a component-based, event-driven architecture. This should be enough to make anyone sit up and listen. Unfortunately I think there are some problems with the way that Tapestry is implemented, but that is not to say that the idea is bad.
And Webflow could be the answer to all our prayers, I guess. Or maybe JSF. Or both.
Nov 16th, 2006, 12:34 PM
Any references/pointers about the integration of WebFlow and JSF ?
Originally Posted by david_syer
Nov 16th, 2006, 09:05 PM
well, I agree with David, that those tapestry's probs are not very significant, but annoying.
Recently I took over a wep-app, where the front-end is written in tapestry. That looks, umm... strange.
Imagine, you have a single hige and chaotic JSP page, where there a lot of java-code, that accesses all your services, including the database directly. Then, the whole mess is converted into a tapestry structure, and the *funniest* point here, that the mess REMAINS! For example the following objects get injected there via DI:
- a couple of DAO's
- a hibernateTemplate
- a TransactionManager
- the Spring context itself!!!
the other pages (40+) have pretty much the same layout.
So, after looking at the system, I got a feeling that tapestry doesn't really encourage developers to write nicely layered code.
Another major drawback is that the MVC's Model and Controller are tightly bound together in tapestry. That means that the controller gets bound to the HTML and tapestry's UI-elements.
Another concequence is, you cannot change not only the media/format, but also the presentation technology.
Another limitation of a controller I saw in an implementation of a wizard. The guy to enable sequence navigation put something like:
pageBean.setPage1( false );
pageBean.setPage2( false );
pageBean.setPage3( true );
pageBean.setPage4( false );
pageBean.setPage5( false );
and had to repeat it on every wizard's page.
I'd use an existing wizard-enabled controller here, like Spring's one, but with tapestry you cannot use a controller and view technology other than tapestry's own ones!
btw, some more about those 'bizzare tapestry' wrappers. A simple example: in my web-app I have 2 tapestry servlets, serving two independant sub-apps. Then I had to set a non-default session timeout for one of them.
In a plain servlet I'd make it with session.setMaxIncativeInterval(), but in the tapestry wrapper this method is not available. So, I had to split the web-app in 2 applications only to enable different timeout values.