THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Parameter Bindings
The component above can be referenced in another component or page template, and its parameters bound:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<html t:type="layout" xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd">
<p> Merry Christmas: <t:count end="3"> Ho! </t:count>
</p>
</html>
|
...
Component parameters may also be bound using the @Component annotation inside the component class. (Where conflicts occur, the parameters bound using the Component annotation will take precedence over parameter bindings in the template.)
| Anchor | ||||
|---|---|---|---|---|
|
Using Binding Expressions
The value inside the template, "3" in the previous example, is a binding expression.
...
Only prop: and var: binding prefixes are updateable .(but you must not use the ${..} syntax here; see the next section).
Each parameter has Parameters have a default prefix, usually "prop:"defined by the component, that is used when the prefix is not provided. The most common are "literal:" and "prop:".
A special prefix, "inherit:", is used to support Inherited Parameter Bindings.
Render Variables
Don't use the ${...} syntax!
Main Article: Component Templates#Expansions
You generally should not use the Template Expansion syntax, ${...}, within component parameter bindings. Doing so results in the property inside the braces being converted to an (immutable) string, and will therefore result in a runtime exception if your component needs to update the value (whenever the default or explicit binding prefix is prop: or var:, since such component parameters are two-way bindings).
| Section | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The general rule is, only use the ${...} syntax in non-Tapestry-controlled locations in your template, such as in attributes of ordinary HTML elements and in plain-text areas of your template.
| Section | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Render variables
Components can Components can have any number of render variables. Render variables are named values with no specific type (they are ultimately stored in a Map). Render variables are useful for holding simple values, such as loop indices, that need to be passed from one component to another.
For example, the following template code:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<ul>
<li t:type="loop" source="1..10" value="index">${index}</li>
</ul>
|
And in and the following Java code:
| Code Block | ||||
|---|---|---|---|---|
| ||||
@Property private int index; |
...
In other words, you don't have to define a property in the Java code. The disadvantage is that render variables don't work with the property expression syntax, so you can pass around a render variables variable's value but you can't reference any of the value's properties.
...
The default binding prefix in most cases is "prop:", which is why it is usually omitted.
"Validate:" Bindings
Main Article: Forms and Validation
The "validate:" binding prefix is highly specialized. It allows a short string to be used to create and configure the objects that perform input validation for form control components, such as TextField and Checkbox.
The string is a comma-separated list of validator types. These are short aliases that for objects that perform the validation. In many cases, the validation is configurable in some way: for example, a validator that enforces a minimum string length needs to know what that minimum string length is. Such values are specified after an equals sign.
For example: validate:required,minLength=5 would presumably enforce that a field requires a value, with at least five characters.
"Translate:" Bindings
The "translate:" binding prefix is also related to input validator. It is the name of a configured Translator, responsible for converting between server-side and client-side representations of data (for instance, between client-side strings and server-side numeric values).
...
Required Parameters
Parameters that are required must be bound. A runtime exception occurs if a component has unbound required parametersrequired must be bound. A runtime exception occurs if a component has unbound required parameters. Note: sometimes a parameter is marked "required" but may still be omitted if the underlying value is provided by some other means. This is the case, for example, with the Select component's value parameter, which may have its underlying value set by contributing a ValueEncoderSource. Be sure to read the component's parameter documentation carefully.
Optional Parameters
Parameters which are not required, are optionalare optional unless they are marked as required.
You may set a default value for optional parameters as you would for any other field. In the Count component, the min parameter has a default value of 1. That value is used unless the min parameter is bound, in which case, the bound value supersedes the default.
...