cziegeler 01/10/19 04:13:49
Modified: documentation/xdocs/userdocs/matchers Tag: cocoon_20_branch
matchers.xml
documentation/xdocs/userdocs/selectors Tag: cocoon_20_branch
selectors.xml
Log:
[patch/docs]Selector documentation
Submitted by: Gianugo Rabellino [[EMAIL PROTECTED]]
Revision Changes Path
No revision
No revision
1.1.2.3 +7 -7 xml-cocoon2/documentation/xdocs/userdocs/matchers/matchers.xml
Index: matchers.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/documentation/xdocs/userdocs/matchers/matchers.xml,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- matchers.xml 2001/10/18 13:24:39 1.1.2.2
+++ matchers.xml 2001/10/19 11:13:48 1.1.2.3
@@ -143,18 +143,18 @@
</s1>
<s1 title="The Matchers in @docname@">
<ul>
- <li><b>WildCard URI matcher </b>(The default
matcher): matches the URI against a wildcard pattern</li>
- <li><b>Regexp URI matcher:</b>
+ <li><strong>WildCard URI matcher</strong>(The default
matcher): matches the URI against a wildcard pattern</li>
+ <li><strong>Regexp URI matcher:</strong>
matches the URI against a fully blown regular expression</li>
- <li><b>Request parameter
- matcher:</b> matches a request parameters given as a pattern. If
+ <li><strong>Request parameter
+ matcher:</strong> matches a request parameters given as a pattern. If
the parameter exists, its value is available for later substitution
</li>
- <li><b>Wildcard request parameter matcher:</b>
matches a wildcard
- given as a pattern against the <b>value</b> of the configured
+ <li><strong>Wildcard request parameter
matcher:</strong> matches a wildcard
+ given as a pattern against the <strong>value</strong> of the configured
parameter
</li>
- <li><b>Wildcard session parameter matcher</b>: same
as the
+ <li><strong>Wildcard session parameter
matcher</strong>: same as the
request parameter, but it matches a session parameter</li>
</ul>
</s1>
No revision
No revision
1.1.2.2 +84 -9 xml-cocoon2/documentation/xdocs/userdocs/selectors/selectors.xml
Index: selectors.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/documentation/xdocs/userdocs/selectors/selectors.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- selectors.xml 2001/10/16 14:42:18 1.1.2.1
+++ selectors.xml 2001/10/19 11:13:48 1.1.2.2
@@ -9,25 +9,100 @@
<type>Technical document</type>
<authors>
<person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/>
+ <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/>
</authors>
<abstract>This document describes all available selectors of
@doctitle@.</abstract>
</header>
<body>
<s1 title="Goal">
- <p>This document lists all available selectors of @doctitle@
and
- describes their purpose.</p>
+ <p>
+ This document lists all available selectors of @doctitle@ and
+ describes their purpose.
+ </p>
</s1>
<s1 title="Overview">
- <p>Forthcoming...
- </p>
+ <p>
+ Selectors in @docname@ 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.
+ </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:
+ </p>
+<source>
+<![CDATA[
+<map:match pattern="docs/*.html">
+ <map:generate src="xdocs/{1}.xml"/>
+
+ <map:select type="browser">
+ <map:when test="netscape">
+ <map:transform src="stylesheets/netscape.xsl" />
+ </map:when>
+ <map:when test="explorer">
+ <map:transform src="stylesheets/ie.xsl" />
+ </map:when>
+ <map:when test="lynx">
+ <map:transform src="stylesheets/text-based.xsl" />
+ </map:when>
+ <map:otherwise>
+ <map:transform src="stylesheets/html.xsl" />
+ </map:otherwise>
+ </map:select>
+
+ <map:serialize/>
+</map:match>
+]]>
+</source>
+
</s1>
<s1 title="The Selectors in @doctitle@">
- <p>Forthcoming...
- </p>
-<!-- <ul>
- <li><link href="xslt-transformer.html">XSLT
Transformer</link> (The default transformer)</li>
+ <p>
+ These are the available Selectors in @doctitle@:
+ </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>CodeSelector</strong>: matches a snippet
of Java code
+ given as the "test" parameter against the environment;</li>
+
+ <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 @docname@ internal
+ (e.g. sitemap) parameter;</li>
+
+ <li><strong>HeaderSelector</strong>: same as the
Parameter selector,
+ but matches against the request headers;</li>
+
+ <li><strong>RequestSelector</strong>: again, same as
the Parameter selector,
+ but matches against the Request parameters;</li>
+
+ <li><strong>SessionSelector</strong>: finally, this
selector is used as
+ the Parameter selector to match against an arbitrary session
+ attribute;</li>
+
</ul>
--->
</s1>
</body>
</document>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
