cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Discussion of Flow Issues
Date Tue, 18 Mar 2003 23:00:51 GMT
Sylvain Wallez wrote:
> Pier Fumagalli wrote:
> 
>> On 18/3/03 21:29, "Christopher Oliver" <res1cf5x@verizon.net> 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)...
>>  
>>
> 
> Mmmh, I don't like it much, as AFAIU it will require too much often to 
> write some glue code for things that could be written in JS only...

I think the above method that Chris suggests is fair for sessions 
(making it a *little* hard, but not too much) but I agree with Sylvain 
that this is way too much overhead for the remaining part of the FOM.

But I have the impression i didn't understand what Pier was implying 
because I'm sure he would not propose to force people to write that much 
java gluecode just for everyday FOM usage.

Pier, can you elaborate more on what you wanted to say above? TIA

Stefano.




Mime
View raw message