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