Jakarta Tapestry - Quotes

This page contains quotes from the Tapestry community, appearing on the Tapestry mailing lists and in online forums such as TheServerSide.com.

These entries have been editted for grammar and readability.

We used Tapestry to implement the monitoring and administration console for a wireless network management product. Initially, we implemented a demonstration using standard JSP but we realized that JSPs presented difficulties for implementation. Some of our requirements were a very aggressive development schedule, integration with EJB 2.0 beans, ability to write modular reusable components, very reliable, easy code maintenance, internationalization, and of course easier debugging than the generated JSP code. Tapestry met all of our requirements and helped us proceed onto a successful release.

After reading the tutorial and reviewing the examples, we started with writing simple components. We started with a StatusImage component. The GIF for the status image should be localized and selected based on standard network status states. Another example of a simple component was a validating IP address text field. The IP address field uses the Tapestry validation framework. After that, we moved onto more complex components like the StatusTable shown in the figure. This table has a varying number of rows depending on the configuration of the product using the Tapestry Foreach component (very cool). This StatusTable makes use of another essential Tapestry component, the Conditional. Looking at the Actions columns, the set of actions is conditional based on the row. All this logic happens in the Java class and is not embedded into our HTML making maintenance much easier.

Finally, we integrated servlets and JSPs into our Tapestry web application. We needed servlet integration for charting and JSPs for reporting. With all this flexibility, we could use each technology where they worked best. Overall, all of Tapestry's flexibility along with its clean object-oriented architecture made our web interface shine.

Screen shot 1 Screen shot 2

When I see things like "I can use Struts+Tiles+JSP 2.0 Taglibs" I kind of chuckle. While you have to learn three different, albeit related, technologies I just have to use Tapestry. With this kind of mindset, is it any wonder companies are looking to ASP for their front-ends?

When I took my current position, I decided to use ASP to develop the front-end piece for similar reasons ... I was fortunate to find Tapestry before I started development in ASP. Not only did it allow for me to meet my goals, but I actually have fun developing now. I used to spend at least a day formatting and introducing the proper presentation logic into an application. What took a day now takes maybe a couple of hours. Performance is excellence, the MVC design couldn't be better, and no messy JSP compilations to worry about.

To me, simplicity with functionality is the greatest achievement of the Tapestry framework.

Of all the web presentation frameworks out there, Tapestry is the most elegant.

For me ELEGANT is the goal of a programmer/developer (I've been around awhile). When, in your MVC framework, VIEW is pure HTML, and your CONTROL - controls (wow - nice control; exception/debugger/session handlers they are -- well, elegant) and the link to your model is - often as simple (elegant) as get/set, then the philosophy of web applications has moved to a new and cleaner level.

But elegance is a moving target, and Tapestry, with this latest release 3.0, puts me not only on board (I already am) but I've fastened my seatbeat, and I'm ready for takeoff.

The learning curve for Tapestry is still somewhat steep ... but I'm really enjoying it now that I'm beginning to get it and, most importantly, I don't feel like I'm writing much, if any, superfluous code. It really seems like all the code directly contributes to functionality and that there's very little boilerplate. One of the hallmarks of a good framework, in my opinion.

You know, Tapestry in fact is different from your average JSP taglib. Anyone who had a chance to use component-based web frameworks (like WebObjects, I don't know any other in this category) would know what I am talking about. This is a *different* and highly powerful and convenient way of doing things.

Surprisingly enough with so many web application layers out there, Tapestry seems to be the only one (OpenSource, that is) that allows you to create a set of reusable components and build the design around this. The level of reuse is unmatched with anything JSP. In many ways it is even stronger than commercial implementation of the same design idea (WebObjects). In particular it makes it extremely easy for graphics designers to modify HTML, since dynamic content does not use *any* custom tags. Also the amount of code (and time) it takes to hook up an average model layer to the HTML presentation is so small that at first you may think you've missed something along the way :-).

I've said it before and I'll say it again... You owe it to yourself to take a serious look at Tapestry. It's the most exciting model in Java web development I've seen in a long time. It really allows you to build applications--not web sites--that "execute on the web." Very cool stuff.

Tapestry is the best solution to the presentation tier and it provides a clean separation of content and developer code. First, I extended it for WAP support, then I developed several WAP components and finally I developed a complete email application for WAP in record time.

When using Struts or Velocity, in order to see what the finished page will look like, our graphic designers must assemble the application, deploy it ... they basically lose all the luxuries of WYSIWYG development ... I spent 30 minutes or so with one of our graphic designers here, and he was giddy at what I showed him as I redesigned one of our smaller apps using Tapestry.

Bottom line for us is this: We have graphic designers and we have developers, and I don't want them to necessarily have to know each others' job to get things done. Tapestry is the best framework I have seen that offers this sort of separation.

As a 'lay developer' using Tapestry I can only recommend it. We have built a content management system based on Tapestry, plus multiple sites that are now powered by it. Thanks to its component architecture, we are able to publish any kind of our metadata-driven business objects with just a handful of generic, highly dynamic pages, using customizable components. All business logic is encapsulated in business objects and services, so there is not really much logic in the presentation layer besides the navigation parts.

The learning curve is not flat, but is really worth the effort. If you need to bring a dynamic web-app to the browser Tapestry offers many predefined and stable components to build on. We have gone with Tapestry and we will continue to use it in the next couple of projects needing a web-interface, too.

I just wanted to send you a quick note of appreciation for your Tapestry framework. It is a truly original and innovative approach.

While the learning curve is steep compared to thinner webapp frameworks, I have found it is well worth the effort. The amount of code I am having to write is greatly reduced and I am achieving a much greater level of reuse.

I just want to second the positive comments about Tapestry. We have evaluated a lot of frameworks in the past couple of years, and in our opinion Tapestry is the only open source Java framework at the moment that provides everything necessary for Web-centric component oriented development.

The most important feature of Tapestry is indisputably the ability to package common Web functionality into components that can then be effortlessly reused again and again. Building a Tapestry application is pretty much like playing with Lego bricks -- all you have to do is just fit the different pieces together and not worry about how each brick would work internally or how the different pieces would interract with one another (an OO approach at its best). As a result, after gaining some experience and accumulating a set of components, one can build incredibly complex Web applications quickly and easily, and yet be assured that those applications are of a very high quality.

Tapestry has another major advantage as well -- it provides very clean separation between presentation and logic (cleaner than that of the most commonly used frameworks). The design of its templates is also very mindful of the actual web development process, accomodates very nicely the work of the web designers from the start, and allows them to play along even in later stages of the application development. This, again, is something rarely found in the other frameworks.

I will mention just one more superb feature -- the Tapestry design and APIs provide a huge number of extension points that allow you to customize the behaviour of the framework almost to no end. In order to achieve a specific goal for one customer we twisted the behaviour of the system so much, that Howard would faint if he sees it. In any case, being able to easily modify and extend specific elements of the framework is a major advantage.

This may sound a bit like an advertisement, but it is not -- we are just very satisfied users. We've got a significant increase in productivity, we've got increased quality, we've got happy web designers, and we've put an end to the repetitive operations -- it would be hard to think of a better scenario.

If you are experienced in OO and/or components and care about Web development, I would suggest that you have a look at Tapestry. I would be very surprised if you do not find it a far more viable solution for your needs than JSP or Struts, for example.

Actually what drove me to Tapestry wasn't the saved development time, it was the sheer beauty of it :-)

I come from an ASP/VB background and I was getting sick and tired of that mess, designers constantly asking me "Is it OK to move this part of code to the bottom of the page?" , "Could you take a look and see if I didn't mess anything when I added the picture?", "Ohh, I'm sorry. that was an include file, I thought it was just a comment" ... well you get the picture, and tools like Dreamweaver only help to some extent. The perfect separation of roles was what drew me to Tapestry ... the rest of the things (and there are a lot of them) were the iceing on the cake.

The company that I work for did a research project with the National Research Council of Canada, and we spent several months reviewing web services, J2EE, and Database systems for a technical risk project that we were doing. Out of that we learned 3 things:

1. Web services were immature.
2. J2EE was overrated.
3. That JSP and anything else that stuck anything other than HTML into an HTML file was not only counter-productive but dangerous to the life of the project.

I will give you an example. We have a "legacy" project that is done in JSP (all of our development efforts have moved to Tapestry). We had to perfect the logic of the project while the text and look of the project was still in flux. Everytime our graphics guys fixed the pages, code would get damaged, or vice versa. Everytime our graphics guys created new pages, our programmers would have to go mark up the pages with code and could not work on the logic of the given page until after our graphics guy had finished it. On top of that the whole system has to be translated into French. Which means that we not only have doubled our work, we have actually ended up tripling it, pushing back deadlines, etc. If it had not been for the fact that we "inherited" the code, it would have been done in Tapestry to start with, because:

1. Our graphics designers could do their thing without disturbing the work of our programmers.
2. The programmer wouldn't have to wait for the designers to finish a page to start work on it. Many times our programmers work with pages that are simple white with text and form fields and after it works, our designers integrate the pages together.
3. Localizing for French simply involves copying the existing layout, replacing English text with French, and saving it with a new file extension ... no need to recreate the code of a JSP.
4. If our client doesn't like the look, it is a simple matter of changing it, no code is disturbed, no code is broken, it will work when it is done being modified without our programmers even looking at it. (And our designers don't even know Java....)

If you are using a language or framework that puts proprietary (non-HTML) code into your templates or HTML files, I seriously suggest that you take a look at the approach that Tapestry takes as you will probably find that it is quite revolutionary in its approach to web development (as stated above).

So take it from someone who just researched existing and upcoming technology for three months, Tapestry frags the snot out of frameworks like JSF, Struts, and the like.

I will give Apache one thing though, they have built a lot of production quality software that beats even Microsoft. We added Torque to Tapestry to fill a void in the database support (Tapestry by itself has no database support) because Tapestry's model fit so perfectly that I can actually create a web page to display all the records in a table using only 14 lines of Java code, of which less than half (only 6 lines of code) are actually hand written (the rest are auto-generated by Eclipse). So I guess that is another point for Tapestry: Integration of other packages / APIs that support a Java Beans style is a no-brainer. No taglibs need to be written, no new scripting needs to be created, it simply works.