Page History

...

Mixins are used in two different scenarios: Instance mixins and Implementation mixins.

Mixin Classes

Mixin classes are stored in a mixins sub-package, below the application (or library) root package. This parallels where component and page classes are stored.

Other than that, mixin classes are exactly the same as any other component class.

Mixin Limitations

Currently, mixins are allowed to do anything a component can do, including parameters, render phase methods.

...

Mixins may not, themselves, have mixins.

Instance Mixins

An instance mixin is a mixin applied to a specific instance of a component. This can be done in the component template with the mixins attribute of the <comp> element. This is a comma-separated list of mixin names.

...

This example defines a component of type TextField and mixes in the hypothetical Autocomplete and DefaultFromCookie mixins.

Implementation Mixins

Implementation mixins, mixins which apply to all isntances of a component, are added using the Mixin annotation. This annotation defines a field that will containg the mixin instance.

...

public class AutocompleteField extendes TextField
{
  @Mixin("Autocomplete")
  private Object autocompleteMixin;
  
  . . .
}

Mixin Parameters

Mixins are allowed to have parameters, just like components.

...

  @Component(parameters={"Autocomplete.id=auto", . . . }) @Mixins("Autocomplete", "DefaultFromCookie"})
  private TextField userId;

Render Phase Ordering

All mixins for a component execute their render phase methods before the component's render phase methods for most phases. However, in the later phases (AfterRender, CleanupRender) the order of executing is reversed.

Exception: Mixins whose class is annotated with MixinAfter are ordered after the component, not before.

Additional Tools

Tapestry-Mixins is a third-part Tapestry module that allows XPath traversal of the Tapestry (server-side) DOM, which can be extremely useful in certain mixins.