On Jan 9, 2005, at 4:17 PM, Mark Lundquist wrote:
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 was wondering about this as well. Is it even necessary in order to use the functions in the first place? If one has a dependency on another blocks flowscript function couldn't one just load the file and use the function as in cocoon.load("resource://org/apache/cocoon/forms/flow/javascript/ Form.js"); ? Is there something special about blocks that would prevent the current cocoon methods of accessing resources from working? If you are passing local URLs to a foreign block I would assume you would use the cocoon pseudo protocol or an absolute path. If the URL is defined inside the foreign function the typical rules should apply. This seems to be adding unnecessary complexity.
Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
