Java Server Faces 2.0 or Tapestry 5.2?

Are there any modern articles comparing JSF 2 and Tap 5? All that seems to me is a comparison of JSF 1.2 and Tap4.

Does anyone have experience with T5 or JSF2 and the time to evangelize one or the other?

I am looking for a framework for rapid development in Java, on top of Hibernate and mySql.

Other wireframes are accepted, but JSF2 and T5 are currently our top picks.

+7
frameworks jsf tapestry
source share
8 answers

Accepting your offer and submitting another Framework:

If you need development very fast , you should check out the Play Framework .

I used JSF / Richfaces / Seam / Hibernate etc. and I would say that using Play more than doubles your performance. No deployment cycles. Thus, there is no downtime for developers. He launched JPA / Hibernate and many plugins that extend its functionality in other directions.

I also like the fact that it makes your pages so light. My biggest problem with JSF has always been the weight of the pages (unnecessary identifiers, lots of tables, client status, etc.).

Take time and watch the webcast.

+8
source share

I have worked mainly with Tapestry 5 over the past few years; I will not evangelize. Choosing a good web infrastructure is certainly a good idea, but usually this is not your main problem.

List of good and bad things on top:

  • Tapestry 5 has a pretty steep initial learning curve. There, magic and metaprogramming take place everywhere. You can claim that he convinced the configuration agreement.

  • Simple things are very easy to use, more complex things require you to understand how Tapestry 5 works in detail, and it can be difficult if you do not (yet).

  • I like reloading live classes. You change something in the T5 component or template, and you see it right away. Really useful when your application does a lot of things and takes 30 seconds + to get started with Jetty.

  • Tapestry does not support dynamic page structures. This is usually not a problem, but if you are developing some kind of portal solution where people can individually organize components, do not use Tapestry. The tapestry is designed for static structures, which it does an excellent job.

  • The tapestry has beautiful urls. package/page/${param1}/${param2} ...

  • The tapestry uses the correct HTTP verbs to work. Link is GET, form submission is POST, post-redirect-get pattern is the norm.

  • The tapestry community is not very large. Apart from Howard Lewis Ship, there are a few more commiters, but nothing like Wicket support. Thus, the tapestry develops rather slowly.

  • The Tapestry approach to templates (an HTML toolkit with types and identifiers) is one of the best I've seen, but it doesn't go so far as Wicket stores code from HTML. Class files, on the other hand, are less verbose. Nevertheless, I think that the way to the gates is preferable.

  • The tapestry is somewhat underestimated.

I really like the Tapestry, I think you can be very productive with it, and I will always be happily involved in projects where it is used.

I would, however, advise checking out Wicket as well. He seems to have gained more traction than Tapestry, and solves some problems less magically, but with common sense.

(I only briefly used JSF 1, which, as I found, was completely disconnected in everything that it did: wrapping each request in POST (thus violating the basic functions of the network) using JSP, but to use special tags for everything, plain HTML ... I read a lot in the JSF camp, but I can't say, I never looked at it again.)

+24
source share

Check out my presentation of JSF 2.0 vs. Tapestry 5: a head-to-head comparison in Jazoon 2010. This can help you make your decision.

As a participant in tapestries, I would advise you to choose a Tapestry, but I believe that the best way to make a decision is to give a try. Need more demos?

https://github.com/drobiazko/tapestry5inaction/tree/master/tlog

The most important feature of Tapestry 5 for me is the flexibility of the structure. Thanks to Tapestry IoC, you can override almost every piece of code inside the Tapestry core.

+6
source share

Do not look at me for an unbiased opinion ... The tapestry has been my life for several years, and I continue to love it.

Thus, the learning curve becomes less steep, documentation is improving rapidly, and Igor’s book is just around the corner.

Some things that confuse people are simply the lack of documentation; for example, naming conventions are optional, there is always a more explicit configuration (in the form of method annotations), which is more convenient for some people.

To address a few of Hanning's points:

Tapestry component patterns are static in design (and this is very important for scaling and classifying Tapestry clusters). However, adding this part of my TapX library supports dynamic external templates that fill the gap.

In addition, if you want your templates to be protected as much as possible, you can also do this, for example:

<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 specific content from the tapestry from the template and into the code. Not ideal for trivial components (more switching between the template and the Java source), but great for maintaining the worlds in general and separately.

+5
source share

I am very pleased with the tapestry. This is a different approach than what most people use. It uses a lot of the same paradigm as WebObjects (on which the iTunes store is built).

The tapestry does a very good job of minimizing the amount of code you have to write to complete the task. It's great when you know what you are doing, but it can be frustrating at the beginning as you study naming conventions, because some things seem to work magically, and other things will not because you called it wrong.

One of my favorite things about Tapestry is how little XML is required. For example, if you create a Hibernate object, you put it in the com.example.entities package and give it the @Entity annotation. No other configuration is required - no XML, without adding the class name to the file somewhere, etc.

I highly recommend taking a look at the actual code to find out what you think. Here are some 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 website. It contains a series of examples along with code showing how to use most of the various components. It also contains an application for the starting point, which gives you some user management functions if you want to create an application on it.

jumpstart.doublenegative.com.au/jumpstart/

Also check out the updated Tapestry documentation. It has not yet been posted on the main site, but this is a very big step forward:

people.apache.org/~uli/tapestry-site/

+4
source share

Use JSF 2, especially if you use Java EE 6 features. If you want a fantastic interface, try Primefaces .

According to your requirement, the important part to consider is that you are using MySQL and what it is. Therefore, take it if from different angles. You are using JPA2 (in which case your persistence provider is Hibernate). With this approach down the track, you can very quickly "change" your provider or the database that you use.

It seems that Java EE 6 solves it.

+3
source share

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

Please note that this was compiled by Igor Drobyazko, guest of Tapestry 5

0
source share

I like this question about Tapestry . Perhaps this will affect your decision.

-2
source share

All Articles