You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by sh...@apache.org on 2002/06/07 22:00:57 UTC
cvs commit: xml-cocoon2/src/documentation/xdocs/userdocs/selectors selectors.xml
shannon 2002/06/07 13:00:57
Modified: src/documentation/xdocs/userdocs/selectors Tag:
cocoon_2_0_3_branch selectors.xml
Log:
sync with head
Revision Changes Path
No revision
No revision
1.1.2.1 +35 -31 xml-cocoon2/src/documentation/xdocs/userdocs/selectors/selectors.xml
Index: selectors.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/selectors/selectors.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- selectors.xml 3 Jan 2002 12:31:05 -0000 1.1
+++ selectors.xml 7 Jun 2002 20:00:57 -0000 1.1.2.1
@@ -9,15 +9,16 @@
<authors>
<person name="Carsten Ziegeler" email="cziegeler@apache.org"/>
<person name="Gianugo Rabellino" email="gianugo@rabellino.it"/>
+ <person name="Diana Shannon, ed." email="shannon@apache.org"/>
</authors>
- <abstract>This document describes all available selectors of Cocoon.</abstract>
+ <abstract>This document describes all of the available selectors of Cocoon.</abstract>
</header>
<body>
<s1 title="Goal">
<p>
- This document lists all available selectors of Apache Cocoon and
+ This document lists all of the available selectors of Apache Cocoon and
describes their purpose.
- See also the concepts document
+ You may also wish to read
<link href="../concepts/matchers_selectors.html">Using and Implementing
Matchers and Selectors</link>.
</p>
@@ -25,29 +26,32 @@
<s1 title="Overview">
<p>
Selectors in Apache Cocoon have a role similar to matchers
- while being more flexible. Like matchers they are designed
- to test something against a part of the environment (the
- request URI, headers, cookies and so on), but unlike matchers
- they can be active decision driving components.
- A matcher allows only for simple
- "yes/no" decisions: the match can be succesful or not, if it
- is the pipeline is executed, if not it's simply ignored.
- Selectors go a step further allowing for more complex
- use cases, where there is need for a decision to be
- made according to a multiple chance scenario. In short you can
- think of matchers as an "if" statement, while selectors have all
- the power of an "if-else if-else" or "switch-case" construct.
- The selector syntax is similar will be familiar to people
- using the XSLT <code><xsl:test></code> statement.
+ with additional flexibility. If you haven't learned about
+ matchers yet, read about them <link href="../matchers/matchers.html">here</link>
+ before continuing. Selectors are designed to evaluate a
+ generally simple boolean expression regarding some
+ part of the environment (request URI, headers, or cookies, for example).
+ The result of this evaluation determines which pipeline fragments
+ should be combined within a given pipeline. Unlike matchers,
+ selectors can be active decision-driving components.
+ For example, a matcher makes only simple
+ "yes/no" decisions. If a match is successful, a
+ pipeline is executed. If not, it is ignored.
+ Selectors go further by allowing more complex, multiple-choice
+ use cases. In short, consider matchers to be simple "if"
+ statements. By extension, consider selectors to have all
+ the power of an "if-else if-else" or "switch-case" constructs.
+ The selector syntax should be familiar to anyone who
+ uses XSLT's <code><xsl:test></code> statement.
</p>
<p>
- As an example consider the typical scenario where a page has to
- be rendered in different way according to the browser being
- used. There are plenty of browsers out there so expressing this
- need as a set of matchers might become ankward and counterintuitive.
- Using the BrowserSelector, which checks a given pattern
- against the user-agent header, it's easy to deploy a consistent
- and readable setup:
+ As an example, consider the typical scenario in which a page should
+ be rendered differently based on the client browser.
+ Given the large number and diversity of available browsers,
+ it would be awkward and counterintuitive to address this need
+ with a set of matchers. The BrowserSelector tests a given parameter
+ against the user-agent request header. Using this single selector,
+ we can deploy a consistent and readable setup.
</p>
<source>
<![CDATA[
@@ -77,21 +81,21 @@
</s1>
<s1 title="The Selectors in Cocoon">
<p>
- These are the available Selectors in Cocoon:
+ Available Selectors in Cocoon include the following:
</p>
<ul>
- <li><strong>BrowserSelector</strong>: matches the value of the "test"
- parameter against the HTTP User-Agent header, allowing to
- recognize the browser being used;</li>
+ <li><strong>BrowserSelector</strong>: matches the value of the "test"
+ parameter against the HTTP User-Agent header, allowing it to
+ recognize the browser issuing the request;</li>
<li><strong>CodeSelector</strong>: matches a snippet of Java code
- given as the "test" parameter against the environment;</li>
+ given as the "test" parameter against the environment;</li>
- <li><strong>HostSelector</strong>: matches the "test" parameter value
+ <li><strong>HostSelector</strong>: matches the "test" parameter value
against the Host request header</li>
<li><strong>ParameterSelector</strong>: matches the string specified
- in the "test" parameter against a specified Cocoon internal
+ in the "test" parameter against a specified Cocoon internal
(e.g. sitemap) parameter;</li>
<li><strong>HeaderSelector</strong>: same as the Parameter selector,
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org