Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
...
I still think it would be a good idea to
have postable sources and especially to make the block protocol postable.
Regarding the "API" side of the blocks protocol, it would be nice, to be
able to call it from the sitemap without much overhead. One idea would
be to extend the map:call to allow to specify a block as target, eg.
<map:call resource="layouting" block="super" /> to call the layouting
resource in the super block.
Something like that is the way to go. Now, the call resource
implementation is not so easy to extend to something that works between
blocks (or even from sub sitemaps). We developed and implemented
something called virtual sitemap components (VPC) some time ago that
works better than the resource mechanism, see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111316710610638&w=2.
A drawback with using the some extension of the VPCs for inter block
communication is that it ties the communications to the specific sitemap
component APIs, so they are not usable for communication with non
sitemap blocks.
What I would propose is to create some new pipeline components that
calls postable sources, and make the block protocol postable. Then we
have four cases for the different combinations of XML or non XML input
and output respectably:
non XML -> non XML
<map:read type="service" src="block:b:/foo1"/>
non XML -> XML
<map:generate type="service" src="input.txt">
<map:parameter name="service" value="block:b:/foo2"/>
</map:generate>
XML -> XML
<map:transform type="service" src="block:b:/foo3"/>
XML -> non XML
<map:serialize type="service" src="block:b:/foo4"/>
A tricky thing is of course to get rid of buffering and serializing
followed by parsing steps for calls to services that have XML input
and/or output. But I think that 1) the problem is solvable and 2) we
don't have to solve it in the first implementation.
So one could call matchers and resources of
another block, don't know if it is a good idea (and even technically
possible) to call continuations or flowscripts in the other block.
We had some long discussions about how to call flowscripts from other
blocks, you can find a summary and some links in,
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111316710610638&w=2.
But in the end I doubt that it is worth the effort. I think it is better
to use the block protocol for all inter block communication and focus on
making that as useful as possible. Both flowscript functions and
continuations are callable through urls to sitemap rules.
With
your proposed change to provide a modifiable BlockSource one is able to
stream stuff into it and get something out. This is true for calling
resources and matchers with request body (my form case). For the last
case it should be easily possible to pass the request parameters on to
the block call with a simple statement in the sitemap.
Yes, being able to send request params to a blocks is also important.
/Daniel
