Author: buildbot
Date: Tue Feb 13 02:20:37 2018
New Revision: 1025319
Log:
Production update by buildbot for tapestry
Modified:
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/component-parameters.html
websites/production/tapestry/content/overriding-exception-reporting.html
websites/production/tapestry/content/switching-cases.html
Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/tapestry/content/component-parameters.html
==============================================================================
--- websites/production/tapestry/content/component-parameters.html (original)
+++ websites/production/tapestry/content/component-parameters.html Tue Feb 13
02:20:37 2018
@@ -180,11 +180,11 @@
</div></div><p>A component may have any number of parameters. Each parameter
has a specific name, a specific Java type (which may be a primitive value), and
may be <em>optional</em> or <em>required</em>.</p><p>Within a component class,
parameters are declared by using the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Parameter.html";>Parameter</a>
annotation on a private field, as we'll see below.</p><p><span
class="confluence-anchor-link"
id="ComponentParameters-bindingparameters"></span></p><h1
id="ComponentParameters-ParameterBindings">Parameter Bindings</h1><p>In
Tapestry, a parameter is not a slot into which data is pushed: it is a
<em>connection</em> between a field of the component (marked with the
@Parameter annotation) and a property or resource of the component's container.
(Components can be nested, so the container can be either the page or another
component.)</p><div class="navmenu" style="float:right; backgr
ound:white; margin:3px; padding:3px">
<div class="panel" style="border-width: 1px;"><div class="panelHeader"
style="border-bottom-width: 1px;"><b>Contents</b></div><div
class="panelContent">
<style type="text/css">/*<![CDATA[*/
-div.rbtoc1518405704819 {padding: 0px;}
-div.rbtoc1518405704819 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1518405704819 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1518488413323 {padding: 0px;}
+div.rbtoc1518488413323 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1518488413323 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style><div class="toc-macro rbtoc1518405704819">
+/*]]>*/</style><div class="toc-macro rbtoc1518488413323">
<ul class="toc-indentation"><li><a
href="#ComponentParameters-ParameterBindings">Parameter Bindings</a></li><li><a
href="#ComponentParameters-BindingExpressions">Binding
Expressions</a></li><li><a
href="#ComponentParameters-@Parameterannotation">@Parameter
annotation</a></li><li><a
href="#ComponentParameters-Don'tusethe${...}syntax!">Don't use the ${...}
syntax!</a></li><li><a href="#ComponentParameters-InformalParameters">Informal
Parameters</a></li><li><a
href="#ComponentParameters-ParametersAreBi-Directional">Parameters Are
Bi-Directional</a></li><li><a
href="#ComponentParameters-InheritedParameterBindings">Inherited Parameter
Bindings</a></li><li><a
href="#ComponentParameters-ComputedParameterBindingDefaults">Computed Parameter
Binding Defaults</a></li><li><a
href="#ComponentParameters-UnboundParameters">Unbound Parameters</a></li><li><a
href="#ComponentParameters-ParameterTypeCoercion">Parameter Type
Coercion</a></li><li><a href="#ComponentParameters-ParameterNames">
Parameter Names</a></li><li><a
href="#ComponentParameters-DeterminingifBound">Determining if
Bound</a></li><li><a
href="#ComponentParameters-PublishingParameters">Publishing
Parameters</a></li></ul>
</div>
</div></div></div> <p>The connection between a component and a property
(or resource) of its container is called a <em>binding</em>. The binding is
two-way: the component can read the bound property by reading its parameter
field. Likewise, a component that updates its parameter field will update the
bound property.</p><p>This is important in a lot of cases; for example a
TextField component can read <em>and update</em> the property bound to its
value parameter. It reads the value when rendering, but updates the value when
the form is submitted.</p><p>The component listed below is a looping component;
it renders its body a number of times, defined by its <code>start</code> and
<code>end</code> parameters (which set the boundaries of the loop). The
component can update a <code>result</code> parameter bound to a property of its
container; it will automatically count up or down depending on whether
<code>start</code> or <code>end</code> is larger.</p><div class="code panel
pdl" st
yle="border-width: 1px;"><div class="codeContent panelContent pdl">
@@ -261,7 +261,7 @@ private int index;
</ul>
</pre>
-</div></div><p>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 variable's <em>value</em>
but you can't reference any of the value's properties.</p><p>Render variables
are automatically cleared when a component finishes rendering.</p><p>Render
variable names are case insensitive.</p><h3
id="ComponentParameters-Property:Bindings">Property: Bindings</h3><p>The
"prop:" binding prefix indicates a property expression binding.</p><p>Property
expressions are used to link a parameter of a component to a property of its
container. Property expressions can navigate a series of properties and/or
invoke methods, as well as several other useful patterns. See <a
href="component-parameters.html">Component Parameters</a>.</p><p>The default
binding prefix in most cases is "prop:", which is why it is usually
omitted.</p><h3 id="ComponentParameters-Validate:Bi
ndings">Validate: Bindings</h3><p>Main Article: <a
href="component-parameters.html">Component Parameters</a></p><p>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.</p><p>The string is a
comma-separated list of <em>validator types</em>. These are short aliases 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.</p><p>For example:
<code>validate:required,minLength=5</code> would presumably enforce that a
field requires a value, and with at least five characters.</p><h3
id="ComponentParameters-Translate:Bindings">Translate: Bindings</h3><p>The
"translate:" binding prefix is also related to input validation. It is t
he name of a configured <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Translator.html";>Translator</a>,
responsible for converting between server-side and client-side representations
of data (for instance, between client-side strings and server-side numeric
values).</p><p>The list of available translators is configured by the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/TranslatorSource.html";>TranslatorSource</a>
service.</p><h3 id="ComponentParameters-Asset:Bindings">Asset:
Bindings</h3><p>Assets bindings are used to specify <a
href="component-parameters.html">Component Parameters</a>, static content
served by Tapestry. By default, assets are located relative to the component
class in your packaged application or module. This can be overridden by
prefixing the path with "context:", in which case, the path is a context path
from the root of the web application context. Becau
se accessing context assets is relatively common, a separate "context:"
binding prefix for that purpose exists (described below).</p><h3
id="ComponentParameters-Context:Bindings">Context: Bindings</h3><p>Context
bindings are like asset bindings, but the path is <em>always</em> relative to
the root of the web application context. This is intended for use inside
templates, i.e.:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p>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 variable's <em>value</em>
but you can't reference any of the value's properties.</p><p>Render variables
are automatically cleared when a component finishes rendering.</p><p>Render
variable names are case insensitive.</p><h3
id="ComponentParameters-Property:Bindings">Property: Bindings</h3><p>Main
Article: <a href="property-expressions.html">Property
Expressions</a></p><p>The "prop:" binding prefix indicates a property
expression binding.</p><p>Property expressions are used to link a parameter of
a component to a property of its container. Property expressions can navigate a
series of properties and/or invoke methods, as well as several other useful
patterns.</p><p>The default binding prefix in most cases is "prop:", which is
why it is usually omitted.</p><h3 id="ComponentParamet
ers-Validate:Bindings">Validate: Bindings</h3><p>Main Article: <a
href="forms-and-validation.html">Forms and Validation</a></p><p>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.</p><p>The string is a
comma-separated list of <em>validator types</em>. These are short aliases 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.</p><p>For example:
<code>validate:required,minLength=5</code> would presumably enforce that a
field requires a value, and with at least five characters.</p><h3
id="ComponentParameters-Translate:Bindings">Translate: Bindings</h3><p>The
"translate:" binding prefix is also related to input vali
dation. It is the name of a configured <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Translator.html";>Translator</a>,
responsible for converting between server-side and client-side representations
of data (for instance, between client-side strings and server-side numeric
values).</p><p>The list of available translators is configured by the <a
class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/TranslatorSource.html";>TranslatorSource</a>
service.</p><h3 id="ComponentParameters-Asset:Bindings">Asset:
Bindings</h3><p>Main Article: <a href="assets.html">Assets</a></p><p>Assets
bindings are used to specify <a href="component-parameters.html">Component
Parameters</a>, static content served by Tapestry. By default, assets are
located relative to the component class in your packaged application or module.
This can be overridden by prefixing the path with "context:", in which case,
the path
is a context path from the root of the web application context. Because
accessing context assets is relatively common, a separate "context:" binding
prefix for that purpose exists (described below).</p><h3
id="ComponentParameters-Context:Bindings">Context: Bindings</h3><p>Main
Article: <a href="assets.html">Assets</a></p><p>Context bindings are like
asset bindings, but the path is <em>always</em> relative to the root of the web
application context. This is intended for use inside templates, i.e.:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"> <img src="${context:images/icon.png}"/>
</pre>
</div></div><p>Tapestry will adjust the URL of the image so that it is
processed by Tapestry, not the servlet container. It will gain a URL that
includes the application's version number, it will have a far-future expires
header, and (if the client supports it) its content will be compressed before
being sent to the client.</p><h1
id="ComponentParameters-@Parameterannotation">@Parameter annotation</h1><h3
id="ComponentParameters-RequiredParameters">Required
Parameters</h3><p>Parameters that are required <strong>must</strong> be bound.
A runtime exception occurs if a component has unbound required
parameters.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
@@ -295,7 +295,7 @@ public String getDefaultMessage(){ 
</div></div></div><div class="columnMacro"><div class="code panel pdl"
style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;"><b>This is wrong</b></div><div
class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><img src="context:images/banner.png"/>
</pre>
-</div></div></div></div></div></div><h1
id="ComponentParameters-InformalParameters">Informal Parameters</h1><p>Main
Article: <a href="component-parameters.html">Component
Parameters</a></p><p>Many components support <em>informal parameters</em>,
additional parameters beyond the formally defined parameters. Informal
parameters will be rendered into the output as additional attributes on the tag
rendered by the component. Generally speaking, components that have a 1:1
relationship with a particular HTML tag (such as <TextField> and
<input> will support informal parameters.</p><p>Only components whose
class is annotated with @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SupportsInformalParameters.html";>SupportsInformalParameters</a>
will support informal parameters. Tapestry silently drops informal parameters
that are specified for components that do not have this
annotation.</p><p>Informal parameters are often
used to set the CSS class of an element, or to specify client-side event
handlers.</p><p>The default binding prefix for informal parameters depends on
<em>where</em> the parameter binding is specified. If the parameter is bound
inside a Java class, within the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Component.html";>Component</a>
annotation, then the default binding prefix is "prop:". If the parameter is
bound inside the component template, then the default binding prefix is
"literal:". This reflects the fact that a parameter specified in the Java
class, using the annotation, is most likely a computed value, whereas a value
in the template should simply be copied, as is, into the result HTML
stream.</p><p>Informal parameters (if supported) are always rendered into the
output <em>unless</em> they are bound to a property whose value is null. If the
bound property is null then the parameter will <em>not</em> be present
at all in the rendered output.</p><p>If your component should render informal
parameters, just inject the <a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ComponentResources.html";>ComponentResources</a>
for your component and invoke the <code>renderInformalParameters()</code>
method. See <a href="component-parameters.html">Component Parameters</a> for
an example of how to do this.</p><h1
id="ComponentParameters-ParametersAreBi-Directional">Parameters Are
Bi-Directional</h1><p>Parameters are not simply variables; each parameter
represents a connection, or <em>binding</em>, between a component and a
property of its container. When using the prop: binding prefix, the component
can force changes <em>into</em> a property of its container, just by assigning
a value to its own instance variable.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div></div></div></div></div><h1
id="ComponentParameters-InformalParameters">Informal Parameters</h1><p>Main
Article: <a href="supporting-informal-parameters.html">Supporting Informal
Parameters</a></p><p>Many components support <em>informal parameters</em>,
additional parameters beyond the formally defined parameters. Informal
parameters will be rendered into the output as additional attributes on the tag
rendered by the component. Generally speaking, components that have a 1:1
relationship with a particular HTML tag (such as <TextField> and
<input> will support informal parameters.</p><p>Only components whose
class is annotated with @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SupportsInformalParameters.html";>SupportsInformalParameters</a>
will support informal parameters. Tapestry silently drops informal parameters
that are specified for components that do not have this
annotation.</p><p>Informal
parameters are often used to set the CSS class of an element, or to specify
client-side event handlers.</p><p>The default binding prefix for informal
parameters depends on <em>where</em> the parameter binding is specified. If the
parameter is bound inside a Java class, within the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Component.html";>Component</a>
annotation, then the default binding prefix is "prop:". If the parameter is
bound inside the component template, then the default binding prefix is
"literal:". This reflects the fact that a parameter specified in the Java
class, using the annotation, is most likely a computed value, whereas a value
in the template should simply be copied, as is, into the result HTML
stream.</p><p>Informal parameters (if supported) are always rendered into the
output <em>unless</em> they are bound to a property whose value is null. If the
bound property is null then the parameter will <em
>not</em> be present at all in the rendered output.</p><p>If your component
>should render informal parameters, just inject the <a class="external-link"
>href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ComponentResources.html";>ComponentResources</a>
> for your component and invoke the <code>renderInformalParameters()</code>
>method. See <a href="supporting-informal-parameters.html">Supporting
>Informal Parameters</a> for an example of how to do this.</p><h1
>id="ComponentParameters-ParametersAreBi-Directional">Parameters Are
>Bi-Directional</h1><p>Parameters are not simply variables; each parameter
>represents a connection, or <em>binding</em>, between a component and a
>property of its container. When using the prop: binding prefix, the component
>can force changes <em>into</em> a property of its container, just by
>assigning a value to its own instance variable.</p><div class="code panel
>pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><t:layout
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
<p> Countdown:
<t:count start="5" end="1" result="index">
@@ -375,7 +375,7 @@ public class Title {
return String.format("Maximum field length is %d.", maxLength);
}
</pre>
-</div></div><p>This form is more like using the "literal:" binding prefix,
except that the literal value is computed by the defaultMessage()
method.</p><p>Obviously, this is a lot more work than simply specifying a
default value as part of the @Parameter annotation. In the few real cases where
this is approach is used, the default binding method will usually deduce a
proper binding, typically in terms of the component's id. For example, the
TextField component will deduce a value parameter that binds to a property of
its container with the same name.</p><p>A default binding method will
<em>only</em> be invoked if the @Parameter annotation does not provide a
default value.</p><h1 id="ComponentParameters-UnboundParameters">Unbound
Parameters</h1><p>If a parameter is not bound (and is optional), then the value
may be read or <em>updated</em> at any time.</p><p>Updates to unbound
parameters cause no side effects. In the first example, the value parameter of
the Count component is not bo
und, and this is perfectly valid.</p><p>Note: updates to such fields are
temporary; when the component <em>finishes rendering</em>, the field will
revert to its default value.</p><h1
id="ComponentParameters-ParameterTypeCoercion">Parameter Type
Coercion</h1><p>Main Article: <a href="component-parameters.html">Component
Parameters</a></p><p>Tapestry includes a mechanism for <span
class="confluence-link">coercing types automatically</span>. Most often, this
is used to convert literal strings into appropriate values, but in many cases,
more complex conversions will occur. This mechanism is used for component
parameters, such as when an outer component passes a literal string to an inner
component that is expecting an integer.</p><p>You can easily <a
href="component-parameters.html">contribute new coercions</a> for your own
purposes.</p><h1 id="ComponentParameters-ParameterNames">Parameter
Names</h1><p>By default, Tapestry converts from the field name to the parameter
name, by strippi
ng off leading "$" and "_" characters.</p><p>This can be overridden using the
name() attribute of the @Parameter annotation.</p><h1
id="ComponentParameters-DeterminingifBound">Determining if Bound</h1><p>In rare
cases, you may want to take different behaviors based on whether a parameter is
bound or not. This can be accomplished by querying the component's resources,
which can be <a href="component-parameters.html">injected</a> into the
component using the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Inject.html";>Inject</a>
annotation:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p>This form is more like using the "literal:" binding prefix,
except that the literal value is computed by the defaultMessage()
method.</p><p>Obviously, this is a lot more work than simply specifying a
default value as part of the @Parameter annotation. In the few real cases where
this is approach is used, the default binding method will usually deduce a
proper binding, typically in terms of the component's id. For example, the
TextField component will deduce a value parameter that binds to a property of
its container with the same name.</p><p>A default binding method will
<em>only</em> be invoked if the @Parameter annotation does not provide a
default value.</p><h1 id="ComponentParameters-UnboundParameters">Unbound
Parameters</h1><p>If a parameter is not bound (and is optional), then the value
may be read or <em>updated</em> at any time.</p><p>Updates to unbound
parameters cause no side effects. In the first example, the value parameter of
the Count component is not bo
und, and this is perfectly valid.</p><p>Note: updates to such fields are
temporary; when the component <em>finishes rendering</em>, the field will
revert to its default value.</p><h1
id="ComponentParameters-ParameterTypeCoercion">Parameter Type
Coercion</h1><p>Main Article: <a
href="parameter-type-coercion.html">Parameter Type Coercion</a> </p><p>Tapestry
includes a mechanism for <span class="confluence-link">coercing types
automatically</span>. Most often, this is used to convert literal strings into
appropriate values, but in many cases, more complex conversions will occur.
This mechanism is used for component parameters, such as when an outer
component passes a literal string to an inner component that is expecting an
integer.</p><p>You can easily <a href="component-parameters.html">contribute
new coercions</a> for your own purposes.</p><h1
id="ComponentParameters-ParameterNames">Parameter Names</h1><p>By default,
Tapestry converts from the field name to the parameter name
, by stripping off leading "$" and "_" characters.</p><p>This can be
overridden using the name() attribute of the @Parameter annotation.</p><h1
id="ComponentParameters-DeterminingifBound">Determining if Bound</h1><p>In rare
cases, you may want to take different behaviors based on whether a parameter is
bound or not. This can be accomplished by querying the component's resources,
which can be <a href="component-parameters.html">injected</a> into the
component using the @<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Inject.html";>Inject</a>
annotation:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">public class MyComponent
{
@Parameter
Modified:
websites/production/tapestry/content/overriding-exception-reporting.html
==============================================================================
--- websites/production/tapestry/content/overriding-exception-reporting.html
(original)
+++ websites/production/tapestry/content/overriding-exception-reporting.html
Tue Feb 13 02:20:37 2018
@@ -118,7 +118,7 @@
</div>
-<p>Of course, one of the first questions anyone asks is "How do I turn it
off?" This exception reporting is very helpful for developers but its easy to
see it as terrifying for potential users. Catching runtime exceptions can be a
very useful way of handling rarely occurring exceptions even in production, and
there's no reason to throw away Tapestry's default error reporting just to
handle a few specific exceptions. From version 5.4 (for previous versions, the
same functionality is available as a <a class="external-link"
href="http://www.tynamo.org/tapestry-exceptionpage+guide/";
rel="nofollow">third-party module tapestry-exceptionpage</a>), you can
contribute exception handles and/or exception pages for specific exception
types. Refer back to <a href="overriding-exception-reporting.html">Overriding
Exception Reporting</a> page for more information. Read on if you want to
completely replace Tapestry's default exception handling.</p><h2
id="OverridingExceptionReporting-Version1:Repl
acingtheExceptionReportPage">Version 1: Replacing the Exception Report
Page</h2><p>Let's start with a page that fires an exception from an event
handler method.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeHeader panelHeader pdl" style="border-bottom-width:
1px;"><b>ActionFail.tml</b></div><div class="codeContent panelContent pdl">
+<p>Of course, one of the first questions anyone asks is "How do I turn it
off?" This exception reporting is very helpful for developers but its easy to
see it as terrifying for potential users. Catching runtime exceptions can be a
very useful way of handling rarely occurring exceptions even in production, and
there's no reason to throw away Tapestry's default error reporting just to
handle a few specific exceptions. From version 5.4 (for previous versions, the
same functionality is available as a <a class="external-link"
href="http://www.tynamo.org/tapestry-exceptionpage+guide/";
rel="nofollow">third-party module tapestry-exceptionpage</a>), you can
contribute exception handles and/or exception pages for specific exception
types. Refer back to <a href="runtime-exceptions.html">Runtime
Exceptions</a> page for more information. Read on if you want to completely
replace Tapestry's default exception handling.</p><h2
id="OverridingExceptionReporting-Version1:ReplacingtheExceptionRe
portPage">Version 1: Replacing the Exception Report Page</h2><p>Let's start
with a page that fires an exception from an event handler method.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeHeader
panelHeader pdl" style="border-bottom-width:
1px;"><b>ActionFail.tml</b></div><div class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"> <html
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd"; t:type="layout"
title="Action Fail">
<p>
<t:actionlink t:id="fail" class="btn btn-large
btn-warning">Click for Exception</t:actionlink>
Modified: websites/production/tapestry/content/switching-cases.html
==============================================================================
--- websites/production/tapestry/content/switching-cases.html (original)
+++ websites/production/tapestry/content/switching-cases.html Tue Feb 13
02:20:37 2018
@@ -80,7 +80,7 @@
<div id="ConfluenceContent"><p> </p><h1
id="SwitchingCases-SwitchingCases">Switching Cases</h1><p>With Tapestry's
<code>If</code> component you can only test one condition at a time. In order
to distinguish multiple cases, you'd have to write complex nested if/else
constructs in your page template and have a checker method for each test inside
your page class.</p><div class="navmenu" style="float:right; background:#eee;
margin:3px; padding:0 1em">
<p> <strong>JumpStart Demo:</strong><br clear="none">
<a class="external-link"
href="http://jumpstart.doublenegative.com.au/jumpstart/examples/lang/ifnotnegateswitchelseunless";
rel="nofollow">If, Not, Negate, Switch, Else, Unless</a></p></div>In cases
where you have to distinguish multiple cases, the <code>Delegate</code>
component comes in. It delegates rendering to some other component, for example
a <code>Block</code>. For each case you have, you basically wrap the content
inside a <code>Block</code> that doesn't get rendered by default. You then
place a Delegate component on your page and point it to a method inside your
page class that will decide which of your Blocks should be rendered.<p>Imagine
for example a use case, where you want to distinguish between 4 cases and you
have an int property called <code>whichCase</code> that should be tested
against. Your page template would look as follows:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;">
<b>SwitchMe.tml</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><html
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd">
+<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><html
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd">
<body>
<h1>Switch</h1>
