cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@cocoon.apache.org
Subject [Cocoon Wiki] Updated: CleanerSiteMapsThroughResources
Date Sat, 10 Jul 2004 02:11:41 GMT
   Date: 2004-07-09T19:11:41
   Editor: JoergHeinicke <joerg.heinicke@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.

Mime
View raw message