cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Lundquist" ...@wrinkledog.com>
Subject RE: Splitting xconf files step 2: the sitemap
Date Sun, 09 Jan 2005 22:17:06 GMT

> From: Reinhard Poetz [mailto:reinhard_poetz@yahoo.de]
>
>
> Let's talk again about our needs. What I've understood so far, we want to:
>
>   * call a flowscript function of another block *within* flowscript
>   * use the return object returned by the *other* block
>   * the function of the *other* block can send responses to the client
>     with correctly resolved links and can create continuations
>
> The question is, which contract we want to establish between
> caller and callee.
>
> Maybe somethink like
>
> function f_of_blockB() {
>     var x = cocoon.callBlock("blockA:f_of_blockA", {a, b, c});
>
>     // here calling a function of a sub sitemap of blockA
>     var y = cocoon.callBlock("blockA:subSitemap1:f_of_blockA_subSitemap",
>               {d, e});
> }
>
> can do the job ...
>
> WDYT?

I'm a way late-comer to both the "real blocks" and VPC discussions, and
really still just in the learning curve of trying to get caught up w/ the
thinking, so I apologize in advance for any cluelessness, but...

Do we really want inter-block flowscript function calls?

I had always assumed that the block contracts would be at the sitemap level,
I suppose in terms of VPCs exported by blocks (and maybe imported from the
mounting context?).  Since VPCs take parameters (right? :-), what value do
we add by allowing blocks to invoke each other at the flow level?

I would rather see a sitemap-level contract, because of (a) parsimony, and
(b) clarity (the block dependencies/coupling are manifest in the sitemap,
not buried in flowscripts).

Am I totally off-base here?

Cheers,
Mark


Mime
View raw message