Page History

...

Tapestry divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting. Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java codeadding a small java class for each. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects – and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications.

...

• Tapestry now uses the Blackbird JavaScript console.
• Tapestry now automatically combines multiple JavaScript libraries into a single request.
• An Ajax event request may now return a MultiZoneUpdate instance to update multiple zones in the client web browser.
• Client-side numeric validation is now locale-sensitive.
• Some significant performance improvements over Tapestry 5.0.18: the time to initially load a page, and the time to render a page have decreased.
• Tapestry IoC services can now be easily advised as well as decorated (both of these refer to Aspect Oriented Techniques applied to Tapestry IoC services).
• Tapestry Services can now be injected into Spring Beans, when using the Tapestry/Spring integration library.
• Tapestry now compresses responses for clients that support GZIP compression. Context and classpath assets are now handled uniformly: versioned URLs, far-future expiration headers, and GZIP compression where applicable.
• Ordered and mapped configurations can now have overrides.
• Property expressions have been improved: You can now invoke methods with parameters, or create a list (very useful for link contexts).
• IoC Service contributions may now be made in terms of classes (that are automatically instantiated) as well as instances.
• A simpler method of overriding built-in services has been added.

Roadmap

Now that that The 5.0 1 release is finally out and available now, work is rounding out winding down on the imminent 5.1 release2 release, and developers are beginning to focus on 5.3.

The goal is to produce such releases on a regular schedule, every 4 - 6 months.

High priorities for 5.2 upcoming releases include Spring Web Flow integration , and support for developing Tapestry applications as Portlets.

Third Party Libraries, Tutorials and Resources

A number of Third Party Libraries, Tutorials and Resources are listed on the Tapestry Home Page.

...

This also represents a distinct change from Tapestry 4. In earlier versions of Tapestry, the Form component's listener parameter would be bound to the method to invoke, by name. Further, the listener method had to be public. This new approach not only support supports multiple listeners, but provides an improved separation of view concerns (inside the page's HTML template) and logic concerns , (inside the Java class).

In many cases, additional information about the event is available, and it can be passed into the method by adding parameters to the method. Again, Tapestry will adapt to your parameters, in whatever order you supply them.

...

Finally, Tapestry 5 explicitly separates actions (requests that change things) and rendering (requests that render pages) into two separate requests. Performing an action, such as clicking a link or submitting a form, results in a client side redirect to the new page. This is often approach, called "redirect after post". This , helps ensure that URLs in the browser are book-markable ... – but it also requires that a bit more information be stored in the session between requests (using the @Persist annotation).

...

Snapshots are intermediate versions of releases. As I'm of this writing this, the most recent preview release is 5.0.2 and the current snapshots are for 5.0.3-SNAPSHOT. Maven keys off the -SNAPSHOT suffix and handles the dependency specially. It knows that snapshot releases can change frequently, so it will keep checking (at least once a day, maybe more often) to see if there's an updated version of the snapshot.

...

In Tapestry, the structure of any particular page is static. This is necessary for several reasons, most importantly because Tapestry pages are pooled (in versions 5.1 and before). Creating a Tapestry page is an involved process, because the page object is simply the root of a large tree of other objects including user provided components, many kinds of structural objects, template objects, and others. Creating a new page instance for each request is simply not scalable.

...

Public vs. Internal

An issue plaguing previous older versions of Tapestry (version 4 ( and earlier) was the lack of a clear delineator between private, internal APIs and public, external APIs. The fact that your code would extend from base objects but that many of the methods on those base objects were "off limits" further confused the issue. This has been identified as a key factor in the "steep learning curve of Tapestry" meme.

With the clean slate of Tapestry 5, we are being the developers have been much more ruthless rigorous about distinguishing internal vs. external API's.

First of all, anything inside the org.apache.tapestry5.internal package is internal. It is part of the implementation of Tapestry. It is the man behind the curtain. You should not ever need to directly use this code. It is a bad idea to do so, because internal code may change from one release to the next without concern for backwards compatibility.

Backwards Compatibility

Tapestry has been Older versions of Tapestry (4 and earlier) were plagued by backwards compatibility problems with every major release. Tapestry 5 does not even attempt to be backwards compatible to Tapestry 4. Instead, it lays the ground work for true backwards compatibility going forwards.

Tapestry 5's API is based almost entirely on naming conventions and annotations. You're components are just ordinary Java classes; you will annotate fields to allow Tapestry to maintain their state or to allow Tapestry to inject resources, and you will name (or annotate) methods to tell Tapestry under what circumstances a method should be invoked.

...

Because of this, Tapestry will be able to change internally to a great degree without it affecting any of the application code you write. This should finally crack cracks the backwards compatibility nut, allowing you to have great assurance that you can upgrade to future releases of Tapestry without breaking your existing applications.

...