cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Postable block protocol
Date Wed, 25 Oct 2006 18:47:49 GMT
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

Mime
View raw message