cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: [RT] Views for readers
Date Thu, 14 Aug 2003 23:31:13 GMT
Sylvain Wallez wrote:

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


I did not copy reader-to-generator association 
(<generator-paired-to-this-reader/>) declared on top. Get the generator 
from there.


>> 2/ Do something with the readers.
>
...

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


Yep. Not good.


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


Yep. Unless you define one xmlizer URI per view... Awful!


> Or to we introduce a "label" attribute on <map:read> to define on 
> which particular view the xmlizer-uri should be triggered ?


Possible.


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


But it solves the problem! And the cleanest solution (with minimal 
impact) among all discussed here.


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


(Special "view" matcher is still possible)


> but you cannot match on the labels. And only labels are currently used 
> in the <map:pipelines> section.


I don't understand this. What is "match on the labels" in this context?


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

Should be "voodoo" above


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


Now it's my turn :)


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


I don't see an elegant solution to the reader/view problem right now. 
And we always can make another flamefest later (are you planning a visit 
to US? :)

Vadim



Mime
View raw message