Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:I see your point. So +1 to adding built-in support for string->SAX to JXTG (should also support streaming byte[], char[], InputStream, and Reader?).
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
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.
WDOT?
Chris
