Using Tapestry

Tapestry is great for writing java web application hosted user interfaces. The version 4.0 with its HiveMind integration is extremely powerful. The Hivemind part of the jigsaw together with Tapestry's use of annotations encourages a clean, reusable style of coding - it took a while but i finally "got" depenendency injection. The Hivemind wiring together with EasyMock makes both unit testing and integration testing simple and very practical.

(Aside: When Tim Bray says he might have a go at writing his comments system in EE, I would heartily recommend he look at Tapestry.)

Having said that I have run up against some annoying issues.

These range from the trival:

• Can not localise a submit button


• Can not put a FieldLabel after it's component


• Finding the correct replacement (usually the service name) for deprecated methods is long winded when not specified in the JavaDoc


• The HiveMind docs are very fragmented - even now I know what I am looking for I still end up search in three different sections to find it...

There are also some other issues I ran up against in building an edit compenent for a POJO that are slightly more vexing.

• The sub-component structure of a component is fixed at compile time, and the only interface for passing info at compile time to a component is through the component's name. This means I ended up inventing a naming convention to pass information to be processed when the component specification is resolved.


• In HiveMind, the javassist integration is limited by the limited interface exported by HiveMind, and the inaccessibility of its ClassPool

I am also having problems localising a component coming from a library - but I think that is a understanding issue on how the IComponentSpecification's Location affects the message catalog resolution ...

Tapestry Edit Component

Howard Lewis-Ship wrote about having an edit component for a pojo.

<span jwcid="@edit:EditObject" object="ognl:pojo"/>

I had already started working on such a component, after getting fed up of creating edit pages by hand. I have posted some (alpha) code at http://www3.sympatico.ca/hugo.duncan/EditComponent.tar.gz.

The component is referenced as Edit<class.name.to.display>.

The object to edit is passed using the item parameter.

The layout parameter can be used to pass a literal string selecting a layout. The default layout is "table", which produces a table, where each property is on a new table row. Template layouts can be contributed to a hivemind service. eg. TemplateLayoutTableColumns provides a layout for one row per object views of a collection.

The type of component used to display a property can be specified in the component specification, eg. Edit<class.name.to.display,myfield=TextFieldPropertyComponent>. Selecting a component of null suppresses the property from being displayed.

The default type of component selected to display and edit a property can be set by contributing a IComponentProvider to the tapestry.contrib.editor.ComponentProviders configuration point.

Bindings on this component of the form "subcomponent.parameter" are forwarded to the subcomponent.

To display collections, parameters mimicking the For component parameters are used.

A sequence parameter can be used to specify the order in which the properties are displayed.