Reinhard Poetz wrote: <snip/>
I think of composing an application out of flow calls:
function myF() {
var newAccount = [here call a flow function of another block] e.g. cocoon.blocks.blockB.createNewAccount(); if(newAccount.type == "xyz") { cocoon.sendPage("xyz"); } else { cocoon.sendPage("abc"); } }
So calling another block has to return a Java(script) object (a stream of SAX
events doesn't help here!) and I don't want to care which flowscript files have
to be loaded to make my call work.
If we go this way we have to solve the problem that the flowscript of the other
block runs completly isoluated from the calling the block.
I think that is the way to go.
The important thing IMO is that when we use a flowscript today, it has access to a global context in terms of the cocoon object. When we introduce blocks each block must have a own cocoon object. This block local cocoon object has access to global stuff as before but also to such things that are internal to the block. Also all relative URIs must be resolved by relative the block rather than relative the user. There might be internal pipelines that the block resolver has access to but that not are exported.
This means that we cannot consider the exported flow calls as normal java script functions anymore, they are more like methods that are invoked at a certain object. And the syntax:
cocoon.blocks.blockB.createNewAccount();
illustrates that interpretation in a nice way.
A question here is what flowscript functions that should be exported from a block. I would prefer to explictly enumerate the functions and possibly whole scripts that are exported rather than exporting everything in the map:flow sections.
This has the
advantage that we don't have to work around the missing namespace concept of
Javascript but has the disadvantage that we have to find a way that in the other
block (runs isolated from the first block) continuations are created and that we
have to return the result of this function to the calling block.
I fear that this isn't possible ...
Can you expand on why you fear that it is impossible. Concerning web continuations I would assume that the normal case is that they are local to the block that creates them and handled by rules in the blocks sitemap, and that links are handled with the block link rewriting mechanism. Then it is the block writers choice to put the continuation handling sitemap rule in the external or the internal pipeline.
Concering objects that are returned from a block flowscript function I wouldn't don't see any problem (yet ;) ) it is an ordinary Java class, possibly from some Rhino name space.
<snip/>
/Daniel
