On Sat, Aug 1, 2009 at 12:21 AM, sebb<seb...@gmail.com> wrote:
> On 01/08/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote:
>> On Fri, Jul 31, 2009 at 9:42 PM, sebb<seb...@gmail.com> wrote:
>>  > On 31/07/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote:
>>  >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<seb...@gmail.com> wrote:
<snip/>
>>  >>  > Several items remain to be resolved:
>>  >>  >
>>  >>  > The current implementation only has direct access to the ENGINE_SCOPE 
>> bindings.
>>  >>  >
>>  >>  > If we wish to give direct access to GLOBAL_SCOPE, how should this be 
>> managed?
>>  >>  > Perhaps use a name prefix to indicate that the variable is intended to
>>  >>  > be global?
>>  >>  >
>>  >>
>>  >> <snap/>
>>  >>
>>  >>  No. The engine scope is nearest, so on read or update, check engine
>>  >>  first and global second. No prefixes.
>>  >>
>>  >
>>  > That's fine, but how does one create an entry in the global table?
>>  > Or is that not allowed?
>>  >
>>
>> <snap/>
>>
>>  Thats the job of the javax.script environment. More specifically, the
>>  ScriptEngineManager will inject the global scope bindings into the
>>  ScriptEngine. We just have to heed those -- IOW, anything other than
>>  put(), putAll() and remove() in the JexlContextWrapper class you have
>>  should refer to the union of the engine and global scopes. For methods
>>  where orders matters i.e. containsKey/Value() and get(), engine scope
>>  beats global. Finally, IMO the clear() implementation should remain
>>  as-is and not touch the global scope.
>>
>
> Yes, one can now set up the global scope with some key-value pairs;
> these are now readable/writable by a JEXL script. However, it's not
> currently possible to create a global key. If put() uses a key that is
> not currently present, it will generate an engine-scope variable.
>
<snap/>

Yup, as it should.


> Seems to me if we allow read/write/delete of global variables by a
> JEXL script, then we should also allow creation of global variables.
<snip/>

Except there is no real delete.


> This would allow different scripts (possibly different languages) to
> communicate via the global area.
>
> How to allow this? One method would be to use a naming convention.
> Another might be to have a global-shift key - if the key is set, then
> apply changes to the global scope only, for example:
>
> localvar=123;
> set_scope="global"
> globalval=456;
> set_scope="local"
>
> A bit of a hack, but do-able.
>
<snap/>

No need to hack the EL itself.

Folks needing to create global variables can always inject into the
engine scope an object with a method that creates a global variable
(and invoke it in jexl script as needed).


> The ScriptEngine implementation could even make certain classes of
> global variables read-only, for example System_OUT etc. by disallowing
> changes to them.
>
<snip/>

Yeah, making any built-in variables read-only sounds good.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to