Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
<snip/>
I would assume that a (virtual) flowscript call should be very
similar to a parametrized virtual pipeline (or maybe will they still
be called resources?). The problem is the continuation handler. I
would propose that the virtual flowscript definition must contain its
continuation handler as well, otherwise the user of the flowscript
must know block internal details about the continuation URL usage.
Are there further problems?
sorry, I haven't understood what parametrized virtual pipelines are,
but I try to give you an example on what I mean:
I meant the block version of an ordinary map:resource, (i.e. a complete
pipeline all the way from generator to serializer or a reader) and
wanted to emphasize the fact that it takes parameters. I also wondered
if we have decided to call it pipeline instead of resource when we
implement VPCs, I would prefer that at least.
Now a virtual pipeline has AFAIKS very similar semantics as a
flowscripts from the caller POV. Booth takes the Cocoon object model and
parameters as input and returns a response object and resolves resources
relative to their block. The main difference is that the flowscript
creates webcontinuations that the repsonse can contain links to.
BLOCK A
-------
- has a flowscript blockA-flow.js
- has an internal pipeline that makes block-flow.js accessible from
other blocks
- flowscript (blockA-flow.js):
function abc() {
cocoon.sendPageAndWait("page1");
cocoon.sendPageAndWait("page2");
return new Customer();
}
- sitemap:
<map:flow>
<map:script src="blockA-flow.js"/>
</map:flow>
<map:match pattern="page*">
...
</map:match>
<map:match pattern="flow.js">
<map:read src="blockA-flow.js"/>
</map:match>
BLOCK B
-------
- has a flowscript blockB-flow.js
- blockB-flow.js wants to use xyz of blockA
- flowscript (blockB-flow.js):
function xyz() {
var cust = abc();
cocoon.sendPageAndWait("anotherpage", {customer:cust});
}
- sitemap:
<map:flow>
<map:script src="block:/blockA/flow.js">
<map:script src="blockB-flow.js"/>
</map:flow>
<map:match pattern="anotherpage*">
...
</map:match>
The problem ist, that this example wont work because when function abc
sends the pipeline page1 it is resolved relative to the sitemap of
blockB.
Thats also the behaviour that I would expect as a user as you imports a
text representation of the flowscript rather than the functions it
contains.
Here we need a solution ...
I would solve this in two steps: First we need a way to use a (virtual)
flowscript function from a map:call. Here we can consider it as a
virtual pipeline as I indicated above. Given that it has been defined as
a VPC, it called like
<map:call function="block:blockA:abc"/>
or whatever syntax we have decided.
Next question is how we use the VPC function from a flowscript in the
block B. Here we must understand that the virtual flowscript function is
a VPC, i.e. a Java object rather than an ordinary flowscript function.
So in some way it must be imported (and adapted to JS function) in
blockB-flow.js to be used. It could either be done in some kind of
import statement in the script or in a special attribute in
map:flow/map:script.
WDYT?
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?
--
Reinhard
