> From: Reinhard Poetz [mailto:[EMAIL PROTECTED] > > > 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
