Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
<snip/>
Here is another wild (or not?) thought.
All this discussion comes down to the requirement of generating some XML out of the content usually served by the reader, if that's possible (and it is possible for some of the types of the content), in order to feed this XMLized content into the view. This generated XML is somewhat "equivalent" to the binary represenation for the purpose of view building. So, I'm going to the conclusion that some types of readers can be paired with the generator producing "equivalent", but XMLized, content. The best place to indicate such pairing is the time when you declare a reader:
<map:readers default="resource">
<map:reader name="resource" src="org.apache.cocoon.reading.ResourceReader"/>
<map:reader name="html" src="org.apache.cocoon.reading.ResourceReader">
<generator-paired-to-this-reader>html</generator-paired-to-this-reader>
</map:reader>
<map:reader name="msexcel" src="org.apache.cocoon.reading.ResourceReader">
<generator-paired-to-this-reader>poi-excel-generator</generator-paired-to-this-reader>
</map:reader>
<map:reader name="pdf" src="org.apache.cocoon.reading.ResourceReader">
<generator-paired-to-this-reader>pdf-text-extractor-generator</generator-paired-to-this-reader>
</map:reader>
</map:readers>
I'm afraid this won't work :
Can you suggest some improvements so it does work? My goal is to have as little impact on sitemap syntax as possible.
- a generator specific to a given content-type is very unlikely to produce the document type expected by the view. We will most often need an additional transformation (e.g. the "xword2xdoc.xsl" that was in my example)
More wild suggestions.
1/ Do something with the views. Say, allow duplicate view names and make them work as selector:
<map:views>
<!-- works if ("when") reader -->
<map:view from-position="reader" name="content">
<map:transform src="wordml2content.xsl" label="content"/>
<map:serialize type="xml"/>
</map:view>
<!-- works if ("when") label -->
<map:view from-label="content" name="content">
<map:serialize type="xml"/>
</map:view>
<!-- works if no label ("otherwise") -->
<map:view from-position="first" name="content">
<map:serialize type="xml"/>
</map:view>
</map:views>2/ Do something with the readers.
<map:readers default="resource">
<map:reader name="msword" src="org.apache.cocoon.reading.ResourceReader">
<map:generate type="msword"/>
<map:transform src="wordml2content.xsl"/>
</map:reader>
</map:readers>
3/ Alternative to 2:
<map:readers default="resource">
<map:reader name="msword" src="org.apache.cocoon.reading.ResourceReader">
<xmlizer-uri>cocoon://word-2-content/</xmlizer-uri>
</map:reader>
</map:readers>
<map:views>
<map:view from-label="content" name="content">
<map:serialize type="xml"/>
</map:view>
</map:views> <map:pipelines>
...
<map:read src="my.doc"/>
...
<map:match pattern="word-2-content/*">
<map:generate type="msword" src="{1}/>
<map:transform src="wordml2content.xsl" label="content"/>
<map:serialize type="xml"/>
</map:match>
</map:pipelines>I would not say that I like any of the suggestions above. The cleanest way ATM is the usage of map:resource I suggested in other email (I yet to see your comment on it).
- views, through their associated labels, can be plugged at any point of the pipelines. Defining pair generators restricts views to be only from-label="start".
PS: Modifying sitemap syntax to allow reader/generator pairs with some "unless" attrbiutes looks awful to me.
Doesn't seem so awful to me, since the reader should be executed "unless" certain conditions are met, which are that the specified label(s) correspond to the one at which the requested view should start.
This "unless" attribute is nothing else than shortcut for <map:match>. Given point on verbosity and given the obfuscated result, I'm for verbosity.
PS Keep sitemap syntax clean! Say "No!" to woodo!
Vadim
