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
