vgritsenko 02/03/14 11:53:30
Modified: src/documentation/xdocs/userdocs/concepts
matchers_selectors.xml
Log:
quick and dirty fix: matcher factories are long gone
Revision Changes Path
1.3 +19 -81
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/matchers_selectors.xml
Index: matchers_selectors.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/matchers_selectors.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- matchers_selectors.xml 5 Feb 2002 01:46:44 -0000 1.2
+++ matchers_selectors.xml 14 Mar 2002 19:53:30 -0000 1.3
@@ -97,7 +97,7 @@
Actions should be used to <em>"do"</em> something, not to chose
between different sub pipelines. That should be done only, if an error
occurred and you cannot continue the regular pipeline. Of course this
-is a fuzzy criterion and using an action to chose between exactly two
+is a fuzzy criterion and using an action to choose between exactly two
sub pipelines is a very common task i.e. for authentication. Also,
often actions have no nested elements and the further processing is
not affected by the result of the action. </p>
@@ -115,10 +115,10 @@
<map:matchers default="wildcard">
<map:matcher name="wildcard"
- src="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
+ src="org.apache.cocoon.matching.WildcardURIMatcher"/>
...
<map:matcher name="next-page"
- src="org.apache.cocoon.matching.WildcardParameterValueMatcherFactory">
+ src="org.apache.cocoon.matching.WildcardRequestParameterMatcher">
<map:parameter name="parameter-name" value="next-state"/>
</map:matcher>
</map:matchers>
@@ -132,8 +132,8 @@
]]>
</source>
<p>Matchers are given a short name (e.g, "wildcard") and of course the
-name of the JAVA class that implements the matcher or a matcher
-factory. In addition, parameters can be defined as well.
+name of the JAVA class that implements the matcher. In addition,
+parameters can be defined as well.
</p>
<p>
One matcher may be defined as default matcher, so whenever a matcher
@@ -170,6 +170,7 @@
<map:match type="sessionstate" pattern="edit*">
<!-- here you could insert parameters for the above matcher -->
<map:parameter name="attribute-name" value="__sessionstate"/>
+
<map:match type="next-page" pattern="ok*">
<!-- do something here, eg. database updates -->
<map:call resource="simple-page1"/>
@@ -194,15 +195,13 @@
...
<map:selectors default="browser">
<map:selector name="browser"
- src="org.apache.cocoon.selection.BrowserSelectorFactory">
+ src="org.apache.cocoon.selection.BrowserSelector">
<browser name="explorer" useragent="MSIE"/>
<browser name="lynx" useragent="Lynx"/>
<browser name="netscape" useragent="Mozilla"/>
</map:selector>
- <map:selector name="coded"
- src="org.apache.cocoon.selection.CodedSelectorFactory"/>
<map:selector name="parameter"
- src="org.apache.cocoon.selection.ParameterSelectorFactory"/>
+ src="org.apache.cocoon.selection.ParameterSelector"/>
</map:selectors>
...
@@ -233,7 +232,8 @@
<map:transform src="stylesheets/w3c-2-msie.xsl"/>
</map:when>
<map:when test="lynx">
- <map:transform src="stylesheets/dynamic-page2html-text.xsl"/>
+ <map:transform
+ src="stylesheets/dynamic-page2html-text.xsl"/>
<map:serialize/>
</map:when>
<map:when test="netscape">
@@ -244,7 +244,8 @@
</map:otherwise>
</map:select>
- <map:transform src="stylesheets/dynamic-page2html.xsl"/>
+ <map:transform
+ src="stylesheets/dynamic-page2html.xsl"/>
<map:serialize/>
</map:match>
@@ -262,8 +263,8 @@
<s2 title="Matchers">
<p>
Since the basic structure and the assumptions are very similar, we
-look first at matchers and matcher factories and point out the
-differences to selectors at the end.
+look first at matchers and point out the differences to selectors
+at the end.
</p>
<p>
Matchers need to implement the org.apache.cocoon.matching.Matcher
@@ -276,66 +277,6 @@
<code>org.apache.avalon.framework.configuration.Configurable</code>
interface.
</p>
-<s3 title="MatcherFactories">
-<p>
-Matcher factories generate two distinct parts of source code: a
-processed pattern stored in a global variable in the sitemap and a
-method used to do the actual matching. Since the global variable can
-be of an arbitrary type and it is an argument for the matcher method,
-it is, too, configurable.
-</p>
-<p>
-For each uniquely named matcher the function
-<code>generateParameterSource</code> and
-<code>generateMethodSource</code> are called exactly once, while
-<code>generateClassSource</code> is called for every use of the
-generated matcher in sitemap pipelines.
-</p>
-<p>
-Note that you may use the same matcher factory (or the same matcher or
-whatever) and declare it with different names. Although they will be
-instances of the very same class they would be different instances and
-thus another matcher method would be generated, e.g. using different
-configuration parameters.
-</p>
-<p>
-The generated matcher method looks like
-</p>
-<source>
-<![CDATA[
-private Map wildcardMatch (int [] pattern, Map objectModel,
- Parameters parameters) {
-
- // this has been generated by generateMethodSource ->
- HashMap map = new HashMap();
- String uri = XSPRequestHelper.getSitemapURI(objectModel);
- if (uri.startsWith("/"))
- uri = uri.substring(1);
- if (org.apache.cocoon.matching.helpers.WildcardURIMatcher.match (
- map, uri, pattern)) {
- return map;
- } else {
- return null;
- }
- // <- this has been generated by generateMethodSource
-}
-]]>
-</source>
-<p>
-The method takes three arguments: the first is the aforementioned by
-<code>generateClassSource</code> processed pattern, the current environment
-(<code>objectModel</code>), and the parameters given for the corresponding match
-element. In the example above for nested matchers, this would be the
-<code><![CDATA[<map:parameter name="attribute-name"
value="__sessionstate"/>]]></code>. The
-<code>int []</code> part of the method signature was generated by
-<code>generateParameterSource</code>.
-</p>
-<p>
-To configure the generated matcher, global configuration parameters
-can be used to create different sources. To read global configuration
-parameters, dom2 is used, you cannot use the usual avalon classes for
-this.
-</p>
<p>
Local configuration parameters are avalon parameters and thus can be
easily read and used with the generated matcher method.
@@ -347,16 +288,13 @@
</p>
<p>
The easiest way to write your own matcher would be to base it upon
-org.apache.cocoon.matching.WildcardURIMatcherFactory and override the
-generateMethodSource method with your own.
-</p>
-<p>
-Personally, I like factories more because they are easily written and
-global configuration options can be incorporated in the generated
-source thus the generated source is less complex than a similar
-versatile matcher would be.
+org.apache.cocoon.matching.WildcardURIMatcher and override the
+getMatchString method with your own.
</p>
+<!-- FIXME: Put some meat inside
+<s3 title="Preparable Matchers">
</s3>
+-->
</s2>
<s2 title="Selectors">
<p>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
