Christopher Oliver dijo:
> 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);
Yep. We "share" flow script modules for common code. ie:
auth.js and utils and jx:macros. And this works. For example in session we
save the user name, and other session related stuff and we can access it
in any flow accross subsitemaps without problem. As a rule we avoid the
use of global variables in flow script. Here is the code that retrieves
the user name from session:
function auth_getUserID() {
var handler = "authhandler";
var authMgr;
var result = null;
try {
authMgr =
cocoon.getComponent(Packages.org.apache.cocoon.webapps.authentication.AuthenticationManager.ROLE);
// autentificación
if (authMgr.checkAuthentication(null, handler, null)) {
// Usuario autenticado, tomamos el userID
result = parseInt(authMgr.getState().getHandler().getUserId());
}
} finally {
cocoon.releaseComponent(authMgr);
}
return result;
}
>> 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.
Yep. I think this is the idea.
>> 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
> Reader?).
Not sure. AFAIK the JXTG already make SAX events, right? We only need to
care in the parsed file that is conforms an XML doc.
> 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*().
Well, for this purpose there is already cocoon.session.
> 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.
Yep. :-( And this is serious problem). In particular, we are "sharing"
function names in subsitemap. ie:
Each subsitemap have function names:
create(), save(), delete(), etc.
As you posted above, the isolation of each subsitemap is good to avoid
confusions and other advantages. If not, will be find to share code
between developers, because we will need to know what others are using as
names to avoid conflicts. Personally, I think it is bad. I would recommend
Leszek to use session variables instead of a change of this kind.
I understand the problem of lack of documentation in Flow, but a good doc
is always a good helper.
Best Regards,
Antonio Gallardo.
