Vadim Gritsenko wrote:

Sylvain Wallez wrote:

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>


Still the same problem I desperatly pointing out again and again : how can the from-position="reader" use different generators (i.e. parsers) depending on the binary content ?

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>


This introduces sitemap snippets into a component manager configuration, wich is not good at all.

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>


Sounds better, but has the problem that it implies that every view should return xml content on "my.doc". Or to we introduce a "label" attribute on <map:read> to define on which particular view the xmlizer-uri should be triggered ?

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).


Sorry, I have no particular comment on the use of resources, as it's mainly a refactoring of the action/matcher proposals.

- 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.


Not exacly : you can currently match on the view name (provided that the environment actually does rely on the "cocoon-view" parameter), but you cannot match on the labels. And only labels are currently used in the <map:pipelines> section.

PS Keep sitemap syntax clean! Say "No!" to woodo!


Funny. That's often me that says "too much magic kills the confidence".

Let's stop this discussion for now. I have the feeling we won't reach consensus and will just come to some useless flame war.

Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com




Reply via email to