Release 2.2 of the Tapestry, an open source Java web application framework has been released. Tapestry is a component object model for building dynamic websites; It reconceptualizes web development in terms of objects, methods and properties instead of URLs and query parameters.

Check out Tapestry.

More info
-----------------------
Release 2.2 of the Tapestry: Java Web Components web application framework has been released and is available at SourceForge.

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.

Tapestry has been greatly enhanced since its 2.1 release in July, 2002.

Tapestry now uses the Object Graph Navigation Library to dynamically read and update bean properties. OGNL support Java-like expressions, allowing behavior to be specified in a specification that used to require Java code.

New Tapestry components include a DatePicker (which allows date input via a popup JavaScript window) and the sophisticated Table component (which presents tabular results that can span multiple pages, with navigation).

The ValidField component can now perform client-side validation, such as range checks on numeric fields.

Documentation has been improved, including a new quick component reference guide, which lists the name, parameters and behaviors of all Tapestry components, complete with examples of how to use them.

Tapestry components, pages and resources can now be packaged as libraries. A simple namespace system has been implemented to reference components packaged in a library.

A sophisticated Tapestry plugin for the open-source Eclipse IDE is also available as a separate project: Spindle.

Next items on the plate: More, and more sophisticated, components. Better integration with traditional servlet and JSP applications, including the ability to use a JSP instead of an HTML template. A streamlined, "Tapestry-lite" for new developers and new converts from JSP.

More information about Tapestry is available at the Tapestry Home Page. Tapestry is licensed under the Lesser GNU Public License.

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

I've downloaded the 2.2 doc archieve--Tapestry-2.2-doc.tar.gz. When I try to extract files, an error message popup saying "corrupted tar file". I redownloaded the archieve file, same error. But DO succefully downloaded the program archieve. Any idea? Or the doc archieve IS indeed corrupted.

Thanks,

Robert
Sinobest Information Technology

Just tested. IE has trouble with .tar.gz unless you use save as. Download the file, but save it locally, and open it once complete and it'll work. Tested with Windows 2000 and WinZip.

- The documtation.tar.gz is ok
- but it doesn't run on "out of the box" on jboss3.0.3/
  tomcat combination
- neither on jboss 3.0.3/jetty

ant-1.5.1
BUILD FAILED
file:/opt/tapestry/build.xml:487: Error while expanding /opt/jboss/server/default/deploy/jetty-plugin.sar


Cheers,
    Henrik
    TNGtech

Here's the fix for build.xml to make it run on 3.0.3/jetty. Most examples seem to work. A couple of deployment exceptions are thrown during startup.

=== comment out the "unjar" line
<!-- <unjar src="${jboss.server.default.dir}/deploy/jetty-plugin.sar"
dest="${temp.dir}"/> -->

=== change the srcdir in the copy operation as given here:
<copy todir="${tapestry.lib.dir}">
  <fileset
    dir="${jboss.server.default.dir}/deploy/jbossweb.sar">
      <include name="*.jar"/>
  </fileset>
</copy>

Cheers,
    Henrik
    TNGtech

Thanks for the fix; keeping compatible with JBoss is a moving target, so for the meantime I've just kept the auto config compatible with 3.0.0. It's probably time to upgrade to 3.0.3 and be done with it.

Why not upgrade to JBoss 3.2?

Or better yet, why not have some docs that give instructions on integrating Tapestry to JBoss? That way, developers can integrate Tapestry with existing JBoss server configurations.

The current Tapestry build creates a JBoss server configuration specific to Tapestry. IMHO, this is the wrong way to go. JBoss is the app server, the base. So why not have docs for integrating Tapestry to JBoss (or any other app server for that matter) and not integrating JBoss to Tapestry.

Tapestry integrates into JBoss like any other framework ... just drop the necessary JARs into the lib directory.

The build file support is to allow a completely turn-key demo to run on the user's machine. No manual instructions for copying files or editing XML, just "ant configure run-jboss". The demo involves running McKoi DB as a service and deploying .war and .ear files, and doing some special setup of the Jetty service. Better and easier to let Ant do the work. Since its only a demo, I don't see it as a deal-breaking issue to limit users to JBoss 3.0.0.

Upgrading to a later JBoss would be good in that JBoss 3.0.0 has some severe class loading problems, speedwise, that are supposedly addressed in later releases. Right now, initial loads of pages are painfully slow, mostly because of class loading.

Thank you. My apologies. The docs do say that build file sets up the **demo** for JBoss 3.0.0 and I have no problem with the demo only being supported by specific versions of JBoss.

I am most curious about what "special setup of the Jetty service" is done for demo. As I am trying to run just the Hangman demo in JBoss 3.2 (with embedded Jetty) and its not working due to the _request.getParameter(name) in RequestContext always returning null for the service name.

I think this question is best dealt with in the Tapestry Mailing List, so I will re-ask there.

Tapestry allows components to be packaged as libraries and distributed in JARs.

A component may have assets (a general term for images, stylesheets and other resources) packaged with the classes in the JAR file.

However, such resources are not visible to a client web browser. In someway, they must be "exposed" to the client web browser.

Tapestry has two ways to do this; first is the "asset" engine service, which will read resource content from files in the classpath and push the bytes down to the client.

A much better way is to, as needed, extract resources and place them into a directory mapped to a web folder. The resources can then be referenced using static URLs.

The special Jetty configuration is to enable this "externalizing" of private assets.

I think the OGNL stuff in Tapestry is a God send. I had a complex Java / Page interaction going on, and then realized that I could do the whole thing as a single line of code in the binding using OGNL. It had to do with formatting of currency values and displaying "Free" when it was zero. I simply created a format method, put a couple of ?: operatators in the binding and voila, it works great. I think OGNL is an important step for Tapestry in making it easier to use but still keeping code or script out of the HTML where it really doesn't belong (one of the shortcomings of JSP and other MVC wannabes).

How does Tapestry fit into the big picture with respect to Java Server Faces?

That's a whole can of worms that's been done to death in a previous discussion:

https://www2.theserverside.com/discussion/thread.jsp?thread_id=15244

Now that 2.2 is out, I'm starting to work on 2.3. My goal is to allow the use of JSPs instead of HTML templates. You'll be able to mix tag libraries, including JSF tag libraries, with Tapestry components (using a Tapestry tag library). It won't be perfect (using Tapestry as-is is perfect :-) ) but it may help with Tapestry adoption.

I'm also looking at some ideas to simplify initial development, a more JSP-like approach to creating simple pages (by allowing simple pages to exist without a seperate page specification). I'm getting some howls from the Tapestry developer list, they don't want me to dumb down the framework, but I'm investigating it anyway.

<shameless plug>
Spindle 1.1beta4 the latest version of the IDE plugin for Tapestry 2.2 is out. This version integrates with the Eclipse Update Manager.

http://spindle.sourceforge.net

</shameless plug>

Looking at the traffic on the Tapestry lists, the community has grown significantly since the last release. There's been a lot of interest from WO-aware people.

Geoff

Is there any demo or real website that use Tapestry?

Demos are available on the Tapestry home page (they are actually hosted at a second site, since SourceForge doesn't support servlets).

There have been recent postings on the mailing list about live sites coming up with Tapestry, but I don't have the URLs handy.

You can download the distro and JBoss 3.0.0 and run the local demos. Setup is easy and takes less than a minute.

Tapestry 2.2 really shines. OGNL takes away a lot of the drudgery that was involved with writing silly one/two liner Java methods. Even the earliest versions of Tapestry had good ways to package reusbale components, but the library mechanism really adds polish. The Eclipse plugin (Spindle) is great, and getting better as I type. But even better - people are actually starting to pay attention to Tapestry. The traffic on the dev list is increasing noticeably, and with the moves afoot this is set to continue.

I have been using Tapestry for over two years now, and I really couldn't ask for anything more than it has given me so far. If you're interested in Java MVC-type web development, this project deserves a serious look - and not just a quick glance.

Recently a member of the tapestry developer list posted some news about a project built in Tapestry that's available for download. A copy of his post follows...

I spent some time cheking out the screenshots (haven't had time to download & run it yet), very nice.

Geoff

-----------------------------------------------------------
FROM: joe
DATE: 10/14/2002 13:24:16
SUBJECT: [Tapestry-developer] new Tapestry application available. Hi,

We are making a new Tapestry application available for
public consumption.

WOF developers who are considering making the move to
Tapestry might want to take a look at this app. I can
tell you that developing the UI for this application
was very easy-- at least as easy as using WOF. As a
WOF developer I was immediately productive in
Tapestry. Hats off to Howard for maintaining such high
standards of software quality.

This application contains a number of reuseable
components (javascript popout-window links, tree
browser, Grid, etc) which we will contribute to the
Tapestry component library. If you see something in
the UI that looks like it might be componentized and
you would like to use it, give a shout and we will
look at getting it in the library sooner rather than
later.

The application, along with some screenshots, can be
found here:

http://groups.yahoo.com/group/pixory-beta/

This is some information about the app:


In a Nutshell

Pixory is a "personal image server". It allows you to
store your photos on your own pc but to access,
compose into albums, and share them anywhere on the
internet. Pixory was motivated by the desire to
centralize the storage of, and access to, personal
photo collections. But rather than centralizing them
at a commercial online photography service such as
Ofoto (tm), Pixory allows you to host your own photo
albums by using the computers and broadband internet
connection that you already own. Pixory presents a
standard web interface through which you can browse
and organize your photos from anywhere on your home
network, or the internet at large, and share them with
anyone on the internet.

Highlights:

    * Presents a standard web, pure html, interface
for all operations. Uses no plugins or proprietary
extensions.
    * Requires no installation. Just unzip and run.
    * Portable, 100% pure java. Will run on any
operating system that supports a 1.4 java runtime
environment (JRE).
    * Is completely self-contained. Requires no third
party packages, aside from the JRE.
    * All user entered album data is stored in
standard XML, accessible to the user independent of
Pixory.
    * Simple intuitive interface.
    * Pixory is secure. The combination of a web
interface and java offer a very secure facade to
present to the internet. There are no general serices
or hooks into the operating system added by Pixory.
The only functionality that is enabled is what you see
directly in the web interface.
    * Efficient. Pixory has fairly minimal hardware
requirements, running well on an Intel pentium 500
MHz. The Pixory download is only 3MB.
    * Can display image metadata such as the EXIF
information embedded in image files by most digital
cameras and scanners.

I am a big fan to the Tapestry framework (and have made some contributions).

The learning curve is steeper than your average Command pattern web framework, but what you get is a more event based Object Oriented programming model. You get great reuse through components and end up writing a lot less code.

The component feature is very important. Components revolutionised GUI programming with languages like VB and Delphi. They enabled developers with domain expertise to assemble applications using components developed by GUI experts. I think the Component based approach in Tapestry (and potentially in JSF one day) provides the same level of productivity boost.

For instance application developers with no JavaScript skills can use the Tapestry JavaScript enabled DatePicker, PropertySelection or ValidField components out of the box.

When learning Tapestry it took me 3-4 days for the whole thing gel in my head (you may do better :) also in my defence the documentation has improved since then). When approaching it don&#8217;t try think in terms of Servlets and JSPs, think more in terms of Components and Events.

Another bonus with Tapestry is the Spindle Eclipse plugin. Spindle is very good and makes it easier to develop and maintain large Tapestry applications with their Page/JWC/Java files. What I would like to see next is a drag and drop GUI editor like Delphi :)

It is great to see Tapestry framework development accelerating.

<aside>
I don't think the MVC design pattern should be used describe most web frameworks, I think people are kidding themselves when the do.
</aside>

We just released an early version of a Tapestry based application which is available for download here:

http://www.pixory.org

It's not an enterprise application but a "personal server" (really both a client and a server). Working with Tapestry was quite a pleasure. I was almost immediately productive in Tapestry (ok, I have a WebObjects background). As you can see from the screenshots, our application contains some non-trivial UI elements (like the "lightbox"). Most of the UI elements in our application are reuseable components, the creation and maintenance of which is greatly facilitated by Tapestry's squeeky clean component model. These are *real* components, black boxes which only interact with the outside world through a small number of well defined parameters. And Tapestry components hierarchically compose into more complex components in a very natural way. We had to spend very little time building our UI components, even though Tapestry did not have pre-built components for our UI.

In short, Tapestry components are as close to traditional event-driven components as web-components get. The Tapestry model of component interactions is quite elegant.

regards,

Joe Panico

Ah, if only I looked at it a year ago. It would have saved me a ton of time and energy.

I'd seriously suggest people spend the time to evaluate tapestry fairly. You will quickly realize it's maturity over other MVC web frameworks (including those with large followings). It?s really top notch, no BS.

I am a long time user of Tapestry. The new features of Tapestry are very exciting to us. We are using Tapestry for two different web applications in my company.

The first web application is for generating surveys pages on the fly. What was unique about our requirements is that we needed completely dynamic forms. The set of form components is a runtime calculated set of fields, checkboxes, radio buttons, etc. To make our problem more difficult, the layout of the individual form components is dynamic and parameterized. Tapestry handled this situation with ease letting us combine object-oriented form components at runtime into survey pages. Tapestry also automatically handled all the posted responses and validated the responses. Finally, we had stringent performance requirements. Our benchmarks showed that generating these dynamics pages under load was extremely fast (~30 ms) using Resin as our web container. (see http://sourceforge.net/mailarchive/message.php?msg_id=1414013)

The second web application is a sophisticated administration console. We needed a tree on the left and an edit pane on the right. We wanted the edit pane to change based on the selection within the tree. Finally, we wanted a menubar along the top. We already had nice looking Javascript menus and trees but we wanted to work with them in an object-oriented manner within Java (not Javascript). So, we defined Tapestry components that wrap our Javascript pieces. Now, we have a very powerful object-oriented web framework. Using Tapestry, our development time was a fraction of what we expected it to be.

We've been using Tapestry for a while now, and must say it's far better, easier, faster, cleaner than stuffing code into JSPs... We've used Struts for a couple of applications previously and when I've found Tapestry I presented it to my boss, and after a short evaluation period we switched to Tapestry for all new web-based applications to be produced.
Sometimes I still have to fix or change something in those two old apps based on Struts and, man, then I keep seeing the huge difference... once you start working on Tapestry you don't want to go back to other frameworks... at least not to Struts ;)
I think the 2 most excellent features of Tapestry are the reusability of components (and the little work to make one) and the auto "handling" of URLs in services.
I don't think the integration with JSP is necessary... I'm even affraid of it... don't want to see this framework contamined. This integration is proposed for gaining acceptance and making it easier for newbies to catchup. Well I think the JSP support will make the learning period just longer.
Why instead of making these Tapestry Light to gain acceptance don't add features that make it unique and necessary when developing web-apps.
For example we have an HTML template engine, why not have a, say, SVG or any other media template engine?
I also must say here that the community of Tapestry is great, when I had difficulties and posted questions on the mailing list I had almost instant answers and Howard seems to have endless patience to answer newbie questions.

I'm hoping the newbie questions will decrease with the new tutorial Neil is putting together.

It is becoming harder for me to keep up with the traffic, which is good and bad. Fortunately, others can answer questions as well!

Hi, I like the Idea of having something like event driven /traditional GUI programming in Tapestry but I think it is really a shame that it is missing JSP integration. If you are interested in my preliminary vision of how JSP/Servlet Frontend Development should go, check out the
iternum ui framework preview.

Karl

Can you quantify *why* you miss JSP?

I'm currently working on extending Tapestry to provide Tapestry Lite. It'll resemble JSP a little more, and serve as a transition layer for newbies. HTML templates will exist directly in the application context (instead of on the classpath). No application spec or page specs will be needed.

Like JSP, there will not be a seperate specification file ... you'll put component types, ids and configuration directly into HTML.

Like Tapestry Professional (Traditional?, anyway, the correct way of doing things), there will not be any Java in the HTML template.

There will be a lot of things you can't do in Tapestry Lite. However, there'll be a clean transition to Tapestry Professional, simply by adding proper application and page specifications. You'll mix and match.

What do you get in JSPs? Java code (universally accepted as a bad idea), taglibs (which can be useful, but Tapestry components are much better) and ... not much else. Lots of wierd Java-code-related cruft (like <%@ page import="" %> and the like. Long compile times when you change things.

You have a point from the traditional UI perspective. However I miss JSP because of some reasons like

- most projects are not green field. They use some technology, server, product that is based on JSP and requires it
- taglibs are not so bad after all.
- JSP provides a programming model a lot of people have grown accustomed to. That does not say it is the best possible - it is probably not.
- If I tell a manager, I want to use a JSP-standards-based-product might be a lot more successful then telling her I want a product that saves all of us money and time and uh unfortunately it does not depend on standards based JSP.

Keep up the good work,

Karl

<quote>
 taglibs are not so bad after all.
</quote>

Well they aren't that good either. I used to think that tag libs are ok.. But not anymore. I realized that user interface development really benefits from component based approach in terms of better quality and productivity.

<quote>

If I tell a manager, I want to use a JSP-standards-based-product might be a lot more successful then telling her I want a product that saves all of us money and time and uh unfortunately it does not depend on standards based JSP.

</quote>

The fact that Tapestry runs on Servlet API is IMHO far more important than templating techology used. Integrating web applications on the user interface level is allways difficult if applications use different frameworks. Rarely you can just glue two web user interfaces together and live happily ever after. JSP-based application can be allmost anything. It might use proprietary framework or Struts etc. or nothing at all. There's no real application wide 'standards'.

Integrating is allways easy if you are only showing stuff on a web page. But when there's actually some interaction with the user, things tend to become much more complicated.

There are situations where JSP is the best choice. But there is other options also. Tapestry is *very* good at building web-based applications.

This is an attractive framework compared to other frameworks in terms of components, templating, writing simple java code, built in validators etc.

Great work and keep it up.

But eventhough it is based on Servlet API, it uses its own terminologies like Visit, Engine etc. A programmer who used to work in JSP or Servlets has to learn all these new concepts and correlate with standard terms like Session, Application etc. Do you have a head to head comparison with JSP concepts since this is an alternative to JSP and reduce the learning curve ?

1. What are the advantages of using Tapestry over an XML/XSL approach. That is, morphing the data to XML and choosing an XSL template with which to generate the output.

2. I note that Tapestry supports Locales, but can Tapestry also be used for those apps where it needs to choose a template to render based on client type, for example - mozilla vs the bowser in my Treo 300.

Thanks

First off, when you talk about XML/XSL pipelines, you are largely covering just the render phase of your application.

The important parts of Tapestry are in the round-trip logic, that links rendering (or links and forms) in one request cycle, to dispatching of incoming requests in the next cycle. That removes tons of code ... and thus, tons of bugs.

To my mind, over-leveraging of XML/XSL to support multiple devices is a red herring. When you have an application that runs on a desktop PC its going to be completely different than an application on cell-phone. More than just editting out some stuff and re-arrainging fields, its simply a different application.

The XML/XSL approach appeals to "ivory tower" mindset, because it appears to save effort ... but boy, that XSL can get complicated fast. To me, XML/XSL is like programming inside a case statement ... you end up having too many hidden dependencies to manage.

In Tapestry terms, you'll have a large PC application and a small cell-phone application (probably inside the same WAR).

Reuse occurs in the application layer (EJBs, datbase and beyond). The presentation layer should be kept flexible, to implement the many minor tweaks needed for good useability.

Code reuse can happen with Tapestry objects .... so the PC version of a page and the cell-phone version of a page may share the same subclass of BasePage, but be different pages (with unique page specifications and templates).

Thanks for your input. In general I agree about the short comings of the XML/XSL approach. Perhaps you are correct about an app on PDA being not the same app as on the PC, perhaps not. However, the URL for an app is part of the company's brand. And a brand is something that companies spend lots of $$ to get imprinted in our brains. No company is going to want a different version of a URL for a PDA version of their site. I can browse google or amazon with my PDA and its smart enough to deliver html appropriate to the device. I am not so quick to dismiss this bit of functionality. I want this ability in a framework.

That's just a little implementation detail. You could easily have a "welcome" servlet that sniffs the client and forwards to the correct Tapestry application based on it.

Once you are past that first URL, users should not know or care about the URL, they just want to be able to bookmark it.

I've been using and learning Tapestry for the last 3 or so months. My previous experience includes Turbine and Velocity - as well as standard JSP/Servlets.

Summary: I'm now hooked :-)

After converting an existing JSP/Servlet web site into Tapestry (partly to learn more about the framework) it has become clear to me that it is significantly more powerful in terms of every day site creation and maintenance than other framework's I've used.

I should clarify that by saying that the site is interactive, not just static pages with little dynamic content.

The Tapestry community is also excellent. I've been sitting on the mailing lists for a while now and almost every discussion is professional and helpful. It is certainly a list that a newbie can fell comfortable posting to!

Howard and the team; Keep up the excellent work!