On 01/08/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > 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. >
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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
