document('cocoon:/myinternalpipeline');
SoC... Caching... Virtual URI space... Pipeline reuse...
All it would take is for Cocoon to keep an eye out for calls to the
SourceResolver, and perhaps for request parameters to be
passed smartly. Better yet, force all document('...') requests be
Cocoon internal protocol requests.
Counter points:
Source Pure XML -
You get one pure XML source indirectly
AND you get to use all the existing XML
application specific tools for your other source.
Aggregation -
Aggregation is not the force for SoC it is presented as.
It is good only for simple single level cases. As soon
as you aggregate aggregations, you've lost the case.
Speed -
In an attempt to speed up processing, I removed the
document function, and cincluded the data
into the source. It made no difference. (Solaris 8 -
there were other speed issues at the time).
DOM / SAX -
Aggregation pumps entire blocks of SAX events. This is
fine, XSLT may be worse. But XSLT (or STX) implementations
do have the freedom to optimize this stuff. The semantics of
aggregation do not allow this freedom.
Now if the developers of Cocoon think that using the document function is
not a good use of Cocoon, then so be it. I think that in conjunction with
the Cocoon protocol, it is a powerful feature that supports SoC.
When it comes down to it aggregation and the document function do fulfil
the same need. The only reason I would pick the XSLT document function
over aggregation, is... it just feels right.
After writing this all down, I think I've decided that both aggregation and
document() suck in Cocoon. There has got to be a better way.
Cocoon 3, perhaps.
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
