Page History

{float:right|background=#eee}
{contentbylabel:title=Related Articles|showLabels=false|showSpace=false|space=@self|labels=component-classes,components}
{float}

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.

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.

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.

Creating a Trivial Component

...

Here's a minimal component that outputs a fixed message, using a template with a matching file name:

...

In this example, just like the first one, the component's only job is to write out a fixed message. The @BeginRender annotation is a type of render phase annotation

, a method annotation that instructs Tapestry when and under what circumstances to invoke methods of your class.

...

...

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 instead of user/EditUser). The goal here is to provide shorter, more natural URLs.

...

One special simplification are exists for Index pages: if the logical page name is Index after removing the package name from the unqualified class name, it will map to the root of that folder. A class such as com.example.myapp.pages.user.IndexUser or com.example.myapp.pages.user.UserIndex will have a page name of user/.

...

The distinction between pages and component is very, very small. The only real primary difference is the package name: root.pages.PageName for pages, and root.components.ComponentType for components. Conceptually, page components are simply the root component of a page's component tree.

...

For the most part, these transformations are both sensible and invisible. In a few limited cases, they are marginally leaky – comprise a marginally leaky abstraction – for instance, the scope restrictions on instance variables described below – but we feel that the programming model in general will support supports a very high levels level of developer productivity.

...

However, class reloading only applies to component classes (pages, components and mixins) and, starting in 5.2, Tapestry IOC-based service implementations (with some restrictions). Other classes, such as service interfaces, entity/model classes, and other data objects, are loaded by the normal class loader and not subject to live class reloading.

...

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

Be aware that you will need to either 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, or else annotate the fields with @Property.

Transient Instance Variables

...

...

Technically, the start and end parameters should be bound to properties, just the like the value parameter. However, certain literal values, such as the numeric literals in the example, are accepted by the prop: binding prefix even though they are not actually properties (this is largely as a convenience to the application developer). We could also use the literal: prefix, "start=literal:5", which accomplishes largely the same thing.

...

If you define a component in the component class, and there is no corresponding element in the template, Tapestry will log an error. In the example above that would be the case if the template for the Countdown page didn't contain an element with <t:count t:id="count">.