This is a quick guide to changes since Tapestry 5.0.18. This is meant to provide information on any additions or changes that developers will face after upgrading from Tapestry 5.0 to Tapestry 5.1, or from one 5.1 snapshot release to another.
It is always advised to perform a full and complete build after upgrading.
You should also check the project-wide release notes for information about bugs fixes and other improvements.
Tapestry's alpha URL rewriting support (available from 5.1.0.1) has undergone some API changes:
The client-side ids for labels and error icons have slightly different names; the ':' seperator (i.e. "textfield:label") has been changed to a '-' (i.e., "textfield-label"). This should only affect users who have significantly overridden client-side validation.
The same approach has been taken with the many client-side elements used by the Palette and DateField components.
Tapestry's client-side JavaScript relating to input field validation has changed somewhat to account for TAP5-211. This will only affect users who have created their own client-side validations.
The handling of the Secure annotation is now only enabled in production mode (by default).
This is the change between releases that is most likely to affect your upgrade.
The PrimaryKeyEncoder interface has been deprecated and will be removed in a later release. See TAP5-165 for the rationale.
You may see type coercion errors on pages where you have specified the encoder parameter of the Grid, Loop or AjaxFormLoop components as a PrimaryKeyEncoder. These errors indicate that Tapestry was unable to automatically convert your PrimaryKeyEncoder instance into a ValueEncoder. Generally, the only change is to invoke the new constructor for DefaultPrimaryKeyEncoder, to identify the type of key used.
If you don't use DefaultPrimaryKeyEncoder, you will see compile errors about the new method, getKeyType(). You will have to change your code to implement that new method.
As part of the changes related to TAP5-417: Tapestry 5.0 Performance Improvements, you should be aware that Tapestry will now optimize the render phase state machine. This is only relevant to advanced users who have written a ComponentClassTransformWorker that adds logic to a render phase: it is necessary to inform Tapestry that the render phase should be invoked.
There have been some significant changes to the tapestry-spring module, to support injection of Tapestry services into Spring beans. You may find you need to add some new configuration to revert to the Tapestry 5.0 behavior.
Tapestry is now more aggressive about automatically re-storing any session persisted object back into the session at the end of the request (this used to only apply to application state objects). See the persistent page data notes for more details.
Many questionable practices in Tapestry module classes that used to produce warnings have been changed to fail early (that is, throw exceptions). The rationale is that the warnings are almost always ignored, resulting in more difficult to diagnose runtime errors.
Extra public methods on module classes (methods that do not define services, contribute to services, or decorate or advise services) are now errors.