Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In addition, it is common for an application to have base classes, often abstract base classes, that should not be directly referenced. These should not go in the pages, components or mixins packages, because they then look like valid pages, components or mixins. Instead, use the root.base package to store such base classes.

Warning

Only component classes should go in any of these controlled packages; classes representing data, or interfaces, or anything that isn't precisely a component class, must go elsewhere. Any top-level class in any of the controlled packages will be transformed at runtime. The only exception is inner classes
(anonymous or not), which are loaded by the same class loader as the component class loader, but not transformed as components.

Sub-Folders / Sub-Packages

...

Instance variables must be private. (In Tapestry 5. 3.2 and later they can protected or package private as well – or even public, if marked final, or annotated with @Retain). These scope restrictions are necessary in order for Tapestry to perform runtime class modifications to support instance variables. You may have instance variables with other scopes in your class, but you may then see unexpected behavior in a production application because of how Tapestry shares and reuses pages and components. Tapestry will log an error for each component class that contains instance variables that violate these scope restrictions.

Be aware that you will need to provide getter and setter methods to access your classes' instance variables. Tapestry does not do this automatically unless you provide the @Property annotation on the field.

Since
5.3.2
5.3.2

Since release 5.3.2, instance variables may be protected, or package private (that is, no visibility modifier). Under specific circumstances they may even be public (they must either be final, or have the @Retain annotation).

Transient Instance Variables

...