2009/11/3 Musachy Barroso :
> I think I saw it in someone's blog but now I can't find it..did I make
> this up? Anyway, I am out of pet projects, so I might just play with a
> UEL plugin :)
Is it really necessary? Isn't it possible to let EL be used by the container?
In Tiles, in JSP support modul
We also have FreeMarker , Velocity and we have a lot of expression
evaluations from Struts code itself.
musachy
On Tue, Nov 3, 2009 at 12:29 AM, Antonio Petrelli
wrote:
> 2009/11/3 Musachy Barroso :
>> I think I saw it in someone's blog but now I can't find it..did I make
>> this up? Anyway, I a
2009/11/3 Musachy Barroso :
> We also have FreeMarker , Velocity and we have a lot of expression
> evaluations from Struts code itself.
And in this case you're right, EL at Struts-side is obligatory.
But exactly, is a bad idea to use the capability of the container to
resolve EL expressions into v
I still think that the simplest approach is still to do nothing except
for EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time you need anything remotely similar to EL is for getting and
setting values out of beans. This is generally not EL handling, but
basic JavaB
That would be ok except for one thing: the value stack. To support the
value stack in those view technologies is the problem. I have tried so
many things, and failed in all of them that it is lame. I will finally
merge my parameters-binder branch in xwork into trunk, and see if I
can get some folks
It's been a while, but that is really more of an current action stack
(I call it the ActionInvocation stack). I recall that I was able to
get most of the functionality I needed into JCatapult while still
using the FTL/JSP expression languages.
-bp
On Nov 3, 2009, at 11:10 AM, Musachy Barr
The parameters binder branch is now merged into xwork trunk (manual
merge thanks to svn being a PITA)(for those unaware, this contains
some experimental code to set parameters in the actions without using
OGNL directly, it is faster, and more secure) . Now we can start
playing with other ELs seriou
what he meant was: we are too lazy to maintain code in 2 different
repositories :)
musachy
On Tue, Nov 3, 2009 at 1:40 PM, Wes Wannemacher wrote:
> Heh, it was my idea to make it a proper, built-in result type... But,
> my motivation for this was that plugins shouldn't depend on other
> plugins.
That was the magic jar. Thanks!
Wes Wannemacher wrote:
> No, Chris, it's definitely still a plugin...
>
> David, download the jar from here -
>
> http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/
>
> -Wes
>
OK. I removed the original GoogleCode dependency from my project, but
now it doesn't appear to find *any* such plugin. It's unclear to me
where the JSON Plugin is located within the Struts framework and how to
get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that
doesn't appear t
The patch seems to be missing in your mail, maybe you want to open a
JIRA ticket and attach the patch to it.
- René
ashish mahamuni schrieb:
> Hi there,
>
> I've created the patch on struts-2.1.8 stable build.
> Also, attached the added files with this mail.
> Please, have it reviewed and if sui
>From what I understand, it's no longer a plugin, it's part of the base
Struts functionality. You don't have to do anything extra. All you have to
do is define your result type to be json and struts will know what you mean.
(*Chris*)
On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks wrote:
> OK
+1 GA (binding)
Wes Wannemacher schrieb:
> The Struts 2.1.8 test build is now available.
>
> Release notes:
> * [http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.8.1]
>
> Distribution:
> * [http://people.apache.org/builds/struts/2.1.8.1/]
>
> Maven 2 staging repository:
> * [http
What happened to the whole decision to bring JSON into the core? Is it true
that all that was done was to move the link from a Google Code URL to a
harder to find Apache URL? That's not the discussion I remember...
(*Chris*)
On Tue, Nov 3, 2009 at 1:25 PM, Wes Wannemacher wrote:
> No, Chris,
Musachy Barroso wrote:
> what he meant was: we are too lazy to maintain code in 2 different
> repositories :)
>
Can't say I blame you. Makes sense to me to have it all in one place,
anyway.
Great work, by the way! 2.1.8.1 seems to be pretty solid.
Thanks, Wes!
Wes Wannemacher wrote:
> No, Chris, it's definitely still a plugin...
>
> David, download the jar from here -
>
> http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/
>
> -Wes
>
> On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt wrote:
>
>> From what I understand,
Wes, is this new plugin referenced in a new struts package type? That
seems to be where I'm getting the GoogleCode plugin from. My package
extends "json-default", and, as far as I can tell, this is where the
plugin itself is referenced.
Thanks again!
Dave
Wes Wannemacher wrote:
> We moved that
Heh, it was my idea to make it a proper, built-in result type... But,
my motivation for this was that plugins shouldn't depend on other
plugins. I was planning the JQuery plugin in my mind and I wanted
proper support for JSON. Since it was not only a plugin, but an
external plugin, using JSON in a
2009/11/3 Musachy Barroso :
> Well yes, that's by default, but with the new EL api you can plugin a
> new EL resolver like:
>
> JspApplicationContext jspApplicationContext =
> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
> jspApplicationContext.addELResolver(new Compou
No, Chris, it's definitely still a plugin...
David, download the jar from here -
http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/
-Wes
On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt wrote:
> From what I understand, it's no longer a plugin, it's part of the base
> Struts
20 matches
Mail list logo
