Founder of Tapestry and Hivemind, Howard Lewis Ship talks about the origins of Tapestry, the differences between it and other web frameworks, how it integrates with Spring and Hibernate, and how to unlearn the bad habits caused by traditional approaches to development, and Hivemind's capabilities as a micro kernel.

Tapestry is component centric. That means you build an application from pages, pages are build from components, components are build from components. Tapestry is having a blueprint of your entire application and that means it can do a lot of things for you that normally you would have to do. Things like figuring what the URL should look like and mapping those URLs to the behavior of your application. So you will create a component and you tell it invoke this method when you get clicked if it is a link, or where you can submit it if it is a form. What you find is huge swathes of code drop out of the picture because they are in the framework, they have been written once, they have been tested once...

Watch Howard Lewis Ship on Tapestry and Hivemind.

You could also listen to him on Tapestry at http://www.javalobby.org/av/javapolis/23/ship-tapestry

Any content-oriented website needs human-friendly URLs. The visitors wants to share URLs of interesting articles, copy them to links, store in bookmarks.

Take a look at www.computerworld.cz for their URLs. This is so messy. If I copy it to email, it usually break line limit and recepient must reconstruct it.

The URL shall IMHO tell you something about the document, it is referencing.

+1
Plus: google likes significant url. They do not store too long utl and they try to search meanings in the word of the url

Currently, there is the FriendlyURLs patch to Tapestry 3.0.x that helps solve much of this problem. In Tapestry 3.1, not only will URLs be better, but somewhat configurable.

Actually only the "STATS" section of the homepage is developed using Tapestry, as far as I know. Anyway, take a look at the source code for the following URL:

http://www.nhl.com/nhlstats/stats?service=page&context=Home

and you will see:

<meta name="generator" content="Tapestry Application Framework, version 2.3"/>

:)

Actually, most of the site seems to be Tapestry now (everything I looked at, except the store, is Tapestry)

I still do not understand why there is this high learning curve for Tapestry... Once you get past that high learning curve it is really a matter of unlearning your bad things, the torture that has been inflicted on you by servlets and struts and then continuing on in the Tapestry way.

Because is a different way of thinking about your applications. And because ... the help is not consistent enough for an "action oriented framework" kind of guy. What I really think it would be usefull is a kind of visual presentation of a very simple example. A login page for example. From the ground up, developed with X html editor and Eclipse Spindle (Just like the Trails sample, I've watched it somewhere).

I have to mention that I really appreciate the approach of Tapestry(in terms of ideas and principles) but I started three times learning Tapestry and never got an example working. And developed several struts/webwork based projects in that time :-D. Well, there is also maybe that I never have enough time to do it, but a 5 minutes example would really help. I would do this myself, if I would know how.

Recently several folks have contributed their time to develop tutorials and examples for Tapestry. You can check out my own contributions at Tapestry Web Components Examples.

http://howardlewisship.com/blog/2005/02/new-tapestry-tutorials.html

Perhaps it can help you.

thanks

For me, I think the most difficult part of the learning curve was moving away from the "brute force" method of doing things. Tapestry provides a much more elegant event-based model than other frameworks, more like a traditional GUI application. I really agree with this statement that "unlearning" is the biggest hurdle. I have noticed that people who find Tapestry interesting tend to be those who are dissatisfied with the alternatives and also tend to be fairly experienced developers. Because of this, "unlearning" issues come up frequently with new Tapestry users.

I agree completely with you that a step-by-step walkthrough would be helpful. I would like to put something together myself, but unfortunately my time is too tight at the moment. Regardless, after a couple of weeks of Tapestry I began to feel somewhat productive, and after a month or so I had developed a 12K line app which (although not perfect) is still in production and I have not had to touch it except for a few minor enhancements.

Tapestry for me now (after six months or so) is completely natural, and I have very few complaints. The next release (3.1) is due for release in June or so, and I expect it will address many of the common minor annoyances (elimination of the "direction" attribute, prettier URLs, etc.) as well as adding some new features such as portlet support.

After having experienced many of the other framework solutions over the past several years, I believe the "Tapestry way" is the best (that is, the most object oriented, achieving the greatest separation of concerns between the model/view/controller application layers, automating many of the common mundane tasks of interfacing with the user). The actual implementation of these ideas is improving all the time, in the form of regular Tapestry patches and revisions.

It's always easiest to fall back on what you know (in your case, Struts/WebWork), but Tapestry for me has been worth the effort.

I have the feeling that Tapestry is made for me, I appreciate that it sticks to html, and that it is component-based, but I must say that until now - and after 2 tries - I did not manage to "unlearn" the other frameworks. In fact, even JSF seems easier to me! Some names are confusing, sometimes when I tried to learn I got lost in a land of concepts, and did not know how to put all these things together. Just in search of a simple example I could study? So I decided to have a deeper look at jsf until the 3.1... Wishing that jsf will help me to understand Tapestry more easily.

If you have the Tapestry in Action book, I found the Hangman application to be complete and educational. If you download Tapestry, there is a Virtual Library example as well as a Workbench example. The VLib is good to study at a source level, but it is somewhat difficult to run since it is a true J2EE app. The workbench app is easy to get up and running, and it illustrates a lot of the basics.

There are other examples on the web which you should be able to find fairly easily. There are several here which also use Spring: http://jroller.org/page/raible/apps

For those complaining the lack of an easy-to-follow tutorial, I'd like to invite to spend 30 minutes following my tutorial at http://www2.cpttm.org.mo/cyberlab/softdev/tapestry/index.html

What I really think it would be usefull is a kind of visual presentation of a very simple example. A login page for example. From the ground up, developed with X html editor and Eclipse Spindle (Just like the Trails sample, I've watched it somewhere).

There is such a login page example in my "Creating an e-Shop" tutorial at http://www2.cpttm.org.mo/cyberlab/softdev/tapestry/index.html

If it's not obvious, this was taped nearly a year ago, at the previous Server Side Symposium. A few of my opinions have shifted in the meantime (especially in terms of scripting languages such as Ruby), but I still think "Java is good enough".

I agree with the other poster: I could just never get where HLS was going with Tapestry. Maybe he just thinks in a different way, but none of his documentation (including Tapestry in Action, which I read cover to cover) is particularly good. Everything is dealing with the inner workings of the Tapestry API, not about really getting things done. I thought the whole point of an API was that I didn't have to know the flow of code through the API (yes, it's helpful when the documentation is bad, but...). Also, his examples deal with snippets of code but never complete concepts.

Having worked with WebObjects--which is awesome, by the way--I see lots of weirdness in Tapestry. It supposedly came out of the WebObjects line of thinking, but then he tacked on oddly-named concepts which don't seem to make sense, but somehow are required to use Tapestry. I've never really understood what "direction" there for.

I think it's very telling the only example of Tapestry in production I could find is the Server Side (don't get me wrong; great example), and that was built by HLS himself!

We tried Tapestry where I work, but wound up rolling our own API that was more like WebObjects (we'd use WO, but we're on Linux). Just didn't have the time to figure out the mess.

I've worked with WebObjects for a few years and am now working on a project using Tapestry. Yes, we looked at Struts and other frameworks, but decided to proceed with Tapestry due to its strengths and have been very happy with our decision. The framework is very versitile and robust. The documentation is pretty good, working examples are included with the framework, the mailing-list is very active and supportive of new users. Yes, there is a learning curve to get to a productive level but it's certainly no steeper than that of WebObjects and well worth the effort.

I would strongly recommend Howard's book, "Tapestry in Action" to anyone seriously interested in learning Tapestry.

The framework is very versitile and robust.

In comparaison to many other frameworks, Tapestry scales well to complexity. The component model is very well designed and allows you to keep a nice separation of your data access/business code. Our goal for porting our web site to tapestry is mostly reduce the maintenance... Php (and many other technologies I bet) end up generating tons of messy code, difficult to manage after several years. With Tapestry, the amount of code in the html page has been very low, keeping it easy to evolve the pages. Also the framework has the nicest navigation model... no more crazy code for form validation and flow through the pages.

Henri.

...I thought the whole point of an API was that I didn't have to know the flow of code through the API...I've never really understood what "direction" there for...Just didn't have the time to figure out the mess.

+1

Tapestry seriously suffers from requiring it's user to know too much about the internals in order to do anything non-trivial.

Hopefully the situation will improve in Tapestry 3.1+. And hopefully Tapestry will become more open in terms of ease of integration with other web technologies, including JSP/JSTL or even Struts, JSF, etc., instead of pointlessly trying to promote it's own superiority like a religion.

Tapestry seriously suffers from requiring it's user to know too much about the internals in order to do anything non-trivial.

Is there a non-trivial web framework where you don't have to know something about the internals? I find Tapestry's architecture to be cohesive and flexible. The return on investment for the learning curve is terrific. After you get "under-the-hood", it is clear that internals (e.g. component model, event abastractions, etc) make building and maintaining large scale apps much much easier.

Hopefully the situation will improve in Tapestry 3.1+.

The situation is always improving. This is another thing to like about the framework.

It's easy to get Tapestry working without knowing its internals. Please follow my 1-hour tutorial at http://www2.cpttm.org.mo/cyberlab/softdev/tapestry/index.html

Hi. I just wanted to let you know that there are, in fact, many examples of deployed applications using Tapestry. My project, The Tree of Life Web Project (http://tolweb.org) is one of them and we couldn't be happier with the results.

Another (formerly) major traffic site that used tapestry was nhl.com -- clearly not getting hit very hard these days.

While I would agree that there is a certain amount of required knowledge needed to use Tapestry, it is constantly improving. For instance, the 'direction' piece of parameters is going away in 3.1.

The documentation keeps getting better and the users' list is unparalleled in terms of friendliness and expertise.

Just my 2 cents,
Danny

Tapestry is not any more complex than other popular frameworks. It is harder to learn because

1) it is different from JSP/Struts/Webworks which is deeply rooted in many developer's mind.

2) it has a component library, which is the "vocabulary" you need to be familiar with before you can be productive.

3) it has too many syntax of doing the same things which tend to confuse new users.

4) some things, such as 'direction', is badly named which further complicates the issue.

5) some concepts are really odd (programming abstract page objects, rewind cycle etc.). Explaining these concepts involves describing the API under the hood.

Dispite these factors, there are still many people switch to Tapestry because it is a truely effective framework.

Here are some point to share if you want to learn Tapestry:

1) stick to one syntax. I always use the xml files to define my components. My HTML templates are regular HTML files except for the jwcid attributes.

2) don't use Border. Border is powerful in the long run, but it is not Dreamweaver friendly. Again I prefer to keep the .html files as HTML as possible.

3) use simple DTO objects and Map as models. Try not to use your domain objects directly for the components unless they are really simple. This strategy will keep you focus on the framework itself rather than distracted by tedious coding.

4) focus on Page objects. Most likely you don't need to create new components until after 2 to 3 weeks of experience.

Albert

Hi. I just wanted to let you know that there are, in fact, many examples of deployed applications using Tapestry. My project, The Tree of Life Web Project (http://tolweb.org) is one of them and we couldn't be happier with the results. Another (formerly) major traffic site that used tapestry was nhl.com -- clearly not getting hit very hard these days.While I would agree that there is a certain amount of required knowledge needed to use Tapestry, it is constantly improving. For instance, the 'direction' piece of parameters is going away in 3.1.The documentation keeps getting better and the users' list is unparalleled in terms of friendliness and expertise.Just my 2 cents,Danny

Are you saying that the National Hockey League web site, http://www.nhl.com is implemented using Tapestry?

If so, that's the kind of ammo I can use. How can this be confirmed?

To discover this fact, just view the source of the home page and you will see this line:

<meta name="generator" content="Tapestry Application Framework, version 2.3"/>

and make this is fact even more delicious is the fact the banner at the top of the page is "MSN Sports". Feels kind of nice to have a java framework running a website sporting a Microsoft logo :->

<blockquoteAre you saying that the National Hockey League web site, http://www.nhl.com is implemented using Tapestry?If so, that's the kind of ammo I can use. How can this be confirmed?
Yes, just click a few links and you will notice some familiar Tapestry URL's. The first level or two of the page seems to be scraped into html files for performance reasons. www.dilos.com and www.tryfoneshare.com also use Tapestry.

I first saw Tapestry a few weeks ago and I didn't have any problems getting the hang of it. I already have a small reusable component library built that I can use to create highly-dynamic pages within minutes. Pages that would take hours in struts.

Also, you can find other websites that use Tapestry by using google. For example, search on something like this:
inurl:"app?service=Direct"

It supposedly came out of the WebObjects line of thinking, but then he tacked on oddly-named concepts which don't seem to make sense, but somehow are required to use Tapestry. I've never really understood what "direction" there for.

"direction" is going away in 3.1. However, what it means is how Tapestry should cache the parameter of the component. If direction is "in", it evaluates the expression once at entry point and caches the value in a variable. If it is "form", it will also store the value back at exit point. If direction is "auto", it will not cache the value (so it will evaluate the expression whenever you try to get the value).

I agree that the name of "direction" is a bit confusing, but I hardly see other misnomers otherwise. If you find some, let us know.

Kent Tong: That's the best description I've seen yet of parameter direction. I notice you've done some of the tutorials, perhaps you could do an FAQ for Tapestry sometime if you get the chance.

Kent Tong: That's the best description I've seen yet of parameter direction. I notice you've done some of the tutorials, perhaps you could do an FAQ for Tapestry sometime if you get the chance.

Sure, thanks!

Most of the problems outlined above will be fixed, or at least greatly improved on the next version of Tapestry. The "direction" parameter is gone (good riddance), and the programmer now has much more control over the URL scheme.

Tapestry 3.1 will also feature a much tighter integration with Hivemind, greatly simplifying the overall Tapestry programming model. 3.1 will be *big*, just you wait.

The other two concerns voiced above seems to be about the learning curve and documentation. Here's my take on them:

Tapestry is an 'run-off-the-pack' framework, and thus you won't be able to leverage your existing knowledge about Struts, WebWork or other similar choices. If you were learning a web framework from scratch, however, Tapestry isn't significantly harder than the two cited examples.

Anyways, please take your time to learn more about Tapestry. We know that Tapestry's documentation is quite lacking, but hopefully things will get better. There are plans to improve the reference manual before Tapestry 3.1 release and add more tutorials as well.

As for existing docs, Howard's book is currently the best source, but the recently released tutorials, written by avid Tapestry users helps a lot to "get your hands dirty" quickly. Spend one week learning Tapestry, and save months in increased productivity later.

The fact is that tapestry does support human readable URLs. I think the confusion stems from the fact that the presentation is nearly a year old. A patch for the 3.0x versions of tapestry has existed since August 2004 and many people are using it with success.

The main benefits are:
- better J2EE security control
- more user friendly URLs
- more search engine friendly

Tapestry 3.1, currently alpha and due for June release, will support friendly URLs out of the box and also pluggable URL generation schemes for cases when more flexibility is required.

Jon

Here at Darden Solutions (University of Virginia, Darden Business School) we build Web applications for business schools. Currently we are rewriting our suite of applications from ColdFusion to J2EE technology. Our first rewrite was to our Alumni product and used Struts. The development team was not very happy with the pain involved using Struts, so we looked about for something better. We considered WebWork 2 and Tapestry 3.0.x and chose Tapestry for its component object model. We have absolutely loved it. We now have our Admissions and Career Development products written using Tapestry 3.0.2 and we are progressing rapidly on our Registrar product using Tapestry 3 with Friendly URLs. Since we use JAAS and declarative security, FriendlyURLs is a big win.

Although I did not personally work on the Alumni (Struts) project, the other developers assert that we are about three times more productive with Tapestry than Struts. Furthermore, we have been able to develop many custom components that we resuse. This cuts down on development time and on cut-and-paste code. Some of the custom components are common to all modules and others are domain specific. The only other Web framework I have used that gives this sort of component reuse is Web Objects.

Clients that currently have our new Tapestry-based products deployed include GSB Chicago (U. of Chicago), MIT's Sloan school, and Darden. Some of our current clients upgrading this year to our J2EE products using Tapestry include Columbia, Duke, Stanford, Yale and Wharton (U. Penn) business schools. These are all top U.S. business schools.

I appreciate Tapestry quite a lot. As an old WebObjects hand, I appreciate it's inspiration... and also see where it falls short of WebObjects (WO for short). Part of that is due to the J2EE framework, but some of it is the way that Tapestry didn't/doesn't get the request/response loop right: it has 2 main stages rather than WO's 3....

Anyway, for those new to this way of thinking, I too find the explanations available generally miss the essential and concentrate on the details.

OK, so what's the view. Go back to the original MVC architecture (not the re-defined MVC of struts). Tapestry is the VIEW in the true sense of original MVC. It adds 2 things that are missing from J2EE apps: state in the presentation layer (see below) and action-invocation on a controller (in the classic MVC sense).

Controller action invocation first: what SmallTalk did (origin of MVC) and C++ didn't give the developer was dynamic invocation of methods. This ability meant that a view element (say a button) could invoke an arbitrary method (object method! not a C++ static "method" which is in fact a simple a function pointer). Unlike with Java no interface definition with an "action" or "callback" method was required. SmallTalk begat Objective-C and that led to the best UI tool ever: InterfaceBuilder. Along came Next's WO folks and they ran with that. UI elements in WO can invoke arbitrary methods on any object (a controller). Hence true layering. True separation of concern. You don't even need a DAO object or that "design pattern." 'Course, 'cept for dynamic proxies, and, more recently, runtime byte code munging, we don't normally do this sort of method invocation in Java because of the reflection overhead and because most tool builders have a history with C++ where such things aren't possible. Anyway, despite the fact that Tapestry is a Java framework the cool thing it gives you is this separation: arbitrary UI presentation (HTML) invoking a method on any object you choose. No need to recode HTML (heck there are only a few dozen elements anyway). No bizarre psuedo-scripting of tags. Simly wire a bit of UI to some objects. Which objects? Your domain objects of course. Basically the UI gets entirely out of your way. This was the beauty of WO: you could built a web app the way the best non-web GUI apps were built: graphical wire-up of UI elements to invocation of domain object methods. How's Tapestry do this? Via its XML middle layer. The XML is per-component. It tells a component (UI) which method to call on what instance (domain object). It's a very nice approach.

The trick to that is a TRUE View in the classic GUI sense: that is, a stateful view. Thus Tapestry must maintain state for elements of a user's UI and re-associate it on each request/response. Doing so gives both the visitor to the site, and the web-app developer the illusion of an ordinary (non-web) stateful environment. This is more than the regular bits of state in a HttpSession: each component, rather each instance of a component (for a component can appear multiple times on a page) knows how to store and retrieve its state from the session AND gives you nice things like: which element of a drop-down WAS selected, etc. It's quite nice. But, this is the bit that Tapestry's creator(s) got somewhat ... well, not quite right. It takes 2 cylces through the UI objects (componenets) to do this correctly and Tapestry's rewind tries to do it in one pass.... Otherwise Tapestry is quite nice and if you have any non-web experience it is by far the most intuitive and easiest dev env. to adopt.

I think you are on to something about two vs. three cycles.
I suspect the solution will be that the Form component will buffer up some deferred behaviors that are executed only after everything else in the Form rewind has occured.

Appreciating the hard work you put into your site and in depth information you present. It’s nice to come across a blog every once in 
a while that isn’t the same unwanted rehashed material. Wonderful read! I’ve bookmarked your site and I’m including your RSS feeds to 
my Google account.

 In many websites and I finally found it here. Amazing article. I am so impressed. Could never think of such a thing is possible with it.

Hello i would like present my page Inmobiliarias

I am an IT professional and i really read all the technical talk of this post with great interest and got a lot of information from here as well. doctorate in education

Nie odkąd w dzisiejszych czasach jak wiadomo o szkodliwości elektroniczne papierosy pykania. Jednostki, które bachnęły nałóg tytoniowy, rozpamiętywają spośród mozołem całkowity ów przebieg. Biznesy farmaceutyczne elektroniczne papierosy zasiedlają uprzednio pewien epoka innowacje i produkty dopomagające w porzucaniu ćmienia. Pojawiły się elektroniczne papierosy dlatego bogate płaty nikotynowe, gumy do przeżuwania oraz nieelektronowe skręty. liquidy e-papierosy Elektroniczne pety (kultowe również jako elektroniczne papierosy) to najpóźniejszy produkt na targu. Istnieją one założone, żeby oczekiwać oraz czynić jak na przykład naturalne niedopałki. Wyrzucają podobnie symulowany ćmij, atoli w światów nie brzmieją tytoniu. Kontrahenty elektroniczne papierosy inhalują opary nikotyny, które reprodukują jaraj wyzbyty podwaliny karcynogennych, jakie stanowią gniewne dla palącego i niedrugich typów.