Scott Smith
Technical Specialist II
TSG HLIS E-Commerce Solution Delivery
Washington Mutual Bank
17901 Von Karman, 5th floor 7124MICA
Irvine, CA 92614
Phone: 949-838-1418
When we put together a simple form that has two text input controls,
WebWork would receive our input values but not render
Smith, Scott wrote:
Scott Smith
Technical Specialist II
TSG HLIS E-Commerce Solution Delivery
Washington Mutual Bank
17901 Von Karman, 5th floor 7124MICA
Irvine, CA 92614
Phone: 949-838-1418
When we put together a simple form that has two text input controls,
WebWork would receive our input
Title: Message
Hi
All,
I just updated a
the webstartable versions of the xwork editor. It fixes the two problems
that have been found until now:
1) Adding a
parameter to an interceptor did not work.
2) You could not
enter the class name of a new interceptor.
Jon...
PS - If any one
has
Title: Message
That
sounds useful.. also, I don't know if you pick up the default parameter name for
each of the result types... this is a static constant field in each result class
(optional) which lets the framework know what name it should give unnamed
params.
i.e.
result
Greetings all,
I've recently met some problems with running Webwork on SunONE Application
Server 7. It was working fine on Resin and OrionServer, thus I suspected
something was wrong with my configuration of SunONE.
First I traced it to a NPE in
com.opensymphony.webwork.dispatcher.VelocityResult
Bernard Choi wrote:
This solved the problem, as webwork was now working fine. However,
understandably, granting all permissions is not acceptable in the final
system.
Why not?
/Rickard
---
This sf.net email is sponsored by:ThinkGeek
Welcome
I'm not sure why it would fail there... The setLocation() method is
public on a public class... Did it give you any access exceptions the
first time?
-Original Message-
From: Bernard Choi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 1:39 PM
To: [EMAIL PROTECTED]
Title: Message
Thanks for pointing out the default parameter name
for the result types... The editor definately doesn't handle this right
now... I'll have to see if I can come up with a way to work with that,
otherwise I might have to preprocess (transform)the xwork.xml file insert
the
I am not sure about WW2, but for WW1 you have to have some permissions for
the reflection and property editors to work.
There is a Wiki note here:
http://wiki.opensymphony.com/space/Running+WebWork+on+SunONE
According to it you should set the following permissions to make it work:
- Give Write
Is there any reason that this wasn't called webwork2, instead of webwork?
It is quite confusing to have two webwork directories checked out of CVS,
containing completely different CVS trees.
Scott
---
This sf.net email is sponsored
Title: Re: [OS-webwork] New version of XWork editor posted
Jon,
The view backwards references do sound useful (what action+result combinations point to this view) - .vm or .jsp :)
Another thing that might be useful is preview XML which shows you the actual XML that will be generated? People
Look at the message from Dick Z. especially this part:
- Give Write Permissions to java.util.PropertyPermission.
I think that should do it.
-Original Message-
From: Bernard Choi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 9:46 PM
To: [EMAIL PROTECTED]
Subject: Re:
From: Rickard Öberg [EMAIL PROTECTED]
Bernard Choi wrote:
This solved the problem, as webwork was now working fine. However,
understandably, granting all permissions is not acceptable in the final
system.
Why not?
In this particular, our application which uses webwork resides in an
Title: Re: [OS-webwork] New version of XWork editor posted
Greetings,
Along the same lines, perhaps we can make this
"reference view" more generic.Conceptually, the result view is just
another component in the chain. The chain might consist of several actions. In
which case it might be
14 matches
Mail list logo
