On Wed, Apr 9, 2008 at 11:18 PM, James Carman <[EMAIL PROTECTED]> wrote: > On Wed, Apr 9, 2008 at 9:47 PM, James Carman <[EMAIL PROTECTED]> wrote: > > So, does anyone object to me putting this code into the sandbox? <snip/>
No, I support this and would like to work on it. > > I've > > got working versions of expressions and builders (with test cases of > > course) for: > > > > MVEL > > OGNL > > BeanUtils > > JXPath > > > > If you're interested, I set it up in my own SVN repository while I was > working on it: > > http://svn.carmanconsulting.com/public/commons-expression/trunk > <snap/> Thanks a lot, this is great. I was lost reading the emails in this thread but the code has made things much clearer. I have some immediate comments: (1) The proposed API feels like [objectgraphnavigation] rather than [expression], which is an interesting subset of expressions, but limiting nevertheless. I'm interested in the latter, and also think it makes the former redundant. (2) I'd like to claim that [expression] is a solved problem ;-) [scxml] requires pluggable expression languages and already has an abstraction over ELs: http://commons.apache.org/scxml/guide/contexts-evaluators.html The core of [expression] should consist of two interfaces (I'm happy to do this by cleaning up the corresponding bits in [scxml]): public interface Context { Object get(String name); void set(String name, Object value); } public interface Evaluator { Object evaluate(String expression, Context context) throws EvaluationException; Context newContext(Context parent); } Names TBD etc. SAMPLE USAGE (untested, ofcourse): Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example Context context = evaluator.newContext(null); context.put(...); try { /*Some type*/ result = evaluator.evaluate("...", context); } catch (EvaluationExpression ee) { // ... } We have proven implementations of this in [scxml] land for: * EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well) * Commons JEXL * JavaScript (by way of Rhino) * Various (by way of javax.script) * Pnuts Other comments: * I've done adapters for two proprietary ELs * MVEL would be trivial * I'm not familiar with its OGNL APIs, will take a look later To summarize, generally the above abstraction has worked well. (3) Generics don't buy us much in terms of type safety / correctness guarantees for [expression]. Lets not use them (easier to support 1.4 that way, for example). (4) I don't think of BeanUtils as an expression language, or JXPath for that matter (relates to point 1 above a bit). That doesn't mean there can't be corresponding Evaluator implementations, just means users of those implementations will need to understand the limitations (and we will need to document them). For example, don't ask the BeanUtils evaluator to evaluate "22 / 7". (5) The [proxy] APIs have bled into your proposal. While thats completely understandable in a PoC since you have the [proxy] usecase in mind, we will have to clean that up. Perhaps [proxy] or [scxml] might need a subinterface or equivalent of the cleaner [expression] APIs, we'll have to see. If [expression] makes progress, I'd want [scxml] to depend on it. I suggest we use the interfaces above, I can bootstrap [expression] in the sandbox per those. -Rahul > Enjoy! > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
