cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 07:16:27 GMT
Glen Ezkovich wrote:
> On Jan 9, 2005, at 7:33 PM, Mark Lundquist wrote:
>>> From: Glen Ezkovich []
>>> On Jan 9, 2005, at 4:17 PM, Mark Lundquist wrote:
>>>> Do we really want inter-block flowscript function calls?
>> Actually, I guess we do... there are some blocks that are meant to be 
>> used
>> from flow, for which passing requests and SAX streams isn't the best 
>> model.
>> Think of an authentication module, for instance.  Or, to use your 
>> example,
>> Forms!

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") {
    else {

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

If I'm right that we can't find a way to make this "isolated flowscript call"
work, we can still think of including other blocks flowscripts the usual way in
the <map:flow>-sections. But it looks more like a hack.

> Of course. But you want to use a service not invoke a javascript 
> function. What you would want is to get the service, make a request and 
> get the result. Not knowing what the intricacies of the block system 
> will be, I would imagine something along the lines of
>     var authService = 
> cocoon.get("block://authentication/authenticationService");
>     var isAuthorized = authService.authorize(user, pwd);
> would make more sense. Or more likely this still might be done by the 
> current service lookup methods but the service will be provided by the 
> authentication block. (Though I do like the simplicity of the above.) If 
> you implemented you app's authentication in javascript and deployed it 
> as a block you could just use it from flow like
>     cocoon.sendPageAndWait("block://authentication/authenticate", 
> "block://currentBlock/loginPage");
> Where all you are essentially doing is redirecting to the authentication 
> blocks sitemap. It really just depends on what exactly it is you want 
> the block to do.
> The way I understand it, one of the main points of blocks is to make it 
> easier to configure Cocoon with just the components you need for your 
> application. Once the various components are wired together we shouldn't 
> really need to do anything differently. If a block has a dependency on 
> another block it should be able to use the existing methods to realize 
> that dependency. All of the magic should be done by Cocoon and the Block 
> Manager.
>> So, I withdraw my question... but I guess I would like to see what block
>> contracts would look like at the flow level!
> Can you explain what a contract between blocks is? I'm lost here. I 
> thought a contract was between the client and the 
> method/function/pipeline it invokes. The client agrees to meet certain 
> requirements of the method/function/pipeline before invoking it and the 
> method/function/pipeline then agrees to perform certain tasks and/or 
> return correct and valid results.
>> Perhaps a flowscript object
>> that encapsulates the flowscript API for the block?
>> Actually, a Java interface could express that...
> Seems like overkill.

see above


View raw message