To clarify, I do not mean for this abstraction to allow a user to swap
in a new EL. This is more meant for us framework developers who want to
play with a new EL for a future version of Struts. The type of EL
should be strongly bound to the version such that 2.0 will use OGNL, but
maybe 3.0 will use some JSR EL.
Therefore, we absolutely shouldn't have an expression parser, because
that would basically defeat the purpose. In the case of switching to a
JSR EL, but not using its native syntax, we lose the benefits an IDE can
give us by providing autocompletion and other assistance with expressions.
Don
Alexandru Popescu wrote:
On 9/29/06, tm jee <[EMAIL PROTECTED]> wrote:
Its doable I guess.
If we have an Expression parser / converter like Alex pointed out,
we could have a standard syntax, but it would be more complicated to
implement.
Without an Expression parser / converter, it'd likely to get users
confused as it depends on what implementation is being used.
This would be indeed a possible drawback, not to mention the confusion
that will arise from the forum posts:
[future-quote]
Q: I have the following in my JSP and it is not working:
<ww:property value="$tralala" />
A: Oh no, you need to write it ${tralala}
A: No, that's not true: you need to write it %{tralala}
A: by the way what expression language are you using?
[/future-quote]
Either case, I think we should stick with a standard supported
implementation i guess. Personally, I think that Ognl is still the
most powerfull expression language. :-)
Btw, is Ognl so slow? I think there's some caching done to the
expression evaluation, is that not sufficient to make the performance
acceptable as well?
AFAIR, considering that the expressions are already cached (which
represents an improvement on the performance), the next problem is the
value manipulation which is not so performant (though I haven't looked
so deep to suggest some optimizations)
./alex
--
.w( the_mindstorm )p.
rgds
----- Original Message ----
From: Alexandru Popescu <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Friday, 29 September, 2006 3:38:45 PM
Subject: Re: Abstracting Ognl from XWork and Struts 2?
On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I've been toying with this idea of severing XWork and Struts 2's
strict
> dependency to OGNL. The goal is not necessary to remove OGNL
outright,
> but to make it possible to replace it with another expression
language.
> I'm happy with OGNL right now, however a couple things - its slow,
> mostly unsupported, doesn't have tool support, and did I mention
slow? -
> inspire me to want to start to wean Struts off of it.
>
> How would we do it?
> 1. Pull out a ValueStack interface from OgnlValueStack
> 2. Create an abstract factory, ValueStackFactory, to create the
ValueStack
> 3. Pull out an interface from OgnlUtils and create a factory for it
> 4. Replace/abstract the custom type conversion stuff
>
> I've done 1 and 2, compiling and tests passing. #3 seems pretty easy,
> but the big question mark is #4. Also, I'd imagine things like our
tags
> are tied to the OGNL grammer, which might be interesting.
>
> Again, my goal isn't to remove it completely, but just to make it
> possible to swap it out sometime in the future with JEXL, JSP EL,
custom
> OGNL (like Wicket and Stripes have done), WW 1 EL, or BeanUtils
EL. The
> last two might be interesting to assist in migration situations.
>
> What does some of the Webwork veterans think? Is this doable?
>
IMO, this is doable. But I think it may require yet another
abstraction: an expression converter, as the engines you are
mentioning are using different types of syntax. Or, if this is
something that comes in the XValueStack implementation than I guess it
may work too.
./alex
--
.w( the_mindstorm )p.
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
