--- James Carman <[EMAIL PROTECTED]> wrote:
> I wanted to start up a discussion about maybe
> starting a new sandbox
> project for expression abstraction. It could be
> named
> commons-expresso. I realize that there's a J2EE
> framework out there
> called "Expresso", but its site hasn't been updated
> since 2005, so I
> don't know how active it is or if this would even be
> a conflict
> anyway. I don't really care what it's called. I
> just care about the
> content.
>
> For those who have not been reading the other
> threads, I would like to
> create a project which allows us to abstract the
> idea of an
> "expression" in Java. Here's the main interface:
>
> public interface Expression
> {
> public Object getValue(Object root);
> public void setValue(Object root, Object value);
> }
>
> This could be generified to perhaps:
>
> public interface Expression<R,V>
> {
> public V getValue(R root);
> public void setValue(R root, V value);
> }
>
> Anyway, the "guts" of the project would be the
> implementations of this
> interface. I have plans to implement it using the
> following
> technologies for now (please add suggestions if you
> have them):
>
> Javassist
> MVEL
> OGNL
> JSTL-EL
> JXPath
>
> That's just a preliminary list, but you get the idea
> of the sort of
> thing I'm looking for. Matt Benson has suggested
> that this sort of
> thing might be best suited to go into his "Morph"
> project currently
> located at Sourceforge.
Actually, to clarify, Morph isn't "mine." Matt
Sgarlata is the primary developer; I just came in
midway and started helping out (at least I like to
think my input has been helpful)... then, I wasn't
necessarily suggesting that new work on the expression
concept should go into Morph, either. Actually I see
Morph being broken down into smaller pieces once we
get it into Commons. It sounds like you're suggesting
a package similar to [proxy]/[logging]/[openpgp] whose
basic purpose is to provide a common interface over
various similar underlying technologies. I honestly
think Morph @ Commons would ultimately have its
Language facilities removed or moved elsewhere, so
maybe there's not much overlap here beyond the idea
that your proposed project might conceivably contain
one or more built-in implementations, and one of these
might be derived from Morph's basic Language
implementation, SimpleLanguage.
> Currently, it doesn't have
> anything like
> this. The project would also contain expression
> "builder"
> implementations which would allow you to use Java to
> build up the
> expression:
>
> public interface ExpressionBuilder<R>
> {
> public R recorder();
> public <V> Expresion<R,V> buildExpression(V
> value);
> }
>
> Example usage:
>
> ExpressionBuilder builder = new
> JavassistExpressionBuilder<Person>();
> Expression<Person,String> expr =
>
builder.buildExpression(builder.recorder().getAddress().getCity());
> Person p = ...;
> String city = expr.getValue(p);
>
> The cool thing about this is that you can switch the
> expression
> implementation without changing how you build up the
> expression!
> Thoughts anyone?
This would qualify as one of the built-in expression
"engines" I mentioned before, really. So... you're
suggesting that _most_ of the "expression factory"
implementations supported by this proposition would be
built from Strings, but that it wouldn't necessarily
be so all the time? How are you intending your
recordable implementation to be able to handle set vs.
get operations, though? I don't get that from your
example.
-Matt
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
