You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wendy Smoak <ws...@gmail.com> on 2008/02/16 00:38:46 UTC
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
On Mon, Sep 10, 2007 at 7:02 PM, Don Brown <mr...@twdata.org> wrote:
> I guess you really don't know until you benchmark it,
...
> As far as a replacement, personally, I'm more interested in
> incorporating the "Unified EL", standardized by JSP 2.1 but usable by
> older servlet containers. It may even be possible to put OGNL behind
> the Unified EL API, allowing us to code to a standard and allow the
> user to fully swap the EL.
Did anything ever happen with this? Can you switch to a different EL
in Struts 2.1?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Blake Byrnes <bl...@gmail.com>.
Does UEL have better generics support? Using generics with Struts 2 actions
or models (or anything OGNL needs to interact with) is fairly difficult
right now. I've also found OGNL to be pretty much a mystery anytime I need
to do anything new (this could be more a matter of spitting out more
relevant information when errors occur).
On Fri, Feb 15, 2008 at 6:38 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Mon, Sep 10, 2007 at 7:02 PM, Don Brown <mr...@twdata.org> wrote:
> > I guess you really don't know until you benchmark it,
> ...
> > As far as a replacement, personally, I'm more interested in
> > incorporating the "Unified EL", standardized by JSP 2.1 but usable by
> > older servlet containers. It may even be possible to put OGNL behind
> > the Unified EL API, allowing us to code to a standard and allow the
> > user to fully swap the EL.
>
> Did anything ever happen with this? Can you switch to a different EL
> in Struts 2.1?
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
I started an "Issues" section and a "Goals" section to explicitly
identify the problem(s) that needs to be solved.
http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
Brian Pontarelli wrote:
> Yeah, this is one of the frustrations that most beginners encounter
> and that I'd really like to fix. I'd say it should be ${} or #{} so
> that it is the same notation in JSPs, XML, etc. In fact, I would think
> that it would make the most sense to follow the UEL convention such
> that ${} is immediately evaluated and #{} is evaluated later. So, in
> the case of XML and annotations, it would probably be #{} to follow
> the standard. Furthermore, you should be able to use ${} in XML and
> annotations and it is resolved immediately. This would be useful for
> servlet context values (context path, etc), statics, and other types
> of configuration.
>
> If anyone wants to help catalog all the OGNL usages, this will be the
> first step in getting this stuff changed. I started a wiki page to
> track all this information:
>
> http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
>
> -bp
>
>
> Dale Newfield wrote:
>> Brian Pontarelli wrote:
>>> I've been trying to catalog all of the cases where OGNL exists and
>>> where it can be replaced.
>>
>> Since different ELs specify different mechanisms to state "this is an
>> expression to be evaluated", I wonder what we should do about the
>> delineating characters "%{"/"}" vs. "${"/"}" vs. "#{"/"}", etc.
>>
>> Right now in result specifications in struts.xml (when the result
>> supports it, and when parsed) we use ${} to say "this is an
>> expression to be evaluated" even though it's currently ognl (which
>> uses %{}). I'm of several thoughts regarding this. One one hand
>> since it's OGNL I think it should be %{}. On the other hand if we're
>> contemplating switching ELs maybe it should not be EL-specific so
>> that the EL can be changed without modifying all the expressions.
>>
>> So: Is it possible to have these change with the EL? Is it
>> desirable? If we want to use a single type for all ELs, which should
>> it be?
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Brian Pontarelli <br...@pontarelli.com>.
Yeah, this is one of the frustrations that most beginners encounter and
that I'd really like to fix. I'd say it should be ${} or #{} so that it
is the same notation in JSPs, XML, etc. In fact, I would think that it
would make the most sense to follow the UEL convention such that ${} is
immediately evaluated and #{} is evaluated later. So, in the case of XML
and annotations, it would probably be #{} to follow the standard.
Furthermore, you should be able to use ${} in XML and annotations and it
is resolved immediately. This would be useful for servlet context values
(context path, etc), statics, and other types of configuration.
If anyone wants to help catalog all the OGNL usages, this will be the
first step in getting this stuff changed. I started a wiki page to track
all this information:
http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
-bp
Dale Newfield wrote:
> Brian Pontarelli wrote:
>> I've been trying to catalog all of the cases where OGNL exists and
>> where it can be replaced.
>
> Since different ELs specify different mechanisms to state "this is an
> expression to be evaluated", I wonder what we should do about the
> delineating characters "%{"/"}" vs. "${"/"}" vs. "#{"/"}", etc.
>
> Right now in result specifications in struts.xml (when the result
> supports it, and when parsed) we use ${} to say "this is an expression
> to be evaluated" even though it's currently ognl (which uses %{}).
> I'm of several thoughts regarding this. One one hand since it's OGNL
> I think it should be %{}. On the other hand if we're contemplating
> switching ELs maybe it should not be EL-specific so that the EL can be
> changed without modifying all the expressions.
>
> So: Is it possible to have these change with the EL? Is it
> desirable? If we want to use a single type for all ELs, which should
> it be?
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Dale Newfield <Da...@Newfield.org>.
Brian Pontarelli wrote:
> I've been trying to catalog all of the cases where OGNL exists and where
> it can be replaced.
Since different ELs specify different mechanisms to state "this is an
expression to be evaluated", I wonder what we should do about the
delineating characters "%{"/"}" vs. "${"/"}" vs. "#{"/"}", etc.
Right now in result specifications in struts.xml (when the result
supports it, and when parsed) we use ${} to say "this is an expression
to be evaluated" even though it's currently ognl (which uses %{}). I'm
of several thoughts regarding this. One one hand since it's OGNL I
think it should be %{}. On the other hand if we're contemplating
switching ELs maybe it should not be EL-specific so that the EL can be
changed without modifying all the expressions.
So: Is it possible to have these change with the EL? Is it desirable?
If we want to use a single type for all ELs, which should it be?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Brian Pontarelli <br...@pontarelli.com>.
I've been trying to catalog all of the cases where OGNL exists and where
it can be replaced. I'll sometime in the next few weeks to really work
on this and I'm hoping that we can replace OGNL from all developer
facing locations and completely standardize on EL. I think most folks
would be in favor of making things simpler and more standard across all
layers of Struts, including JSPs.
From what I've found thus far, I think the main point where OGNL is
extremely useful and something similar to OGNL is required is the
parameter handling. Other than that, it is just a matter of changing
code and possibly losing some features such as inline list and map
creation (not sure if UEL has this or not).
-bp
Jeromy Evans wrote:
> Wendy Smoak wrote:
>> Did anything ever happen with this? Can you switch to a different EL
>> in Struts 2.1?
>>
>>
> Hi Wendy,
> Not at this point. A plugin has been started in the sandbox
> (struts2-uel-plugin). However, my impression in that OGNL is deeply
> entrenched and making the EL switchable is a major undertaking. For a
> start, the Component, which every tag extends, has numerous methods
> that have been assumed to evaluate OGNL to access the valuestack (eg.
> findString) and the default converters all seem to fall-back to OGNL
> to determine object types. These can be made EL-independent, or OGNL
> wrapped so UEL can be used in the tags, but it's not going to be easy!
>
> See the thread(s) from November 07 containing "JUEL plugin" in the
> subject
>
> reagrds,
> Jeromy Evans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Wendy Smoak wrote:
> Did anything ever happen with this? Can you switch to a different EL
> in Struts 2.1?
>
>
Hi Wendy,
Not at this point. A plugin has been started in the sandbox
(struts2-uel-plugin). However, my impression in that OGNL is deeply
entrenched and making the EL switchable is a major undertaking. For a
start, the Component, which every tag extends, has numerous methods that
have been assumed to evaluate OGNL to access the valuestack (eg.
findString) and the default converters all seem to fall-back to OGNL to
determine object types. These can be made EL-independent, or OGNL
wrapped so UEL can be used in the tags, but it's not going to be easy!
See the thread(s) from November 07 containing "JUEL plugin" in the subject
reagrds,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org