Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <41E24FCF.109@nada.kth.se>
References: <BBEMLIFHEHIAOJDHONPDEEADCBAA.ml@wrinkledog.com>
 <C771A8C6-62C5-11D9-A9E3-000393B3DE96@hard-bop.com>
 <41E22BCB.9010502@apache.org> <41E24FCF.109@nada.kth.se>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <942AA128-6307-11D9-A9E3-000393B3DE96@hard-bop.com>
Content-Transfer-Encoding: 7bit
From: Glen Ezkovich <glen@hard-bop.com>
Subject: Re: Blocks,
 Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date: Mon, 10 Jan 2005 07:00:18 -0600
To: dev@cocoon.apache.org


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?

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

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

Precisely. Flowscripts are not components. Neither are a collection of 
flow functions. If you want to make them so then provide a component as 
a wrapper. look it up as usual and then invoke its methods all from 
within a single flowscript function.

I'm sure if someone implemented things as you both describe I would 
take advantage of it. But I really think you could achieve the same 
results in a simpler way.


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com


A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow