Subj : Re: Question about Rhino contexts
To   : netscape.public.mozilla.jseng
From : Mark Turansky
Date : Wed Sep 07 2005 11:42 am

This reply may not be the one you're looking for, but it seems to me you
could simplify your application.  The more you can remove the better.  The
fewer "moving pieces" the better.

See Occam's Razor:  http://pespmc1.vub.ac.be/OCCAMRAZ.html

That said, Rhino has native XML support now thanks to E4X.  I imagine you
could cut Jelly right out of the equation if you wanted to.

Lastly, if you don't need xml, why use it at all?  Javascript Object
Notation  (JSON - www.json.org) is just as expressive in terms of data
markup but it includes semantics that xml does not have and is lighter
weight (no parsing required, easier on the bandwidth).



"Jon Brisbin" <jon.brisbin@npcinternational.com> wrote in message
news:mailman.1126031040.20161.mozilla-jseng@mozilla.org...
> I seem to be having problems getting the context in my executions of
> JavaScript. Before I switched to straight Rhino (i.e. cut out BSF from
> the equation) I noticed that my two different kinds of JavaScript don't
> talk to each other now. Here's what I mean:
>
> My web application framework looks at the DOM controlling it's execution
> via a Jelly script execution. I have a Jelly tag that handles the
> JavaScript scripting at this stage.
>
> Once that XML file is read, it is interrogated for the child elements,
> those are retrieved, and each is executed in order.
>
> When I was using BSF, I could pass the BSFManager into each of these
> scripting elements and anything declared in a JavaScript in one part of
> the application would be visible to another part of the application at a
> different point in the processing cycle. I'm pretty sure that's because
> the Rhino JavaScript engine in BSF just does a Context.enter(). When I'm
> not debugging, I use Context.enter(), but when I am debugging I have to
> do it differently because I'm using a global Context. Obviously, I can't
> use a global context in a multi-threaded web application, so I have to
> restrict myself to thread-based or processing-based techniques.
>
> So far, I've tried storing the Scriptable scope object that I use in a
> HashMap that gets passed between Jelly and my framework. I've also tried
> using Context.put(/get)ThreadLocal() and using a generic, global scope.
> I can't seem to figure out, even when I'm using Context.enter(), that my
> objects defined (like function definitions I want available to everyone
> who will executing during this run) in Jelly-based JavaScript processing
> don't get communicated to the next execution of JavaScript (where I'm
> also using Context.enter()).
>
> Since this is a web application, everything is getting executed in a
> single thread, so there should be no problems there. Jelly scripts are
> compiled and cached, but executed on every request, so I don't think
> things are getting set in Jelly and then not being available later
> because they are being accessed from a different thread than the one
> that created them. I could be wrong on that one, though...
>
> Any ideas?
>
> Thanks!
>
> Jon Brisbin
> NPC International, Inc.

.