You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by do...@cocoon.apache.org on 2004/07/10 04:11:41 UTC
[Cocoon Wiki] Updated: CleanerSiteMapsThroughResources
Date: 2004-07-09T19:11:41
Editor: JoergHeinicke <jo...@gmx.de>
Wiki: Cocoon Wiki
Page: CleanerSiteMapsThroughResources
URL: http://wiki.apache.org/cocoon/CleanerSiteMapsThroughResources
no comment
Change Log:
------------------------------------------------------------------------------
@@ -23,29 +23,29 @@
* Various input-sources that should run through similar pipeline snippets: live-scraping versus local-copy
The most naive attempt at attacking the problem would be to (match for and) define the various pipelines one by one:
-{{{
- <map:match pattern="data/live.txt">
- <map:read mime-type="text/plain" src="http://csv-server.domain/getData" />
- </map:match>
-
- <map:match pattern="data/live.xml">
- <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
- <map:serialize type="xml" />
- </map:match>
-
- <map:match pattern="data/live.svg">
- <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
- <map:transform src="xsl/datafilter.xsl" />
- <map:transform src="xsl/data2svg.xsl" />
- <map:serialize type="svgxml"/>
- </map:match>
-
- <map:match pattern="data/live.jpg">
- <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
- <map:transform src="xsl/datafilter.xsl" />
- <map:transform src="xsl/data2svg.xsl" />
- <map:serialize type="svg2jpeg"/>
- </map:match>
+{{{
+ <map:match pattern="data/live.txt">
+ <map:read mime-type="text/plain" src="http://csv-server.domain/getData" />
+ </map:match>
+
+ <map:match pattern="data/live.xml">
+ <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
+ <map:serialize type="xml" />
+ </map:match>
+
+ <map:match pattern="data/live.svg">
+ <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
+ <map:transform src="xsl/datafilter.xsl" />
+ <map:transform src="xsl/data2svg.xsl" />
+ <map:serialize type="svgxml"/>
+ </map:match>
+
+ <map:match pattern="data/live.jpg">
+ <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
+ <map:transform src="xsl/datafilter.xsl" />
+ <map:transform src="xsl/data2svg.xsl" />
+ <map:serialize type="svg2jpeg"/>
+ </map:match>
}}}
Mind:
@@ -60,25 +60,25 @@
The SVG and JPEG output pipelines only differ in the serializer, which means we could hope for one single component that wraps up the complete mutual start of the pipelines in question. Such component would be (Starting a pipeline?) taking up the role of a "generator" that looks like this:
-{{{
- <map:resource name="generate-data-svg" >
- <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
- <map:transform src="xsl/datafilter.xsl" />
- <map:transform src="xsl/data2svg.xsl" />
- </map:resource>
+{{{
+ <map:resource name="generate-data-svg" >
+ <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
+ <map:transform src="xsl/datafilter.xsl" />
+ <map:transform src="xsl/data2svg.xsl" />
+ </map:resource>
}}}
Resulting in modified pipelines that are as simple as:
-{{{
- <map:match pattern="data/live.svg">
- <map:call resource="generate-data-svg" />
- <map:serialize type="svgxml"/>
- </map:match>
-
- <map:match pattern="data/live.jpg">
- <map:call resource="generate-data-svg" />
- <map:serialize type="svg2jpeg"/>
- </map:match>
+{{{
+ <map:match pattern="data/live.svg">
+ <map:call resource="generate-data-svg" />
+ <map:serialize type="svgxml"/>
+ </map:match>
+
+ <map:match pattern="data/live.jpg">
+ <map:call resource="generate-data-svg" />
+ <map:serialize type="svg2jpeg"/>
+ </map:match>
}}}
=== Duplication 2 ===
@@ -86,34 +86,34 @@
Since the SVG and XML pipelines share the same specific generator there is a similar step more to take by letting both this new resource and the xml-pipe call upon a resource that hides away this generator (and it's hardcoded source.)
Now the combination of:
-{{{
- <map:resource name="generate-data-xml" >
- <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
- </map:resource>
-
- <map:resource name="generate-data-svg" >
- <map:call resource="generate-data-xml" />
- <map:transform src="xsl/datafilter.xsl" />
- <map:transform src="xsl/data2svg.xsl" />
- </map:resource>
+{{{
+ <map:resource name="generate-data-xml" >
+ <map:generate type="myCSVGenerator" src="http://csv-server.domain/getData" />
+ </map:resource>
+
+ <map:resource name="generate-data-svg" >
+ <map:call resource="generate-data-xml" />
+ <map:transform src="xsl/datafilter.xsl" />
+ <map:transform src="xsl/data2svg.xsl" />
+ </map:resource>
}}}
Allows for even more similarity in the pipelines:
-{{{
- <map:match pattern="data/live.xml">
- <map:call resource="generate-data-xml" />
- <map:serialize type="xml"/>
- </map:match>
-
- <map:match pattern="data/live.svg">
- <map:call resource="generate-data-svg" />
- <map:serialize type="svgxml"/>
- </map:match>
-
- <map:match pattern="data/live.jpg">
- <map:call resource="generate-data-svg" />
- <map:serialize type="svg2jpeg"/>
- </map:match>
+{{{
+ <map:match pattern="data/live.xml">
+ <map:call resource="generate-data-xml" />
+ <map:serialize type="xml"/>
+ </map:match>
+
+ <map:match pattern="data/live.svg">
+ <map:call resource="generate-data-svg" />
+ <map:serialize type="svgxml"/>
+ </map:match>
+
+ <map:match pattern="data/live.jpg">
+ <map:call resource="generate-data-svg" />
+ <map:serialize type="svg2jpeg"/>
+ </map:match>
}}}
While this does not offer us that much gained economics in the typing effort, it does limit once more the occurance of the part that is the most probable to change (since it is out of our control: the URI-location (server and path) of the CSV file).
@@ -124,44 +124,44 @@
The question to ask is which 'role' should be taken up by the resource that could fit into both pipelines that still require this field. Given the end-to-end coverage of the single {<map:read>} component in the txt pipeline there is however no smaller granularity then the full pipe to consider. This in turn forces us to reconsider all pipelines to be redefined as resources with end-to-end responsibility. The source to start from, now becomes a parameter {{{input-src}}} to these Resources:
-{{{
- <!--
- | resources that behave as full-blown end-to-end pipes
- -->
- <map:resource name="pipe-data-txt">
- <map:read mime-type="text/plain" src="{input-src}" />
- </map:resource>
-
- <map:resource name="pipe-data-xml">
- <map:call resource="generate-data-xml" >
- <map:parameter name="input-src" value="{input-src}" />
- </map:call>
- <map:serialize type="xml" />
- </map:resource>
-
- <map:resource name="pipe-data-svg">
- <map:call resource="generate-data-svg" >
- <map:parameter name="input-src" value="{input-src}" />
- </map:call>
- <map:serialize type="svgxml"/>
- </map:resource>
-
- <map:resource name="pipe-data-jpeg">
- <map:call resource="generate-data-svg" >
- <map:parameter name="input-src" value="{input-src}" />
- </map:call>
- <map:serialize type="svg2jpeg"/>
- </map:resource>
+{{{
+ <!--
+ | resources that behave as full-blown end-to-end pipes
+ -->
+ <map:resource name="pipe-data-txt">
+ <map:read mime-type="text/plain" src="{input-src}" />
+ </map:resource>
+
+ <map:resource name="pipe-data-xml">
+ <map:call resource="generate-data-xml" >
+ <map:parameter name="input-src" value="{input-src}" />
+ </map:call>
+ <map:serialize type="xml" />
+ </map:resource>
+
+ <map:resource name="pipe-data-svg">
+ <map:call resource="generate-data-svg" >
+ <map:parameter name="input-src" value="{input-src}" />
+ </map:call>
+ <map:serialize type="svgxml"/>
+ </map:resource>
+
+ <map:resource name="pipe-data-jpeg">
+ <map:call resource="generate-data-svg" >
+ <map:parameter name="input-src" value="{input-src}" />
+ </map:call>
+ <map:serialize type="svg2jpeg"/>
+ </map:resource>
}}}
Not precisely a small amount of typing, but in return it cleans up the pipelines to a mere:
-{{{
- <map:match pattern="data/live.*">
- <map:call resource="pipe-data-{1}">
- <map:parameter name="input-src"
- value="http://csv-server.domain/getData" />
- </map:call>
- </map:match>
+{{{
+ <map:match pattern="data/live.*">
+ <map:call resource="pipe-data-{1}">
+ <map:parameter name="input-src"
+ value="http://csv-server.domain/getData" />
+ </map:call>
+ </map:match>
}}}
And the real gain is yet to come.
@@ -171,18 +171,18 @@
Although we started the other way around, we finally come down to the most obvious duplication in the original setup. i.e. The fact that the local copy (2nd dimension) needed to go through the complete same set of considerations. The only variable in the two cases is the source to start from.
Since we factored that one out to become a simple parameter, the complete 'local' case is dealth with by reusing the resources we already have:
-{{{
- <map:match pattern="data/local.*">
- <map:call resource="pipe-data-{1}">
- <map:parameter name="input-src"
- value="local/sample.txt" />
- </map:call>
- </map:match>
+{{{
+ <map:match pattern="data/local.*">
+ <map:call resource="pipe-data-{1}">
+ <map:parameter name="input-src"
+ value="local/sample.txt" />
+ </map:call>
+ </map:match>
}}}
=== Aditional notes: ===
* When diving into adventures like these, you might want to consider careful attention in ResourceNaming
- * Attacking the issue through NestedMatchers is a valid option. However, things might not immidiately become more readable.
+ * Attacking the issue through nested [:Matcher]s is a valid option. However, things might not immediately become more readable.
* The followed 'one step at a time'-procedure is also advocated on SurvivalTips (Look for Proceed in "baby steps")
* The test/examples on this page were done with Cocoon 2.0.4 using the !TreeProcessor.