Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 75326 invoked by uid 500); 24 Nov 2002 04:31:01 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 75214 invoked from network); 24 Nov 2002 04:31:00 -0000 Message-ID: <3DDFE9DE.7060807@apache.org> Date: Sat, 23 Nov 2002 12:49:34 -0800 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Flow wishlist :) References: <3DDE72BA.80607@apache.org> <1038060690.1071.47.camel@defiant.dff.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Torsten Curdt wrote: > > >>We must do *everything* possible to prevent abuse of the flowscript >>layer. In fact, at the Cocoon BOF, several people expressed this concern >>of seeing script kiddies coming from the flash world abusing the >>flowscript and making the whole thing unmaintainable. > > > that's also one of my fears... Andy expressed this loud and clear at the Cocoon BOF, but he (and many others that never touched javascript not even with a stick) have a hard time understanding that while Java is a platform (means language + libraries), JavaScript (well, should say ECMAScript) is *just* a syntax. The object model available for your scripting is totally dependent on the environment that interprets the script. This is actually the major reason why DOM was created: to standardize the set of objects that are available from a page script in a browser environment. So while DHTML is HTML + EcmaScript + DOM, FlowScript is EcmaScript + Cocoon Flow Object Model (FOM?). This FOM is described in package org.apache.cocoon.components.flow.javascript and so far includes: JSLog.java - provides object 'Log' to the script - provides functions: Log.debug(string) Log.info(string) Log.warn(string) Log.error(string) JSCocoon.java - provides the object 'Cocoon' to the script - provides the object variables: Cocoon.interpreter Cocoon.environment Cocoon.request Cocoon.response Cocoon.session Cocoon.context Cocoon.componentManager - provides the object functions: Cocoon.load(script) Cocoon.forwardTo(uri) Cocoon.createSession() Cocoon.removeSession() Cocoon.displayAllContinuations() Cocoon.callAction(type,source,parameters) Cocoon.inputModuleGetAttribute(type,attribute) Cocoon.outputModuleSetAttribute(type,attribute,value) Cocoon.outputModuleCommit(type) Cocoon.outputModuleRollback(type) JSWebContinuation.java - provides the object 'WebContinuation' - provides the object variables: WebContinuation.id WebContinuation.continuation - provides the object functions: WebContinuation.invalidate() WebContinuation.display() and, of course, the call-with-continuation methods sendPage*() which are added to the interpreting environment directly. [ovidiu, we must make a serious effort to document this stuff or people will simply keeping on being scared of what the flowscript is. Since you are the man around that, I'd love if you could start at least filling the above skeleton with what is missing and what the calls are supposed to provide.] [snip] >>>2. Dynamic Flow Loading. >>>The way I see it, the flow controller managers the flow through a set of >>>available "views" (pipelines in our case). However, its quite possible that >>>in certain situations the flow through this particular set of views will need >>>to differ. For example, the flow through the views for a user with the >>>profile of "administrator" might be different than for that of "user". >> >>Hmmm, -0.9 it sounds like overseparation of concerns to me (oSoC, it's >>anti-pattern brother). We *want* people to work on the same file, >>otherwise, the flow of the administrator and the one of the users might >>get out of synch. > > > why should they have to be in sync? Hmmm... > it might be a totally different > flow.. yes, sure, but it smells like overseparation to me. Why don't we start with one and then see in the future what happens? I'm afraid of FS here. > If we could read the flowscript from an internal pipeline we > would be set. > > > > hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in my head, but I have several great examples of where having that would rock the planet.... but still, I'm afraid of people going back adding programmatical logic to the sitemap.... ... but it would be *so* cool to have a Workflow definition language created as markup and then having a pipeline that generates the flowscript by XSLT transformation! I know, I know, it smells of FS all around, but this would make it *so* easy to be able to connect cocoon to existing workflow editing systems. Gosh, I have to think about that. What do you people think? -- Stefano Mazzocchi -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org