cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 09:50:07 GMT
Reinhard Poetz wrote:

> 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:


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.



View raw message