On 18/3/03 21:29, "Christopher Oliver" <[EMAIL PROTECTED]> wrote:
> Stefano Mazzocchi wrote:
>>> Another possibility is to only expose the session at the Java level
>>> (not JavaScript) forcing new JavaScript objects that need access to it
>>> to be written in Java. This might prevent abuse.
>>
>>
>> Hmmm, if you don't get a hook to the ObjectModel, how can you get a java
>> session object from the flow?
>>
>
> What I meant was instead of this:
>
> public class JSCocoon extends ScriptableObject {
>
> public Session jsGet_session() // expose session to JavaScript
> {
> ...
> }
> }
>
>
> we could do this:
>
> public class JSCocoon extends ScriptableObject {
>
> public Session getSession() { // not available in JavaScript
> }
>
> public static Session getSession(Scriptable scope) {
> Scriptable topLevel = getTopLevelScope(scope);
> Object obj = getProperty(topLevel, "cocoon");
> return ((JSCocoon)obj).getSession();
> }
> }
>
>
> Then if you need access to a Session you would have to implement a
> JavaScript object in Java, for example:
>
>
> class MyObject extends ScriptableObject {
>
> public String getClassName() {return "MyObject";}
>
> public void jsFunction_foo() {
> // I need the session:
> Session session = JSCocoon.getSession(this);
> }
> }
>
> Then in javascript you could do this:
>
> var obj = new MyObject();
> cocoon.session; // undefined
> obj.foo(); // but foo() uses the session
I like your approach _MUCH_BETTER_... I think we should consider it for most
of the stuff we make visible to the flow, rather than passing the real Java
instances to Rhino (obviously removing the construction part when needed)...
Pier
