> Yeah, Struts 2 in Action isn't bad.
>
> :/
>
> Dave
I can confirm, it's better to have orginal version ;-)
Regards
--
Lukasz
http://www.lenart.org.pl/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-ma
--- On Thu, 9/25/08, Philip Luppens wrote:
> But all in all, a nice resort, and perhaps a good introduction for new
> developers besides the current guides.
Yeah, Struts 2 in Action isn't bad.
:/
Dave
-
To unsubscribe, e-mail
pot.com/2008/09/struts-2-and-ognl.html
>
> --
> View this message in context:
> http://www.nabble.com/-s2--Struts-2-and-OGNL-findings-tp12558251p19664629.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> --
Here is a good article on Struts 2 and OGNL
http://struts2-java.blogspot.com/2008/09/struts-2-and-ognl.html
--
View this message in context:
http://www.nabble.com/-s2--Struts-2-and-OGNL-findings-tp12558251p19664629.html
Sent from the Struts - Dev mailing list archive at Nabble.com
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
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
immediat
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. "${"
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 fa
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 ma
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
relev
On Mon, Sep 10, 2007 at 7:02 PM, Don Brown <[EMAIL PROTECTED]> 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
Henri also is fixing a lot of outstanding EL bugs in the taglibs project.
On 9/11/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
>
> 2007/9/11, Don Brown <[EMAIL PROTECTED]>:
> >
> > As far as a replacement, personally, I'm more interested in
> > incorporating the "Unified EL", standardized by JS
2007/9/11, Don Brown <[EMAIL PROTECTED]>:
>
> 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 st
s with implementing the improvements.
>
> James
>
>
> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 08, 2007 10:50 AM
> To: Struts Developers List
> Subject: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
>
&
OGNL abstracted (was Struts 2 and OGNL findings)
Ok, so take that last bit I said about wanting to keep with OGNL tied
throughout our code and scrap it. I've just finished the first step
in a major refactoring of our OGNL usage, both in XWork and Struts,
and have found a way to put all
Ok, so take that last bit I said about wanting to keep with OGNL tied
throughout our code and scrap it. I've just finished the first step
in a major refactoring of our OGNL usage, both in XWork and Struts,
and have found a way to put all code that references OGNL in any way
in its own package, and
Thanks so much, Don. OGNL has been a point of concern, and I'm glad
you were able to look into it.
With TP5 moving away from OGNL, do we know of any other projects other
than XW still using it?
If not, then if we (meaning XW) starts to tweak OGNL, would it make
sense to bring OGNL into the XW cod
Sounds good. Thanks.
- Original Message
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List ; Jon Wilmoth <[EMAIL
PROTECTED]>
Sent: Friday, September 7, 2007 9:20:36 AM
Subject: Re: [s2] Struts 2 and OGNL findings
Correct, static fields are still accessible,
eptember 7, 2007 9:04:37 AM
> Subject: [s2] Struts 2 and OGNL findings
>
>
> I spent the last couple days looking into the OGNL situation in Struts
> 2 and XWork, with the intent on if not eliminating it, at least
> blocking it cleanly off. The summary is this:
> 1. Refactored the
Does #2 include access to static fields (i.e. Constants) or are these not
affected by your change?
Thanks,
Jon
- Original Message
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Friday, September 7, 2007 9:04:37 AM
Subject: [s2] Struts 2 and OGNL findin
I spent the last couple days looking into the OGNL situation in Struts
2 and XWork, with the intent on if not eliminating it, at least
blocking it cleanly off. The summary is this:
1. Refactored the TypeConverter system away from OGNL into new XWork API [1]
2. Turned off static method access in
21 matches
Mail list logo
