On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
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.
(Being maybe too pragmatic) I would ask: than why not leave it for
that moment, and now just settle everything for a big/noisy rekease?
./alex
--
.w( the_mindstorm )p.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
