> 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)
I see. Do you mean stuff like
%{'someString'+#someContextKey+someContextRootKey}
Or is it something else?
rgds
----- Original Message ----
From: Alexandru Popescu <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Friday, 29 September, 2006 3:38:57 AM
Subject: Re: Abstracting Ognl from XWork and Struts 2?
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]
