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. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
