If you want a good web framework for Java, try Wicket. Components are real objects written in standard java, and proper separation between logic and presentation is enforced (because wicket markup files can't contain any logic).
If you want a good web framework for Java, try Wicket. Components are real objects written in standard java, and proper separation between logic and presentation is enforced (because wicket markup files can't contain any logic).
Tapestry is a reimagined WebObjects framework, and the company I worked for originally specialised in these systems, so it was natural for them to pick Tapestry. I also did a lot of translating/transplanting code from a WebObjects system to a Tapestry 4 system and everything the parent says was true for me. Work on a single component is spread across a minimum of three files, sometimes four, and there is a lot of magic which makes debugging (something you'll have to do a lot) a nightmare. I suspect Tap5 is incompatible and a wholly different beast to Tap4, but to this day I never want to work on a Java based web framework. Give me a pile of rotten php spaghetti any day of the week.
That said, I'm loving Clojure and might investigate Noir at some point in the future.
I might be getting a bit too evangelical here, but Wicket will change that. It actually uses the Java type system the way it's meant to be used (it's the only library I've ever seen that uses final classes and final methods effectively), and as a result its backwards-compatibility record is superb. It's so good that when writing wicket I don't even miss python.
If you're writing good OO code then you write objects whose state gets set on creation. In wicket, if I want to redirect the user to another page (say after a form submission) passing in a parameter I can do setResponsePage(new MyOtherPageClass(parameter)). In tapestry that looks like randomAnnotatedField.magicMethod(parameter); return MyOtherPage.class . IIRC.
There's no type safety; if you misspell a tapestry magic method name it will just silently not be called. You can't step through your components in a debugger because your fields won't show up properly. It's particularly bad if you're just learning, because it seems to actively discourage good OO design, and because tapestry classes have subtly and not-so-subtly different semantics from real Java.