Component Classes
Page edited by Bob Harner
Comment:
Noted @Retain as deprecated
Changes (2)
...
Unless an instance variable is decorated with an annotation, it will be a _transient_ instance variable. This means that its value resets to its default value at the end of reach request (when the [page is detached from the request|Page Life Cycle]).
If {deprecated:since=5.2}For Tapestry 5.1 and earlier, if you have a variable that can keep its value between requests and you would like to defeat that reset logic, then you should attach can add a @[Retain|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Retain.html] annotation to the field. You should take care that no client-specific data is stored into such a field, since on a later request the same page _instance_ may be used for a different user. Likewise, on a later request for the _same_ user, a _different_ page instance may be used.
{deprecated}
Use [persistent fields|Persistent Page Data] to hold information from one request to the next.
...
Full Content
Component Classes
Related Articles
Page:
Component Cheat Sheet
Page:
Component Libraries
Page:
Component Parameters
Page:
Component Reference
Page:
Component Templates
Page:
Page And Component Classes FAQ
A Component class is the class associated with a page, component or mixin in your Tapestry web application. Classes for pages, components and component mixins are all created in an identical way. They are pure POJOs (Plain Old Java Objects), with annotations. They are not abstract, nor do they extend from framework base classes.
For Tapestry 4 Users: Component classes in Tapestry 5 are much easier than in Tapestry 4. There are no base classes to extend from, the classes are concrete (not abstract), and there's no XML file. There is still a bit of configuration in the form of Java annotations, but those now go directly onto fields of your class, rather than on abstract getters and setters.
In most cases, each component class will have a corresponding component template. However, it is also possible for a component class to emit all of its markup itself, without using a template.
Component Class Basics
Creating page and component classes in Tapestry 5 is a breeze. There are only a few constraints:
The classes must be public.
The classes must be in the correct package (see below).
The class must have a standard public, no-arguments constructor.
Here's a very basic component:
package org.example.myapp.components;
import org.apache.tapestry5.MarkupWriter;
import org.apache.tapestry5.annotations.BeginRender;
public class HelloWorld
{
@BeginRender
void renderMessage(MarkupWriter writer)
{
writer.write("Bonjour from HelloWorld component.");
}
}
In this example, the component's only job is to write out a fixed message. The @BeginRender annotation is a type of component life cycle annotation, a method annotation that instructs Tapestry when and under what circumstances to invoke methods of your class.
These methods are not necessarily public; they can have any visibility you like (unlike in Tapestry 4).
Component Packages
Component classes must exist within an appropriate package (this is necessary for runtime code transformation and class reloading to operate).
These packages exist under the application's root package, as follows:
For pages, place classes in root.pages. Page names are mapped to classes within this package.
For components, place classes in root.components. Component types are mapped to classes within this package.
For mixins, place classes in root.mixins. Mixin types are mapped to classes within this package.
In addition, it is common for an application to have base
