tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1025319 - in /websites/production/tapestry/content: cache/main.pageCache component-parameters.html overriding-exception-reporting.html switching-cases.html
Date Tue, 13 Feb 2018 02:20:37 GMT
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>&#160;<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;
 &lt;/ul&gt;
 
 </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;">  &lt;img
src="${context:images/icon.png}"/&gt;
 </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(){&#160;
 </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;">&lt;img
src="context:images/banner.png"/&gt;
 </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 &lt;TextField&gt;
and &lt;input&gt; 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 &lt;TextField&gt; and &lt;input&gt; 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&#160;<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;">&lt;t:layout
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd"&gt;
     &lt;p&gt; Countdown:
         &lt;t:count start="5" end="1" result="index"&gt;
@@ -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:&#160;<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&#160;<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;"> &lt;html
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd" t:type="layout" title="Action
Fail"&gt;
         &lt;p&gt;
             &lt;t:actionlink t:id="fail" class="btn btn-large btn-warning"&gt;Click
for Exception&lt;/t:actionlink&gt;

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>&#160;</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;">&lt;html
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"&gt;
+<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;html
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd"&gt;
     &lt;body&gt;
         &lt;h1&gt;Switch&lt;/h1&gt;
 



Mime
View raw message