Release 2.3 of the Tapestry: Java Web Components web application framework has been released and is available at SourceForge ... but don't let that fool you, Tapestry is transitioning to Jakarta!

Tapestry is a component object model for building dynamic, robust, scalable web applications in Java. It reconceptualizes web application development in terms of objects, methods and properties instead of URLs and query parameters ... in other words, more like building a Swing GUI than assembling a mass of servlets and JSPs.

Tapestry allows developers to concentrate on interesting, application-specific code, rather than the low-level grunge work of building and interpreting URLs and query parameters. It allows a proper separation of HTML and Java code, and closely follows the standard Model-View-Controller patttern.

Tapestry allows for high levels of reuse, both horizontal (same application) and vertical (different applications). Creating reusable components in Tapestry is easy and natural.

Release 2.3 represents a modest improvement over 2.2. It contains bug fixes, and some new documentation and components. Primarily, the release marks the transition from LPGL to ASL in terms of license, and the transition from SourceForge to Jakarta in terms of project hosting.

The turn-key Tapestry demos now configure and deploy into JBoss 3.0.4.

Next up in release 2.4 (which is well underway): More, and more sophisticated, components. Better integration with traditional servlet and JSP applications. All aspects of Tapestry application development are being streamlined and improved.

More information about Tapestry is available at the Tapestry Home Page. Tapestry is licensed under the Apache Software License.

My thanks to the growing Tapestry community for all the great help, support and feedback.

Any word from ASF on when Tapestry will be "offically" moved to Jakarta?

Rong

Cool... another step to web-development heaven.

I've been using Tapestry with a small team of programmers and
web-designers with great success for the past 9 months.
Tapestry really is on a league of it's own, and if you are a Java
developer and suffer for penis envy when looking at ASP.NET, you
should give Tapestry a try.

This is what you get for free[1]:
- Perfect separation of roles.
- Great validation framework.
- Easy display of localized content.
- Excellent exception reporting.
- Large code coverage for the Tapestry JUnit test suite - http://jakarta.apache.org/proposals/tapestry/doc/clover/
- IDE support - http://sourceforge.net/projects/spindle/
- Lego-brick approach to components and component reuse. With a bunch of components already included.
- Great community support and good documentation.


Great work Howard et al.
Looking forward to the 2.4 Release, for what I've seen it will rock.

Luis Neves

[1] - Not exactly for free, the biggest complaint I here about
Tapestry is the initial impedance mismatch, but once you conquered the
learning curve you won't want to use anything else, I know I don't.

As Struts sails into the sunset to make room for next fat, bloated, overly complex web development framework--ahem, I mean JSF--there will be nothing standing in Tapestry's way of total world domination.

Way to go Howard and team! Keep up the good web work! (no pun intended) ;)

Also I value and savor any outside support for Tapestry, negativity does not serve any real purpose. Detailed comparisons of one framework against another are one thing (and Tapestry will always shine in such a comparison), but simply trashing other frameworks is a quick way to close potential Tapestry users' minds.

> Detailed comparisons of one framework against
> another are one thing (and Tapestry will
> always shine in such a comparison)

It depends on what you are comparing. If you are searching for a simple (and clean) web framework (that has not very steep learning curve and uses more common mindset), then I would stick away from Tapestry and choose another framework for example Maverick or Webwork.

> simply trashing other frameworks is a quick
> way to close potential Tapestry users' minds.

And you are definately the one to say that as you have learned it the hard way, :-).

This is a very good library for building web based GUIs.
We have a very big project with lots of user interfaces where Java script is duplicated many places. The main problem with JSP approach is you can not build components. With tapestry we can even wrap javascript into components and
the glue those components to form pages.

This is very nice concept. The main problem with tapestry
is when I do some mistake in configuration (XML files) it gives some exception in tapestry code, instead of giving exactly where I have gone wrong.

Improvement is necessary in error handling of tapestry itself.

Perhaps if you post your stack trace to the Tapestry user list. Tapestry has error reporting that is light years ahead of anybody else. Maybe the community can point out how the built in reporting addresses your issue. Or, if not, your point could kick off improvements!

Geoff

Acutally, I have been accused of monopolizing other threads to market Tapestry, but I don't feel I "bash" other frameworks or that I'm widely percieved as doing so. Probably the most negative thing I did was a diatribe about JavaServer Faces (something I've been far from alone in), but I did my best to balance what I saw in the code and examples against specific aspects of Tapestry.

I'm really looking forward to the release of Tapestry 2.4. It is just loaded with new features that should ease adoption and improve productivity. Specifications are somewhat de-emphasised: it uses a search mechanism to find page and component specifications, so you don't have to laboriously declare each page and component in the application specification (you don't even need an application specification anymore).

In a step towards JSP, there are now "implicit components". These are components whose type and parameters are specified directly in the HTML template. They can also be anonymous (meaning that Tapestry assigns an id to them). This bends, but doesn't break, the role separation in 2.3.

2.4 also uses BCEL to dynamically create subclasses of pages and components at runtime. A lot of busy work coding related to properties and parameters just evaporates; Tapestry creates a subclass with all the necessary fields and accessor methods and instantiates the subclass intead of the developer's class. It's very cool!

You can also use BSF supported languages, such as Jython, in 2.4. There's a new type of binding (used in page and component specifications) that allows you to specify a listener method as a script in the language of your choice.

Basically, Tapestry's rock solid foundation has made it pretty easy to extend in different directions. All the stuff in 2.4 will make Tapestry very, very competitive for quick-n-dirty applications, but still scale up easily to the high complexity range Tapestry is intended for.

Congratulations, Howard & team!

People speak of the learning curve of Tapestry, but I find it much more intuitive that other frameworks.

For Tapestry new users, version 2.4 can significantly change the web application development process.

By the way, I was working on a PowerPoint presentation about Tapestry for my new co-workers. It is based on the 2.4 alpha 3 version.

Here is the link:

http://members.cox.net/dsolis/tapestry/FastTrack2Tapestry.pdf

Regards

David

> but I find it much more intuitive that other
> frameworks.

Maybe it's because of many separate tightly coupled files that you have to work with, when you are building simple things . For example from your powerpoint presentation I found that creating component that will insert text inside bold elements requires you to make component specification (several lines of xml), BoldInsert HTML template, BoldInsert java class that inherits from BaseComponent. And when you want to use that component you have to create Page Specification (several lines of xml), and Home HTML template. That's 5 distinct files (maybe you also need some more configuration???) that need to be insync with each other. For example if I change the name or package of Java class I have to modify 3 files. Have I understood something wrong? Also it is not so clear what happens behind the scenes when you work with Tapestry. Things are more transparent with these other simpler frameworks (of course you have to write more code too, the code that has already been written for you in Tapestry).

Maybe some day I'll try Tapestry as it really seems impressive, but I'm quite happy currently with these true and tried command pattern implementing frameworks (command pattern makes it easy to debug, profile and unit test your code).

These forums are not the best place for a technical discussion; the mailing list (tapestry-user at jakarta dot apache dot org) is a bit better.

At one time, I had hoped to be able to fully integrate JSP and Tapestry, so that you could use a Tapestry component on a JSP page (basically, that a JSP could be used as the template instead of a Tapestry HTML template). That hasn't worked out, there are some seemingly insurmountable issues in trying to integrate the two rendering models.

In 2.4, I will try and put together a taglib to allow JSP apps to call into a Tapestry app.

The whole point of Tapestry is to have clean separation between presentatiaon and logic, to really use the MVC pattern. Through 2.3, there was a total separation; presentation was only in the HTML template. Configuration was only in the page (or component) specification. Logic was only in the Java class. This is the steep learning curve of Tapestry, knowing which file to access, and it is too much.

2.4 streamlines all that. The HTML templates will look a bit more familiar to a JSP developer, because the component types and parameter configurations can be right in the template. There's still the Tapestry philosophy of minimal intrusion into the HTML. For components with very complicated configurations you can still use the 2.3 way, putting the type and configuration into the page specification.

The page specification in 2.4 is smaller, typically containing only a few lines for things that don't fit into the HTML template, such as the Java class for the page. You can also declare properties for Tapestry to brew into your page. Using the scripting option, you can write listener methods in the page specification, embedding Jython or JavaScript (or REXX, etc.) blocks into the page spec that are activated in response to links or form submissions.

In 2.3, each page and component had to be laboriously declared the application specification. In 2.4, Tapestry searches for page and component specs using well defined search rules; only rule breakers must be specified. The application specification is also optional in 2.4.

David Solis's BoldInsert component (from that PDF) was done in 2.3 terms. In 2.4 terms, and following the same implementation pattern, you would have:

1) A component template of about two lines.
2) A component specification of perhaps 10 lines of XML.

When you want to use that component in any template in your application, it would look something like:

<span jwcid="@BoldInsert" value="Text to Display"/>

"Text to Display" could either be a literal value or, with the correct marker, an OGNL expression.

So all the dynamic binding in Tapestry means that you don't have to do as much work in 2.4 and you did in 2.3. And to accomplish the same thing by creating a JSP taglib would be at least 10x as much work and be uglier to boot!

The PowerPoint is just a technical introduction. It doesn’t pretend to substitute to official Developer and User Guide or Tutorials.

I looked for simplicity and clarity instead of efficiency or style.

Anyway, the slide about BoldInsert component is fixed.

Tapestry, I found, was much easier to understand than Struts and the like when it came to the number of files required. I looked at struts and all the JSP Tags, Action classes, form classes, etc. started to get to me. The same with Turbine et al. Yes, there are many files. But if all you want to do is print something in bold, use the B tag. Don't make work for yourself, you still have the full power of HTML available. The component model really shines when you have to do things like:

-- Drop down calender to select dates (done completely in DHTML)
-- Rich Text Editor (complete with picture upload and management)
-- Field validation using regular expression complete with prompts explaining what you did wrong.
-- Collapsable trees
-- Dynamic Data Driven tables

People have said "Tapestry makes the hard things easy and the easy things hard", I say "Use Tapestry for what it was meant for, making the hard things easy and use HTML for the easy stuff." Tapestry 2.4 severly closes the gap between the easy and the hard, and I have to commend Howard et al for that.

excellent presentation file.
This is a definite documentation for anyone who wants to understand tapestry.

Howard:

Congratulations. It's a very very nice work. I'm also pleased to found that you look more open regarding other frameworks. Perhaps thats only my perception, and this time I gave me some time to explore the product in more deep.

Look, two years ago I choose Struts to build web applications for my team, and abandoned the writing of my own web framework. I bet on Struts not because it were the best option available technically speaking (of course Struts has its merits), but because I felt at that time that it was going to be very well supported. I thougth support was important because that decision was going to affect many of my programmers, they were going to deal (and suffer) with the product daily. However, the experience using Struts was better that using only servlets and JSP, so there was an improvement. At this time it is possible to buy some books, give them to the people and easy the learning curve, our time to enable new programmers to learn Struts is shrinking also. Bottom line, we choose Struts because it was good enough for us, and today none of our programmers liked to be back programming plain servlets and JSPs.

Now, we have legacy on Struts. We are not willing to rewrite our applications to use another framework. We got some levels of productivity by using Struts. Of course, we could choose to rewrite our applications to use Tapestry, perhaps WebWork, or perhaps Velocity. And then, another Great and Better Framework would appear or mature and then we could rewrite our applications again. In our case, that's not possible. However, it is very likely we will integrate Tapestry in our portfolio, once we discover where it does apply better for our specific situation.

I was very pleased again for the phrase "In a step towards JSP,". I believe we must value the benefits of integration. If I could use tapestry components in a Struts application, it would be wonderful to me.

And the last good new, is to know that when I need to deliver quickly an application, perhaps in a "quick and dirty" way, I may use Tapestry instead of PHP. Yes, I prefer PHP when time to market is over all other considerations regarding a web application.

Regards and thank you very much Tapestry team for giving us Tapestry.


Javier

Will Tapestry 2.4 has good documentation?
Tapestry 2.3 was released few days ago but its documentation has too many examples under construction. It is rather hard to understand Tapestry without detailed documentation.