cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Views for readers
Date Thu, 14 Aug 2003 19:30:35 GMT

Sylvain Wallez wrote, On 14/08/2003 14.30:
> Nicola Ken Barozzi wrote:
> 
>>
>> Jeff Turner wrote, On 14/08/2003 14.17:
>>
>> ...
>>
>>> Isn't the problem there that a <map:read> is a whole little pipeline 
>>> unto
>>> itself?  If it were broken into two atomic operations:
>>>
>>> <map:generate type="binary" src="foo.doc"/>
>>> <map:serialize type="binary"/>
>>>
>>> then we could have a <map:view from-position="first"/> using a
>>> content-aware pipeline, and everything would work.
>>
>> Well, why can't the view simply start from a reader?
>>
>>  <map:read src="foo.doc"/> 
> 
> Because a view finishes a partial XML pipeline, meaning it requires a 
> generator to be already present...

That's because of how we define a view now ;-)
If we had just pipelines that handle both binary and xml data, the viw 
would finish a partial pipeline, in this case starting from binary.

>>> I have the feeling that handling non-XML content in Cocoon is Just 
>>> Wrong,
>>> and that <map:read> is just a hack.  The fact that it doesn't integrate
>>> with Views is a symptom of this.  In a theoretically pure world, we'd
>>> either make Cocoon an XML-only framework and kill <map:read>, or make
>>> Cocoon a generic data pipelining framework capable of handling and
>>> transforming binary content.
>>
>> Well, it can be done easily by allowing more than one reader and by 
>> allowing readers in the xml pipeline.
>>
>> Some time back I had proposed the following to be possible (and got 
>> touted as the usual FS man)
>>
>>  <map:read src="foo1.doc"/>
>>  <map:read type="stripstuff"/>
>>  <map:read type="otherfilter"/> 
> 
> Mhhh... I guess "stripstuff" and "otherfilter" are actually 
> <map:transform-binary> and not <map:read> as they do have an input. Now 
> how do we "close" the pipeline ? Is there a <map:serialize-binary> ?

Since streams are just streams, they don't need to be adapted like XML, 
so there is no notion of Generator or Serializer really, but only 
filter. So the reader is just a filter, and if in the middle it's just 
given a stream and has to output to a stream. So there is no need to 
open, and no need to close.

>> And also:
>>
>>  <map:read src="foo1.doc"/>
>>  <map:generate src="foo1.doc"/>
>>  <map:serialize src="foo1.doc"/>
>>  <map:read type="zip"/> 
> 
> 
> Wow! What's the result of this ??

Oops, a bit too quick.

<!-- remove encription or do other stream preprocessing -->
   <map:read type="decrypt" src="foo1.doc"/>
<!-- normal generation but from the previous reader output -->
   <map:generate type="doc2xml"/>
<!-- eventual transforms-->
<!-- give back html -->
   <map:serialize type="html"/>
<!-- zip that result so that it takes less bandwidth -->
   <map:read type="zip"/>

>> We can already do this BTW by using the Cocooon protocol, but it's 
>> such a hack! 
> 
> Sounds interesting. Can you elaborate on the hack ?

<map:match pattern="mypage.html">
   <map:read src="internal/mypage.html" type="zip"/>
</map:match>

<map:match pattern="internal/mypage.html">
   <!-- generate, transform, serialize... -->
</map:match>

BTW, maybe you may be interested in my RT about aspected pipeline 
snippets, it could be interesting. Basically it would make it possible 
to insert pipeline components inside all pipelines using certain rules.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



Mime
View raw message