Link Details

Seemed to go out of its way to display Tapestry (4.1) in the worst possible light; for example, using lots of XML for components rather than the annotations available in 4.1, which are much more concise.

Looking more closely, I think I agree with Howard's comment. It's entirely plausible that a better picture of Tapestry could have emerged if the authors had used annotations.

I would like to see a comparison of the support given in each framework for living by the DRY (Don't Repeat Yourself) principle.

For example, suppose I use a drop-down choice box containing the same seven options at many different places in my web application. One might compare the ease by which the developer can create and use a new choice box component that is pre-populated with those seven items (so that the list of options need not be repeated many times on the page), and which makes the code easier to read by providing the new component a name suggestive of its role in the business logic.

In some frameworks, creation of a new component requires so much code that people are tempted to just cut-and-paste the same seven choices into each occurance. I don't know what support Tapestry provides, but in Wicket all you need do is declare a subclass of the choice box class, provide the subclass with a simpler constructor that provides the seven choices in a call to the base class' constructor, and give the subclass a name suggestive of the information the user provides through it. Then the developer can simply use subclass every time he needs a dropdown with those seven values.

Admittedly, this is a somewhat contrived example, but I'd like to see whether Tapestry, like Wicket, provides the full power of object orientation when it comes to arranging and configuring components.
,

An interesting observation about reusability; Tapestry goes quite a bit further than Wicket in this situation; you can certainly roll a new component for editing a Foo data type, but in Tapestry you have several additional vectors of reuse. In your example, we could using a Select component tied to a property and the TYPE of the property would dictate the model used by the Select component. There is built-in support for the enum data type, and adding your own application-specific data types is fully supported.

You will end up with something like:

>

Here the component will, by default, bind to a property named "status" of the containing page (or component). The type of the status property is used to obtain a default SelectModel; it is the model that provides the server-side values and client-side strings and labels.

Part of the focus in Tapestry is to ruthlessly eliminate redundant and boilerplate code (both on the Java side, and in the templates) through the use of sensible, or even smart, defaults. One of the "hidden" features I am proud of in Tapestry is that you can write a code snippet (a specially named method) to provide a default value, or default parameter binding, for an otherwise unbound parameter.