It means that you can't choose or replace components at runtime effectively.
If, say, you'd want to build a portal solution where users could arrange components on a screen any way they wanted, Tapestry would not offer an effective way to do that, because components have static structure, i.e. you must define what goes into them at compile-time in their template file.
Or you might have a specialized menu for administrators, so you might want to just replace the Menu
component with a derived component, AdminMenu
- but you can't, you have to use if
statements in the template or use a block to inject different menus into your layout component.
There's an anti-pattern related to this limitation: The God or über-component tries to solve this problem by effectively having a giant template file with all the available components, like this:
<t:if t:test="displayComponentA">
<span t:type="ComponentA" ... />
</t:if>
<t:if t:test="displayComponentB">
<span t:type="ComponentB" ... />
</t:if>
...
This, however, is horribly ineffective, as Tapestry assembles the entire component tree, including components that are not displayed, to do the rendering of the page.