Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 91334 invoked from network); 10 Jan 2005 13:24:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Jan 2005 13:24:27 -0000 Received: (qmail 920 invoked by uid 500); 10 Jan 2005 13:24:24 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 842 invoked by uid 500); 10 Jan 2005 13:24:24 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 802 invoked by uid 99); 10 Jan 2005 13:24:23 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from viefep11-int.chello.at (HELO viefep11-int.chello.at) (213.46.255.27) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 10 Jan 2005 05:24:22 -0800 Received: from [192.168.1.31] (really [62.178.239.20]) by viefep11-int.chello.at (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050110132418.ZABB20013.viefep11-int.chello.at@[192.168.1.31]> for ; Mon, 10 Jan 2005 14:24:18 +0100 Message-ID: <41E281FE.1040706@apache.org> Date: Mon, 10 Jan 2005 14:24:14 +0100 From: Reinhard Poetz User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap] References:

<41E22BCB.9010502@apache.org> <41E24FCF.109@nada.kth.se> <942AA128-6307-11D9-A9E3-000393B3DE96@hard-bop.com> In-Reply-To: <942AA128-6307-11D9-A9E3-000393B3DE96@hard-bop.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Glen Ezkovich wrote: > > On Jan 10, 2005, at 3:50 AM, Daniel Fagerstrom wrote: > >> 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 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