Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Minor formatting (wrapping)

...

There's very little difference between the two. Pages clases must be in the root-package.pages package; components must be in the
root-package.components. Pages may provide event handlers for certain page-specific events (such as activate and passivate). Components may have parameters.

...

LibraryMappings are used to resolve a library prefix to one or more package names. The empty string represents the application itself; the above example
adds two additional root packages; you might see additional pages under com.example.app.tasks.pages, for example.

Warning

Tapestry doesn't check for name collisions, and the order the packages are searched for pages and components is not defined. In general, if you
can get by with a single root package for your application, that is better.

...

Tapestry does a large amount of transformation to your simple POJO classes as it loads them into memory. In many cases, it must locate every read or write of an instance variable and change its behavior; for example, reading a field that is a component parameter will
cause a property of the containing page or component to be read.

Limiting fields to private means that Tapestry can do the necessary processing one class at a time, as needed, at runtime. More complex
Aspect Orient Programming systems such as AspectJ can perform similar transformations (and much more complex ones), but requires a dedicated build step (or the introduction of a JVM agent).

...

Getting informal parameters to work is in two steps. First, you must make a call to the ComponentResources.renderInformalParameters() method, but just as importantly, you must tell Tapestry that you want the component to support
informal parameters, using the SupportsInformalParameters annotation. Here's a hypothetical component that displays an image based on the value of a Image object (presumably, a database entity):

...

The second version is much more complicated; it's the transformed version of your code, with lots of extra hooks and changes to allow the class to operate inside Tapestry. This includes implementing
new interfaces and methods, adding new constructors, and changing access to existing fields and methods.

...

When a page or component is passed as a parameter to a service, a failure occurs
(how it is reported varies in different JDK releases) because of the class mismatch.

...

Info

Ultimately, it's developer choice. HLS prefers the method naming conventions in nearly all cases, especially prototypes and demos, but can see
that in some projects and some teams, an annotation-only approach is best.

...

Tapestry tranforms your class at runtime. It tends to build
a large constructor for the class instance. Further, an instance of the
class is useless by itself, it must be wired together with its template
and its sub-components.

____

...