You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by ta...@jakarta.apache.org on 2004/11/03 19:49:47 UTC

[Jakarta Tapestry Wiki] New: ComponentClassEnhacement

   Date: 2004-11-03T10:49:47
   Editor: HowardLewisShip <hl...@apache.org>
   Wiki: Jakarta Tapestry Wiki
   Page: ComponentClassEnhacement
   URL: http://wiki.apache.org/jakarta-tapestry/ComponentClassEnhacement

   no comment

New Page:

Tapestry pages and components are often abstract.  At runtime, Tapestry uses information provided by the class and by the matching page or component specification, to enhance the class.

Enhancement is the creation of a subclass with more methods and fields.

Often the base class is abstract; the enhanced subclass is always concrete.

Class enhnacement began in Tapestry 3.0; the motivation was the number of bugs caused (in 2.3 and earlier) by people not properly resetting instance variables of their pages/components
back to default values when storing a page back into the page pool.

Tapestry 3.0's <property-specification> element (renamed to <property> in 3.1) directed Tapestry on how to create a new transient or persistent property, that would behave properly when the containing page was pooled; it works equally well for pages and components.

This has been improved in Tapestry 3.1; the <inject> element can create a property that corresponds to a HiveMind service.  The <property> element has been simplified and made optional in many common cases.

It is still awkward that the classes you create are abstract.  Tapestry 3.1 includes org.apache.tapestry.test.Creator, a utility class for instantiating abstract classes.  Creator does similar work to the enhancement subsystem; it finds all the properties of the class that are abstract and create simple read/write properties for each one. You can then test your classes.

Tapestry 4.0 will no longer require that your page and component classes inherit from Tapestry base classes or implement Tapestry interfaces; it will be much more PlainOldJavaObjects.  However, it is still likely that the classes will be abstract.

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org