cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: flowscript bizData "AOP"
Date Sun, 18 Apr 2004 19:01:19 GMT
Ugo Cei wrote:

> Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
>> I think you can use a combination of session attributes and jx macros 
>> to get the effect you want, e.g.
>> // Flow script
>> function toSAX(str, consumer) {
>>   ...
>> }
>> cocoon.session.setAttribute("stringToSAX",  toSAX);
> So you can set a Flowscript function as an attribute of a Session? 
> Well, I suppose it makes sense, since in the end it's just an Object, 
> but it would have never occurred to me.
>> Since both Flow script (cocoon.load()) and JXTemplateGenerator 
>> (<jx:import/>) support  including other files you can factor such 
>> code into supporting "library" files and include them in your 
>> application code.
> That's true, but I suspect it's going to quickly become a FAQ unless 
> we do something to support it out-of-the-box. The number one FAQ 
> related to XSP is already "How do I insert an XML fragment taken from 
> whatever source inside my output without having special characters 
> escaped?" or a similar one.
>     Ugo
I see your point. So +1 to adding built-in support for string->SAX to 
JXTG (should also support streaming byte[], char[], InputStream, and 

The above approach has a serious drawback anyway - namely, that it won't 
work for sub-sitemaps. They share the same session and would overwrite 
each other's session attributes. As I understand it currently each 
sitemap has its own Flow interpreter with its own independent JS global 
scope. It's currently not safe to share JS objects between them because 
thread synchronization occurs on those global scopes, and all JS objects 
created within a flow interpreter are linked to the global scope object.
I still don't think the flowscript global scope should be exposed 
directly to the view as that prevents the flowscript from having private 
data shared between top level functions independent of the view. But I 
think Leszek's point is valid - you might want to create variables that 
remain accessible to the view between different invocations of  sendPage*().
Maybe what is needed is an additional variable "scope" that is 
accessible to the view and into which the flowscript can store data 
which persists between invocations of sendPage*(). This scope would be 
read-only from the POV of the view. I'm not sure what to call this scope:

- cocoon.request
- cocoon.session
- cocoon.context
- cocoon.currentFlow (or cocoon.sitemapScope, or ....)

Otherwise, another approach would be to create exactly one flow 
interpreter per session and synchronize access to it based on the 
session. This would result in all sitemaps sharing the same JS global 
scope as well as session attributes. The drawback of this approach is 
that functions and variables defined in flowscripts under different 
sitemaps would collide with each other.



View raw message