| 4.2. Parameters and Bindings | ||
|---|---|---|
 | Chapter 4. Tapestry Components - A Primer |  |
| 4.2. Parameters and Bindings | ||
|---|---|---|
| | Chapter 4. Tapestry Components - A Primer | |
Tapestry components, we said, are reusable black boxes that take in some input and add value to the container. The input to these components is provided in the form of parameters.
![[Note]](common-images/note.png) | Note |
|---|---|
| Web pages are top level specialized components that cannot have parameters. | |
Parameters are the gateway to configuring components. Component parameters are somewhat similar to method parameters but not quite the same. Component parameters, in contrast to method parameters, hold the property that provides the value for the parameter instead of the actual property value. The actual value is obtained from the held property just-in-time when the component needs it. The property is held in the component in a specially wrapped object called binding (IBinding). The IBinding enables the component to be decoupled from the actual parameter value. And this decoupling enables the component to be shared across multiple concurrent sessions - a major facet in Tapestry's strategy for maintaining application scalability.
![[Tip]](common-images/tip.png) | Tip |
|---|---|
| Tapestry uses OGNL to retrieve the actual value from the property held in the IBinding and hence the binding property can actually be an OGNL expression, not just a simple JavaBeans property. | |
The binding expression is evaluated in the context of the container component. Hence the expression userName will evaluate to getUserName() (and/or setUserName() depending on the parameter direction) in the container component class.
Component parameters are specified at the time of component definition in the component specification. Component parameters, like method parameters, are statically typed and their type is part of their specification. Parameter bindings are specified at the time of component declaration in the container template or specification as shown below.
| Note |
|---|---|
| Properties, bound to the parameters, should be of the same type as that of the parameter they are bound to. | |
Parameter bindings can be one of five types depending on the nature of the bound expression.
This is the most prevalent form of binding where the expression is stored in the binding and evaluated just-in-time when the component needs it.
Dynamic binding in templates.
... <span jwcid="@Insert" value="ognl:userName" /> ... |
The attribute, "value", here is the actual component parameter name and the attribute value is the parameter binding expression. The ognl: prefix in the expression denotes that the expression is a dynamic binding expression.
Dynamic binding in specifications.
... <binding name="value" expression="userName" /> ... |
The <binding> tag in the specification denotes a dynamic binding. The attribute, "name", denotes the component parameter, "value", being bound. And the attribute, "expression", denotes the dynamic expression being bound.
This type of binding is used when a constant value needs to be passed to the parameter. Unlike dynamic binding, the value is read once and cached in the component for future use.
Static binding in templates.
... <span jwcid="@Insert" value="User Name" /> ... |
The attribute, "value", here is the actual component parameter name and the attribute value is the static parameter value. The lack of a prefix in the attribute value denotes that this is a static binding.
Static binding in specifications.
... <static-binding name="value" value="User Name" /> ... |
The <static-binding> tag in the specification denotes a static binding. The attribute, "name" denotes the component parameter, "value", being bound. And the attribute, "value", denotes the actual value being bound to the parameter.
This type of binding is used when the value for the parameter needs to be obtained from a localized properties file. This properties file is very much similar to the PropertyResourceBundle.
The value for the parameter may be obtained from any of the properties files for the component by performing a methodical search, much like the PropertyResourceBundle.
For example, a component, Border, may have the following properties files for locale, fr_BE:
Border_fr_BE.properties - This is the most specific file for locale, fr_BE.
Border_fr.properties
Border.properties - This is the least specific file for locale, fr_BE.
Here, Tapestry first searches the property key in Border_fr_BE.properties and then works its way down to the least specific properties file until the key is found in one of the properties files.
| Note |
|---|---|
| If the key, bound to the parameter, is not found in any of the applicable properties files, Tapestry would simply return the key in the following format: [KEY]. | |
Message binding in templates.
... <span jwcid="@Insert" value="message:label.userName" /> ... |
The attribute, "value", here is the actual component parameter name and the attribute value is the message binding expression. The message: prefix in the attribute value denotes that this is a message binding.
Message binding in specifications.
... <message-binding name="value" key="label.userName" /> ... |
The <message-binding> tag in the specification denotes a message binding. The attribute, "name" denotes the component parameter, "value", being bound. And the attribute, "key", denotes the property key being bound to the parameter.
| Tip |
|---|---|
| Message binding can be helpful in localizing simple strings on the web page. It is also possible to localize the entire web page via localized-templates as we will see later. | |
This type of binding is used when the container component's parameter value needs to be passed into the embedded component unaltered.
Inherited binding in specifications.
... <inherited-binding name="value" parameter-name="userName" /> ... |
The <inherited-binding> tag in the specification denotes an inherited binding. The attribute, "name" denotes the component parameter, "value", being bound. And the attribute, "parameter-name", denotes the container parameter being bound to the component parameter.
| Note |
|---|---|
| This type of binding is not possible in the template. | |
This type of binding defines an in-place script using a scripting language supported by (Bean Scripting Framework). The script itself is the element's character data (often, inside a CDATA block).
| Tip |
|---|---|
| The default language is Jython, though this can be overridden. Please see configuration values for details. | |
| |  | |
| 4.1. Implicit and Explicit Component Usage |  | 4.3. Parameter Directions |