On 01/08/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > On Sat, Aug 1, 2009 at 10:10 AM, sebb<seb...@gmail.com> wrote: > > 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. > > > > <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-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
