This is an automated email from the ASF dual-hosted git repository.
asf-gitbox-commits pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/struts-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 801b5a09b Automatic Site Publish by Buildbot
801b5a09b is described below
commit 801b5a09bfc11ead06f1a9cfdf8ddaa61f82bda7
Author: buildbot <[email protected]>
AuthorDate: Wed Sep 16 06:57:19 2026 +0000
Automatic Site Publish by Buildbot
---
output/tag-developers/alt-syntax.html | 49 +++++++++++++----------------------
output/tag-developers/tag-syntax.html | 37 ++++++++++++--------------
2 files changed, 35 insertions(+), 51 deletions(-)
diff --git a/output/tag-developers/alt-syntax.html
b/output/tag-developers/alt-syntax.html
index 5383cbbe8..576870622 100644
--- a/output/tag-developers/alt-syntax.html
+++ b/output/tag-developers/alt-syntax.html
@@ -155,24 +155,16 @@
<h1 id="alt-syntax">Alt Syntax</h1>
<blockquote>
- <p>Note: As from Struts 2.6 option to disable the AltSyntax has been removed
and now using %{…} is the only way
-to create an expression as stated below.</p>
+ <p>Note: This page is history. The <code class="language-plaintext
highlighter-rouge">%{ ... }</code> notation described here is the only tag
syntax since Struts 2.6, when the
+option to disable it was removed (WW-3877). See <a href="tag-syntax">Tag
Syntax</a> for how tag attributes are evaluated today.</p>
</blockquote>
-<p>The <em>altSyntax</em> is an option that can be defined in <code
class="language-plaintext highlighter-rouge">struts.xml</code>. By default it
is set to true and it is <strong>strongly</strong>
-recommend you do not change that unless you are upgrading from WebWork 2.1.7
or previous versions.</p>
+<p>The <em>altSyntax</em> was an option introduced in WebWork 2.1.4 that
changed how tag attributes are interpreted. Before it,
+every tag attribute was evaluated against the value stack as an expression, so
string literals had to be marked with
+single quotes. With the altSyntax, only expressions enclosed in <code
class="language-plaintext highlighter-rouge">%{}</code> are evaluated and
everything else is taken
+literally.</p>
-<blockquote>
- <p>You can also turn on the altSyntax on a per-page basis by using the
<em>set</em> tag. Simply set the name <em>useAltSyntax</em><br />
-to the value <em>true</em> . From this point on, all tags will use the
altSyntax for the rest of the request.</p>
-</blockquote>
-
-<p>The altSyntax changes the behavior of how tags are interpreted. Instead of
evaluating each tag parameter against
-the value stack and needing single quotes to mark string literals, only marked
expressions are evaluated.</p>
-
-<p>Example:</p>
-
-<p>the following code uses the <a href="tag-syntax">Tag Syntax</a>:</p>
+<p>The old syntax:</p>
<div class="language-jsp highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><s:iterator </span><span
class="na">value=</span><span class="s">"cart.items"</span><span
class="nt">></span>
...
@@ -182,8 +174,8 @@ the value stack and needing single quotes to mark string
literals, only marked e
<span class="nt"></s:iterator></span>
</code></pre></div></div>
-<p>this is somewhat counter intuitive to normal HTML tag behaviour, and you
get loads of single quotes. Now the same example
-in altSyntax:</p>
+<p>This was counter-intuitive next to normal HTML tag behaviour and produced
loads of single quotes. The same example in
+the altSyntax, which is the syntax Struts uses today:</p>
<div class="language-jsp highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><s:iterator </span><span
class="na">value=</span><span class="s">"cart.items"</span><span
class="nt">></span>
...
@@ -193,23 +185,18 @@ in altSyntax:</p>
<span class="nt"></s:iterator></span>
</code></pre></div></div>
-<p>Only expressions enclosed with <code class="language-plaintext
highlighter-rouge">%{}</code> are evaluated. The code is shorter and clearer,
very similar to JSTL EL usage.
-Quoting problems, eg. with javascript function calls, are avoided.</p>
-
-<p>In order to fully understand why this option exists and what the
differences are, it is best to get a bit of history
-about WebWork.</p>
-
-<blockquote>
- <p>If you are <em>not</em> upgrading from WebWork 2.1.7 or previous versions
and you don’t care about the history of WebWork’s
-evolution, you can skip this section. See the <a href="tag-syntax">Tag
Syntax</a> section for more information
-on the standard tag syntax support</p>
-</blockquote>
+<p>The code is shorter and clearer, very similar to JSTL EL usage, and quoting
problems, e.g. with JavaScript function
+calls, are avoided.</p>
<h2 id="history">History</h2>
-<p>In WebWork 2.1.4, the altSyntax option was introduced. The book, WebWork in
Action, while based around WebWork 2.1.7,
-was entirely written with the assumption that the altSyntax was enabled. As of
WebWork 2.2, the altSyntax is turned
-on by default and eventually the old syntax will no longer be supported and
will be removed from the code.</p>
+<p>The book WebWork in Action, while based around WebWork 2.1.7, was entirely
written with the assumption that the
+altSyntax was enabled. As of WebWork 2.2 it was turned on by default, with a
<code class="language-plaintext highlighter-rouge">struts.xml</code> constant
and a per-request
+<code class="language-plaintext highlighter-rouge">useAltSyntax</code> flag to
switch back to the old syntax. Struts 2.6 removed both, and with them the old
syntax.</p>
+
+<p>Documentation written for the old syntax survives in places. If you meet an
example where a plain property name is
+passed to <code class="language-plaintext highlighter-rouge">value</code> on a
form tag and expected to be evaluated, it predates the altSyntax; today that
requires
+<code class="language-plaintext
highlighter-rouge">value="%{property}"</code>.</p>
</section>
</article>
diff --git a/output/tag-developers/tag-syntax.html
b/output/tag-developers/tag-syntax.html
index 39350a25e..7adc38562 100644
--- a/output/tag-developers/tag-syntax.html
+++ b/output/tag-developers/tag-syntax.html
@@ -166,9 +166,9 @@
<li><a href="#evaluating-booleans-verbose-with-property"
id="markdown-toc-evaluating-booleans-verbose-with-property">Evaluating booleans
(verbose with property)</a></li>
</ul>
</li>
- <li><a href="#value-is-an-object" id="markdown-toc-value-is-an-object">value
is an Object!</a></li>
- <li><a href="#probably-wrong" id="markdown-toc-probably-wrong">Probably
wrong!</a></li>
- <li><a href="#passing-a-literal-value-the-right-way"
id="markdown-toc-passing-a-literal-value-the-right-way">Passing a literal value
the right way</a></li>
+ <li><a href="#the-value-attribute-of-form-tags"
id="markdown-toc-the-value-attribute-of-form-tags">The value attribute of form
tags</a></li>
+ <li><a href="#passing-a-literal-value"
id="markdown-toc-passing-a-literal-value">Passing a literal value</a></li>
+ <li><a href="#reading-a-property"
id="markdown-toc-reading-a-property">Reading a property</a></li>
<li><a href="#expression-language-notations"
id="markdown-toc-expression-language-notations">Expression Language
Notations</a></li>
<li><a href="#disallowed-property-names"
id="markdown-toc-disallowed-property-names">Disallowed property names</a></li>
<li><a href="#escaping-body-of-a-tag"
id="markdown-toc-escaping-body-of-a-tag">Escaping body of a tag</a></li>
@@ -230,31 +230,30 @@ The value is evaluated as an expression and automtically
converted to a boolean.
<div class="language-html highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><s:select</span> <span
class="na">key=</span><span class="s">"state.label"</span> <span
class="na">name=</span><span class="s">"state"</span> <span
class="na">multiple=</span><span class="s">"%{allowMultiple}"</span><span
class="nt">/></span>
</code></pre></div></div>
-<h2 id="value-is-an-object">value is an Object!</h2>
+<h2 id="the-value-attribute-of-form-tags">The value attribute of form tags</h2>
-<p>Most often, the <code class="language-plaintext
highlighter-rouge">value</code> attribute is set automatically, since <code
class="language-plaintext highlighter-rouge">name</code> attribute usually
tells the framework which
-property to call to set the <code class="language-plaintext
highlighter-rouge">value</code>. But, if there is a reason to set the <code
class="language-plaintext highlighter-rouge">value</code> directly, be advised
that <code class="language-plaintext highlighter-rouge">value</code>
-<strong>is an Object <em>NOT</em> a String</strong>.</p>
+<p>Most often, the <code class="language-plaintext
highlighter-rouge">value</code> attribute is set automatically, since the <code
class="language-plaintext highlighter-rouge">name</code> attribute tells the
framework which
+property to read. If there is a reason to set <code class="language-plaintext
highlighter-rouge">value</code> directly, be advised that on the form tags —
<code class="language-plaintext highlighter-rouge">textfield</code>,
+<code class="language-plaintext highlighter-rouge">password</code>, <code
class="language-plaintext highlighter-rouge">textarea</code>, <code
class="language-plaintext highlighter-rouge">hidden</code>, <code
class="language-plaintext highlighter-rouge">select</code> and the like — <code
class="language-plaintext highlighter-rouge">value</code> <strong>is a String
attribute</strong>: it is parsed for the
+<code class="language-plaintext highlighter-rouge">%{ ... }</code> notation,
and anything outside that notation is used literally.</p>
-<blockquote>
- <p>NOTE: Since <code class="language-plaintext
highlighter-rouge">value</code> is not a String, whatever is passed to <code
class="language-plaintext highlighter-rouge">value</code> is evaluated as an
expression - <strong>NOT</strong> a String literal.</p>
-</blockquote>
-
-<h2 id="probably-wrong">Probably wrong!</h2>
+<h2 id="passing-a-literal-value">Passing a literal value</h2>
<div class="language-html highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><s:textfield</span> <span
class="na">key=</span><span class="s">"state.label"</span> <span
class="na">name=</span><span class="s">"state"</span> <span
class="na">value=</span><span class="s">"ca"</span><span class="nt">/></span>
</code></pre></div></div>
-<p>If a <code class="language-plaintext highlighter-rouge">textfield</code> is
passed the value attribute <code class="language-plaintext
highlighter-rouge">ca</code>, the framework will look for a property named
<code class="language-plaintext highlighter-rouge">getCa</code>. Generally,
-this is not what we mean. What we mean to do is pass a literal String. In the
expression language, literals are placed
-within quotes</p>
+<p>The field is rendered with the literal text <code class="language-plaintext
highlighter-rouge">ca</code>; the framework does <strong>not</strong> look for
a <code class="language-plaintext highlighter-rouge">getCa</code> property.</p>
-<h2 id="passing-a-literal-value-the-right-way">Passing a literal value the
right way</h2>
+<h2 id="reading-a-property">Reading a property</h2>
-<div class="language-html highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><s:textfield</span> <span
class="na">key=</span><span class="s">"state.label"</span> <span
class="na">name=</span><span class="s">"state"</span> <span
class="na">value=</span><span class="s">"%{'ca'}"</span> <span
class="nt">/></span>
+<div class="language-html highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><s:textfield</span> <span
class="na">key=</span><span class="s">"state.label"</span> <span
class="na">name=</span><span class="s">"state"</span> <span
class="na">value=</span><span class="s">"%{selectedState}"</span><span
class="nt">/></span>
</code></pre></div></div>
-<p>Another approach would be to use the idiom <code class="language-plaintext
highlighter-rouge">value="'ca'"</code>, but, in this case, using the expression
notation is recommended.</p>
+<p>To read a property, wrap it in the expression notation. The same goes for
<code class="language-plaintext highlighter-rouge">hidden</code> and the other
form tags.</p>
+
+<p>Two form tags are the exception: <code class="language-plaintext
highlighter-rouge">checkbox</code> evaluates <code class="language-plaintext
highlighter-rouge">value</code> as a Boolean and <code
class="language-plaintext highlighter-rouge">file</code> as an Object, so on
those it
+is always an expression (rule 2 below). The generic tags — <code
class="language-plaintext highlighter-rouge">property</code>, <code
class="language-plaintext highlighter-rouge">set</code>, <code
class="language-plaintext highlighter-rouge">if</code>, <code
class="language-plaintext highlighter-rouge">iterator</code> — take an
expression
+in <code class="language-plaintext highlighter-rouge">value</code> as well.</p>
<p>Boiled down, the tag attributes are evaluated using three rules.</p>
@@ -265,8 +264,6 @@ within quotes</p>
as redundant, and the content evaluated.</li>
</ol>
-<p>Please remember about <em>altSyntax</em> option that can change when value
is evaluated as an expression - <a href="alt-syntax">Alt Syntax</a></p>
-
<h2 id="expression-language-notations">Expression Language Notations</h2>
<ul>
