cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Mon, 10 Jan 2005 13:24:14 GMT
Glen Ezkovich wrote:
> 
> On Jan 10, 2005, at 3:50 AM, Daniel Fagerstrom wrote:
> 
>> 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 it seems, flow replaces components? If createNewAccount() gathers 
> sends pages, collects information, creates an Account, etc. then why not 
> just use cocoon.sendPageAndWait?

because this is done in the called block, not by the callee.


>>> So calling another block has to return a Java(script) object (a 
>>> stream of SAX
>>> events doesn't help here!)
> 
> 
> Of course. Thats why you should be using be invoking a method on a Java 
> object. If you do not know how to use a Java object from flow you 
> shouldn't be writing flowscripts. Once you have written a flowscript in 
> your Account block you should be able to use that flow script from any 
> block directly. Its  just a script.
> 
>>> and I don't want to care which flowscript files have
>>> to be loaded to make my call work.
> 
> 
> Then load(block://account/flowscript.js);  or something similar.
> 
>>>
>>> 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.
> 
> 
> hmm...
> 
>> 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.
> 
> 
> Thats why a block manager is needed, not individual local cocoon objects.
> 
>>
>> 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:
> 
> 
> I still don't see this. Then you should be creating objects and invoking 
> methods on them.
> 
>>
>>  cocoon.blocks.blockB.createNewAccount();
>>
>> illustrates that interpretation in a nice way.
> 
> 
> This just seems like a very complex way to implement the invocation of a 
> function in flow.
> 
>>
>> 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.
> 
> 
> I guess this makes sense but if you use java flow you have method access 
> modifiers to handle this.
> 
>>
>>> 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.
> 
> 
> Seems like you want a round peg in a square hole. Just invoke the 
> function by loading its file and this problem goes away.


If Javascript supported namespaces, I would agree with you.


-- 
Reinhard

Mime
View raw message