Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 70698 invoked from network); 12 Nov 2003 23:19:44 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 12 Nov 2003 23:19:44 -0000 Received: (qmail 23792 invoked by uid 500); 12 Nov 2003 23:19:25 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 23706 invoked by uid 500); 12 Nov 2003 23:19: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 23655 invoked from network); 12 Nov 2003 23:19:24 -0000 Received: from unknown (HELO gull.mail.pas.earthlink.net) (207.217.120.84) by daedalus.apache.org with SMTP; 12 Nov 2003 23:19:24 -0000 Received: from 1cust118.tnt3.barrie.on.da.uu.net ([66.48.153.118] helo=andrzej) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AK4Go-0000Fk-00 for dev@cocoon.apache.org; Wed, 12 Nov 2003 15:19:30 -0800 From: "Andrzej Jan Taramina" Organization: Chaeron Corporation To: dev@cocoon.apache.org Date: Wed, 12 Nov 2003 18:20:34 -0500 MIME-Version: 1.0 Subject: Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...) Reply-to: andrzej@chaeron.com Message-ID: <3FB279F2.18467.1886D8C@localhost> Priority: normal In-reply-to: <3FB2A54B.2050506@cbim.it> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Ugo suggested: > > > > > > > > > > > function dumpData() { > dumpUserData(); > dumpOrderData(); > dumpNewsItems(); > cocoon.sendPage("view"); > } > The main problem I have with this approach is that without looking at the script code, there is no easy way of telling that the first match will end up calling the second one and so the flow of the application becomes more opaque...and thus harder to understand and maintain. I like Tim's approach much better....where everything is in one place and the high level flow of control is quite clear and transparent. also glad to see that I am not the only one that has used this paradigm. An action that will call a flowscript for you without the sendPage restriction would seem to be a reasonable alternative, in which case Tony's code then looks like: ... error stuff can go here... Which I like even better...since you have the ability to branch the flow based on success/failure of the action. You could also allow parameters as input to the function by doing something like: .... as before where the method signature of dumpUserData would look like function dumpUserData( xValue, yValue ) {....} Clean...crisp...understandable...functional....and doesn't clutter the architecture. +1 from me for the FlowscriptAction approach and soon too! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com