Cameron,
I played around with doing something similar to this with Bebop, which is my
own spiffy cool component container. I think integration with Spring would
be fairly comparable.
Basically, the ActionProxy needs an ActionConfig. So, you can either:
specify enough in your xwork.xml so that
I was thinking of doing something just like this, i've got alot of
boiler plate exception handling code in all my actions that i could get
rid of by using something like this.
Fred Lamuette wrote:
Is there an exception handler mechanism in xwork ?
Something like :
that could redirect exceptions
I've started on the cleanup of webwork 1.3 sources. if anyone is
vaguely upset by any of this then please do speak up! This is what I've
done so far:
Moved all jars into directories under lib. We have lib/optional,
lib/view, lib/core, and lib/build.
I've removed the jasper report compilation f
Is anyone working on integration between Xwork and the Spring Framework.
I have managed to create a webwork interceptor that allows a xwork
action to make use of any spring bean by creating a simple mapping.
However, I would like a better soloution that uses spring as the action
facory.. And I
Err, why on earth would you want this in webwork? What's wrong with the
exception handlers you can specify in web.xml, which work exactly as
described below?
On Oct 31, 2003, at 10:18 PM, Jason Carreira wrote:
Nope... Interesting idea... Post a Jira issue for it...
-Original Message-
F
We'll see what we get to ... Definitely before 1.0 final
> -Original Message-
> From: Fred Lamuette [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 31, 2003 2:53 PM
> To: [EMAIL PROTECTED]
> Subject: [OS-webwork] XWork release
>
>
> Jason,
> Do you plan to get the patch (XW-105) in th
Nope... Interesting idea... Post a Jira issue for it...
> -Original Message-
> From: Fred Lamuette [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 31, 2003 3:00 PM
> To: [EMAIL PROTECTED]
> Subject: [OS-webwork] Exception handler proposal
>
>
> Is there an exception handler mechanism
Because the property setting should catch the exception and add a field
error...
> -Original Message-
> From: James Cook [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 31, 2003 2:31 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] Any hope of validating empty input text?
>
>
>
Hani Suleiman wrote:
Would anyone mind terribly if I had shuffled things around in ww 1.3?
The directory structure is annoying, the changes I'd like to make are
to bring it more inline with other os projects, including:
Great! Please consider applying my changes for more efficient
URLBean/URLT
Is there an exception handler mechanism in xwork ?
Something like :
that could redirect exceptions inherited from mypack.ApplicationException to
the myExceptionHandlerAction action ?
Cheers.
Richard HALLIER
Chef de projet
[EMAIL PROTECTED]
01.40.12.41.52
www.uniclick.org
UNICLICK
Jason,
Do you plan to get the patch (XW-105) in the next beta WW2 release ?
Cheers.
Richard HALLIER
Chef de projet
[EMAIL PROTECTED]
01.40.12.41.52
www.uniclick.org
UNICLICK
---
This SF.net email is sponsored by: SF.net Giveback Program.
Doe
Hi,
>I'm not sure where you're looking... I refactored the 3 Result classes to all extend
Ouch! You did exactly what I did :) ...
Sorry, I was using the Beta 1 code ... I was planning patch at home because there I'm
with the last
CVS head.
thanks
Samuel
---
> -Original Message-
> Behalf Of Jason Carreira
> You also get number format messages for non int values?
> That's a bug... It should just add a field error...
Here is the exception for a non-numeric value. How can this ever be a
field error if OGNL throws this before the calidation inter
-Original Message-
From: Jason Carreira
Sent: Friday, October 31, 2003 1:20 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [OS-webwork] Xwork Parse variables at dispatchers
I'm not sure where you're looking... I refactored the 3 Result classes to all extend
com.opensymphony.webwork.dispatche
The problem with the empty field value is the Ognl 2.6.3 bug we've been
waiting for a fix to for a while now...
You also get number format messages for non int values? That's a bug...
It should just add a field error...
> -Original Message-
> From: James Cook [mailto:[EMAIL PROTECTED]
>
James Cook wrote:
> Does anyone have any good ideas for determining the presence of field or
> action errors using only JSTL?
>
>
>
> Doesn't work, because a new HashMap is created on the fly.
>
>
>
> Doesn't work, because it would expect a getSize() function on the Map,
> when the function i
I have the following field in my Action:
Integer _personIDNumber;
And the following input field in my JSP:
My validation requirements are:
You must enter a value for person ID
number.
When the code executes and I supply no value in the input
I'm not sure where you're looking... I refactored the 3 Result classes to all extend
com.opensymphony.webwork.dispatcher.WebWorkResultSupport, which delegates to
subclasses after parsing the location parameter.
> -Original Message-
> From: Samuel Mota [mailto:[EMAIL PROTECTED]
> Sent:
Does anyone have any good ideas for determining the presence of field or
action errors using only JSTL?
Doesn't work, because a new HashMap is created on the fly.
Doesn't work, because it would expect a getSize() function on the Map,
when the function is size().
So, I have to resort to som
Hi,
I was trying to use variables (${variable}) within results at xwork.xml with
Dispatcher result type.
So I noticed that this feature is not consistent through the 3 main result types
(dispatcher,
redirect and velocity).
At (com.opensymphony.webwork.dispatcher):
ServletRedirectResult.java:
Scott Farquhar wrote:
Hani Suleiman <[EMAIL PROTECTED]> wrote ..
Fine by me. If possible - leaving the source in the current directory (even if it is main) would be best, so as to preserve the file's history.
Yeah definitely, source won't move.
I don't think that there are many testcases for 1
Sebastiano Pilla wrote:
At 14.57 31/10/2003, Hani Suleiman wrote:
I don't mind, of course... but now that you mention it, what's the
status of WW 1.3.1? The OS Jira shows that 22 of 56 issues have been
fixed for the 1.3.1 version, and several OS committers are currently
much more focused on WW
Wouldn't it be a better use of your time to work on WW2?
On Fri, 31 Oct 2003, Hani Suleiman wrote:
> Would anyone mind terribly if I had shuffled things around in ww 1.3?
>
> The directory structure is annoying, the changes I'd like to make are
> to bring it more inline with other os projects, in
At 14.57 31/10/2003, Hani Suleiman wrote:
Would anyone mind terribly if I had shuffled things around in ww 1.3?
The directory structure is annoying, the changes I'd like to make are to
bring it more inline with other os projects, including:
top level build.xml
Moving all lib jars into one of lib
Hani Suleiman <[EMAIL PROTECTED]> wrote ..
> Would anyone mind terribly if I had shuffled things around in ww 1.3?
>
> The directory structure is annoying, the changes I'd like to make are
> to bring it more inline with other os projects, including:
>
> top level build.xml
> Moving all lib jars
That sounds great, please go ahead!
While you're at it, please consider fixing so the build.xml file will be included in
release builds (and working of course).
Best regards,
Dick Zetterberg
[EMAIL PROTECTED]
- Original Message -
From: "Hani Suleiman" <[EMAIL PROTECTED]>
To: <[EMAIL PR
Would anyone mind terribly if I had shuffled things around in ww 1.3?
The directory structure is annoying, the changes I'd like to make are
to bring it more inline with other os projects, including:
top level build.xml
Moving all lib jars into one of lib/core, lib/optional, or lib/build
Moving t
27 matches
Mail list logo
