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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------