commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [JEXL] 2.0 JSR-223 initial implementation added - what next?
Date Sat, 01 Aug 2009 14:10:54 GMT
On 01/08/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Sat, Aug 1, 2009 at 12:21 AM, sebb<sebbaz@gmail.com> wrote:
>  > On 01/08/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>  >> On Fri, Jul 31, 2009 at 9:42 PM, sebb<sebbaz@gmail.com> wrote:
>  >>  > On 31/07/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>  >>  >> On Thu, Jul 30, 2009 at 10:54 PM, sebb<sebbaz@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.
>

Ah, I was wondering about that.
So presumably JEXL never invokes remove() on the Jexl context?
I checked in Eclipse and it could not find a reference.

>
>  > 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.

That would not need a change to the EL.
The script engine would just need to check the value of the
"set_scope" variable.

>  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).

Or use

context.getBindings(200).put(key,value);

Given that read/write access to global variables is now handled the
same as for engine variables, I thought it would be convenient to do
the same for global variable creation.

>
>  > 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.

For which I think we need a naming convention...

>  -Rahul
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message