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 18:24:01 GMT
On 01/08/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Sat, Aug 1, 2009 at 10:10 AM, sebb<sebbaz@gmail.com> wrote:
>  > 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.
>  >
>
> <snip/>
>
>  Not unless the user manipulates the JexlContext vars map directly.
>
>
>
>  >>
>  >>  > 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.
>  >
>
> <snap/>
>
>  Its another difference between a standalone JEXL script and one
>  executed in a 223 environment. So it needs to be added, maintained,
>  documented, understood (by users) and used correctly. As you already
>  point out below, this is all doable right now via the 'context'
>
> 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...
>  >
>
> <snip/>
>
>  Built-in variables are a bit of a pain (we use them more extensively
>  in Commons SCXML as they are required by the spec) so if there is any
>  way to avoid having more of them, that'd be good. How about one JEXL
>  object that any built-in stuff hangs off? So, JEXL.out would be
>  System.out, for example. Extensible in the sense that JEXL.foo and
>  JEXL.bar could come along as needed without polluting the vars map
>  with more built-in names.

Nice!

Sounds good, I'll create an initial implementation.

Probably OK to use global scope to store it in?

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