Are there any up to date articles comparing JSF 2 and Tap 5? Everything I seem to find is comparing JSF 1.2 and Tap4.
Does anyone have any experience with T5 or JSF2 and time to evangelize one or the other?
I'm looking for a framework for rapid development in Java, on top of Hibernate and mySql.
Other framework sales pitches accepted, but JSF2 and T5 are currently our top picks.
Taking up your offer and pitching another Framework :
If you want really rapid development then you should look at the Play Framework.
I've used JSF/Richfaces/Seam/Hibernate etc and I'd say that using Play more than doubles your productivity. There are no deploy cycles. So no developer downtime. It's got JPA/Hibernate baked in and lots of plugins that extend it's functionality in other directions.
I also like the fact that it makes your pages so lightweight. My biggest issue with JSF was always the weight of the pages (unecessary IDs, lots of tables, client state etc)
Take some time and view the webcast.
I've worked mostly with Tapestry 5 over the last few years; I won't evangelize though. Choosing a good web framework is certainly a good idea, but usually not your prime problem.
A list of good and bad things from the top of my head:
Tapestry 5 has a rather steep initial learning curve. There's magic and metaprogramming happening everywhere. You could argue it's overdoing convention over configuration.
Simple stuff is very simple to do, harder stuff requires you to understand in detail how Tapestry 5 works and can be hard if you don't (yet).
I love the live class reloading. You change something in a T5 component or template and you see it right away. Really useful when your app does a lot of stuff and takes 30s+ to start in Jetty.
Tapestry does not support dynamic page structures. This is usually not a problem, but if you're developing some kind of portal solution where people can individually arrange components, don't use Tapestry. Tapestry is for static structures, which it handles really well.
Tapestry has beautiful URLs. package/page/${param1}/${param2} ...
Tapestry uses the proper HTTP verbs to do stuff. A link is a GET, a form submission is a POST, the post-redirect-get pattern is the norm.
Tapestry's community is not very large. Apart from Howard Lewis Ship, there are a few other committers, but nothing like the support Wicket has. Thus, Tapestry evolves rather slowly.
Tapestry's approach to templating (instrumenting HTML with types and IDs) is one of the better ones I've seen, but it doesn't go as far as Wicket in keeping code out of the HTML. On the other hand, the class files are less verbose. Still, I think the Wicket way is preferable.
Tapestry is somewhat under-documented.
I like Tapestry very much, I think you can be very productive with it, and I would always happily participate in projects where it is used.
I would, however, advise to also check out Wicket. It seems to have gained more traction than Tapestry and solves some problems less magically, but with a common sense approach.
(I've only briefly used JSF 1, which I found was completely off in just about everything it did: wrapping every request in a POST (thus breaking basic web functionality), using JSPs, but requiring to use special tags for everything, even plain HTML... I read a lot has improved in the JSF camp, but I can't tell, I've never looked at it again.)
Taking up your offer and pitching another Framework :
If you want really rapid development then you should look at the Play Framework.
I've used JSF/Richfaces/Seam/Hibernate etc and I'd say that using Play more than doubles your productivity. There are no deploy cycles. So no developer downtime. It's got JPA/Hibernate baked in and lots of plugins that extend it's functionality in other directions.
I also like the fact that it makes your pages so lightweight. My biggest issue with JSF was always the weight of the pages (unecessary IDs, lots of tables, client state etc)
Take some time and view the webcast.
Check out my presentation JSF 2.0 vs. Tapestry 5: A head-to-head comparison at Jazoon 2010. This might help you to make your decision.
As Tapestry committer I would advise you to choose Tapestry, but I think the best way to make the decison is to give both a try. Need more demo applications?
https://github.com/drobiazko/tapestry5inaction/tree/master/tlog
Most important Tapestry 5 feature for me is the flexibility of the framework. You can override almost every piece of code inside Tapestry's core, thanks to Tapestry IoC.
Don't look to me for an unbiased opinion ... Tapestry has been my life for several years now, and I continue to love it.
That being said, the learning curve is getting less steep, the documentation is improving rapidly, and Igor's book is just around the corner.
Some of the things that confuse people are simply lack of documentation; for example, the naming conventions are optional, there's always more explicit configuration (in the form of method annotations) that some people are more comfortable with.
To address a couple of Henning points:
Tapestry component templates are, by design, static (and this is very important to Tapestry's scalability and clusterablity story). However, an add-on that's part of my TapX library supports dynamic external templates that fill the gap.
Also, if you want to keep your templates maximally spare, you can do that too, such as:
<form t:id="myForm">
... in the template, with the remainder in the Java class:
@Component(parameters={"zone=target", "clientValidation=blur", "context=client", "secure=true") private Form myForm;
.... in other words, all the Tapestry specific content out of the template and into the code. Not ideal for trivial components (more switching back and forth between template and Java source) but great for keeping the worlds nice and separate.
I've been pretty pleased with Tapestry. It is a different approach than what most people are use to. It uses a lot of the same paradigm as WebObjects (what the iTunes store is built on).
Tapestry does a very good job of minimizing the amount of code you have to write to accomplish a task. This is great once you know what you are doing, but it can be frustrating at first while you are learning the naming conventions because some stuff seems to magically work and other things won't because you named wrong.
One of my favorite things about Tapestry is how little XML is required. For example, if you create a Hibernate entity, you place it in the com.example.entities package and give it the @Entity annotation. There is no other configuration necessary--no XML, no adding the the class name to a file somewhere, etc.
I'd highly recommend taking a look at actual code to see what you think. Here are a couple suggestions:
wookicentral.com/ github.com/spreadthesource/wooki
tapestry.zones.apache.org:8180/tapestry5-hotel-booking/ github.com/ccordenier/tapestry5-hotel-booking
Also take a look at the jumpstart site. It contains a number of examples along with the code showing you exactly how to use most of the various components. It also contains a starting point app that gives you some user management features if you want to base an application on it.
jumpstart.doublenegative.com.au/jumpstart/
Also check out the revamped Tapestry documentation. It isn't posted on the main site yet, but it is already a very big step forward:
people.apache.org/~uli/tapestry-site/
Use JSF 2, particularly if you make use of Java EE 6 features. If you want to have fancy UI, try Primefaces.
As per your requirement, the important part to consider is that you're using MySQL, and that's it. Therefore, take if from different angle. You're using JPA2 (and your persistence provider happens to be Hibernate in this case). With this approach, down the track you can quickly very easily 'swap' your persistence provider or database you're using.
Looks like Java EE 6 solves it.
Here's a pretty good comparison of Tapestry 5 and JSF 2
http://blog.tapestry5.de/wp-content/uploads/2010/06/JSF-2.0-vs-Tapestry-5.pdf
Note this was put together by Igor Drobiazko, a Tapestry 5 comitter
I love this question about Tapestry. Maybe it will influence your decision.
© 2022 - 2024 — McMap. All rights reserved.
