[CONF] Apache Tapestry Component Classes
Bob Harner edited the page:
Component Classes
Comment: changed {code} param from xml to language=xml, as an experiment
...
Section
Column
Code Block
java
title
HelloWorld.java
[CONF] Apache Tapestry Component Classes
Component Classes
Page edited by Bob Harner
Comment:
Changed to have the first example be a component that does use a template, because it's the simpler and more common case.
Changes (16)
...
{float}
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.
A *Component class* is the class associated with a page, component or mixin in your Tapestry web application. Classes for pages, components and mixins are all created in an identical way. They are pure POJOs (Plain Old Java Objects), typically with annotations and conventionally named methods. They are not _abstract_, nor do they need to extend base classes or implement interfaces.
_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 theres 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|Component Templates]. However, it is also possible for a component class to emit all of its markup itself, without using a template.
h2. Component Class Basics
h2. Creating a Trivial Component
Creating a page and or component classes in Tapestry 5 is a breeze. There are only a few constraints:
* The classes must be public.
* There must be a public Java class.
* The classes must be in the correct package (see below).
* The class must have a standard public, no-arguments constructor. (The default one provided by the compiler is fine.)
Heres a very basic component:
Heres a minimal component that outputs a fixed message, using a template:
{code:java} {section}
{column} {code:java|title=HelloWorld.java}
package org.example.myapp.components;
public class HelloWorld { } {code} {column}
{column} {code:xml|title=HelloWorld.tml} t:container xmlns:t=http://tapestry.apache.org/schema/tapestry_5_3.xsd Bonjour from HelloWorld component. /t:container {code} {column} {section} In this example the HelloWorld class contains no code at all (except what it inherits from the Object class and what Tapestry adds invisibly). And heres a component that does the same thing, but without needing a template: {code:java|title=HelloWorld.java -- without a template} package org.example.myapp.components;
import org.apache.tapestry5.MarkupWriter; import org.apache.tapestry5.annotations.BeginRender;
...
{code}
In this example, just like the first one, the components only job is to write out a fixed message. The @[BeginRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender.html] annotation is a type of _[component life cycle annotation|Component Rendering]_, 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).
...
Full Content
Component Classes
Related Articles
Page:
Page And Component Classes FAQ
Page:
Component Templates
Page:
Component Reference
Page:
Component Cheat Sheet
Page:
Component Parameters
Page:
[CONF] Apache Tapestry Component Classes
Component Classes
Page edited by Howard M. Lewis Ship
Changes (3)
...
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 isnt 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. {warning}
h2. Sub-Folders / Sub-Packages
...
Tapestry components may have instance variables (unlike Tapestry 4, where you had to use _abstract properties_).
*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). private.*. 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|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Property.html] annotation on the field.
{since: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|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Retain.html] annotation). {since}
h2. Transient Instance Variables
...
Full Content
Component Classes
Related Articles
Page:
Component Libraries
Page:
Component Cheat Sheet
Page:
Page And Component Classes FAQ
Page:
Component Parameters
Page:
Component Templates
Page:
Component Reference
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,
[CONF] Apache Tapestry Component Classes
Component Classes
Page edited by Kalle Korhonen
Changes (1)
...
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]).
{note:title=About initialization} Never initialize an instance field to a mutable object at the point of declaration. If this is done, the instance created from that initializer becomes the default value for that field and is reused inside the component on every request. This could cause state to inadvertently be shared between different sessions in an application. {note}
{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 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}
...
Full Content
Component Classes
Related Articles
Page:
Component Libraries
Page:
Component Cheat Sheet
Page:
Page And Component Classes FAQ
Page:
Component Parameters
Page:
Component Reference
Page:
Component Templates
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
[CONF] Apache Tapestry Component Classes
Component Classes Page edited by Bob Harner Comment: Updated for the new 5.3.2 change that allows instance variables to be any non-public scope. Changes (5) ... h2. Class Transformation Tapestry uses your class as a starting point. It _transforms_ your class at runtime. This is necessary for a number of reasons, including to address how Tapestry pools shares pages between requests. For the most part, these transformations are both sensible and invisible. In a few limited cases, they are marginally [leaky|http://www.joelonsoftware.com/printerFriendly/articles/LeakyAbstractions.html] -- for instance, the requirement that scope restrictions on instance variables be private described below -- but we feel that the programming model in general will support very high levels of developer productivity. Because transformation doesnt occur until _runtime_, the build stage of your application is not affected by the fact that you are creating a Tapestry application. Further, your classes are absolutely simple POJOs during unit testing. ... The net result: super productivity --- change your class, see the change instantly. This is designed to be a blend of the best of scripting environments (such as Python or Ruby) with all the speed and power of Java backing it up. However, class reloading _only_ applies to component classes and, starting in 5.2, Tapestry IOC-based service implementations (with some restrictions). Other classes, such as service interfaces, entity/model classes, or and other data objects, are loaded by the normal class loader and not subject to live class reloading. h2. Instance Variables ... Tapestry components may have instance variables (unlike Tapestry 4, where you had to use _abstract properties_). *Instance variables must be private.* Tapestry must perform runtime class modifications to support instance variables, and may only do so for private variables. You may have non-private variables in your class, but you may then see unexpected behavior in a production application because of how Tapestry pools and reuses pages and components. Tapestry will log an error for each component class that contains fields that are neither static nor private. *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|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Property.html] annotation on the field. ... Full Content Component Classes Related Articles Page: Component Libraries Page: Component Cheat Sheet Page: Component Parameters Page: Component Templates Page: Component Reference 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.
[CONF] Apache Tapestry Component Classes
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
[CONF] Apache Tapestry Component Classes
Component Classes
Page edited by Bob Harner
Comment:
Added intro paragraph about component templates
Changes (1)
...
_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 theres 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|Component Templates]. However, it is also possible for a component class to emit all of its markup itself, without using a template.
h2. Component Class Basics
...
Full Content
Component Classes
Related Articles
Page And Component Classes FAQ
Component Cheat Sheet
Component Templates
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 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.
Sub-Folders / Sub-Packages
Classes do not have to go directly inside the package (pages, components, mixins, etc.). It is valid to create a sub-package to store some of the classes. The sub-package name becomes part of the page name or component type. Thus you might define a page component com.example.myapp.pages.admin.CreateUser and the logical page name (which often shows up inside URLs) will be admin/CreateUser.
Tapestry performs some simple optimizations of the logical page name (or component type, or mixin type). It checks to see if the package name is either a prefix or a suffix of the unqualified class name (case insensitively, of course) and removes the prefix or suffix if so. The net result is that a class name such as com.example.myapp.pages.user.EditUser will have a page name of user/Edit (not user/EditUser). The goal here is to provide shorter, more natural URLs.
Pages vs. Components
The distinction between pages and component is very, very small. The only real difference is the package name: root.pages.PageName for pages, and root.components.ComponentType for components.
[CONF] Apache Tapestry Component Classes
Component Classes
Page edited by Bob Harner
Changes (1)
...
{float}
*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 theres 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 (the case in Tapestry 4).
Classes for pages, for components and for component mixins are all created in an identical way.
...
Full Content
Component Classes
Related Articles
Page And Component Classes FAQ
Component Cheat Sheet
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 (the case in Tapestry 4).
Classes for pages, for components and for component mixins are all created in an identical way.
Component Class Basics
Creating page and component classes in Tapestry 5 is a breeze.
Unlike Tapestry 4, in Tapestry 5, component classes are not abstract, nor do they extend from framework base classes. They are pure POJOs (Plain Old Java Objects).
There are only a few constraints:
The classes must be public.
The classes must be in the correct package, as per the application configuration.
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.");
}
}
This component's only job is to write out a fixed message. The @BeginRender annotation is a type of component lifecycle annotation, a method annotation that instructs Tapestry when and under what circumstances to invoke methods of your class.
In another departure from Tapestry 4, these methods are not necessarily public; they can have any visibility you like.
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.
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 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.
Sub-Folders / Sub-Packages
Classes do not have to go directly inside the package (pages, components, mixins, etc.). It is valid to create a sub-package to store some of the classes. The sub-package name becomes part of the page name or component type. Thus you might define a page component com.example.myapp.pages.admin.CreateUser and the logical page name (which often shows up inside URLs) will be admin/CreateUser.
Tapestry performs some simple optimizations of the logical page name (or component type, or mixin type). It checks to see if the package name is either a prefix or a suffix of the unqualified class name (case insensitively, of course) and removes the prefix or suffix if so. The net result is that a class name such as com.example.myapp.pages.user.EditUser will have a page name of user/Edit (not user/EditUser). The goal here is to provide shorter, more natural URLs.
Pages vs. Components
The distinction in Tapestry 5 between pages and component is very, very small. The only real difference is the package name: root.pages.PageName for pages, and root.components.ComponentType for components.
In Tapestry 4, there was a much greater distinction between pages and components, which showed up as separate interfaces and a hierarchy of abstract implementations to extend your classes from.
In Tapestry 5, the "page" is still somewhat present, but is really an internal Tapestry class. Page components are simply the root component of a page's component tree.
Class Transformation
Tapestry uses your class as a starting point. It transforms your class at runtime. This is necessary for a
