Parameters and chaining (was: Re: RE-2: cvs commit:jakarta-struts/src/share/org/apache/struts/acti on Action.javaActionForm.java)
Actually, one of the reasons I elected to use a separate form bean was
actually to avoid one of the issues (for me, anyway) that a parameter stack
would raise.
When a request is chained using a forward, the set of parameters presented
to the second action is the union of those supplied in the first and second
requests. What bothers me most about that is the dependency introduced
between the two actions and their parameters.
For example, if the second action behaves differently depending on the
presence or absence of a particular parameter, then it would be very
important to know if that same parameter name was ever used by the first
action. Even if the parameter was not specified for the forward itself, if
it was present in the request for the first action, it will be present in
the request for the second action.
Hence I decided to avoid even looking at the request parameters when an
action is chained to. True, my second action has to know to look for a
separate bean, but at least I know what I'm passing and receiving.
It would be nice if there was some Struts mechanism so that I could tell
Struts "please pass this form bean directly to the target action instead of
resetting one and populating it from request parameters". Then my target
action wouldn't need to be aware that it was the target of the chain, or
that the form bean was hand-crafted.
One way would be for Struts to do part of what I'm doing behind the scenes.
That is, I could call a Struts method like setForwardFormBean() to set up
the bean, and Struts could store it in the request under a well-known
attribute name. Then, before resetting and populating a form bean as usual,
Struts would look for a form bean under that same attribute name and, if it
was present, pass that to perform() instead creating/resetting and
populating as usual.
Thoughts, anyone?
--
Martin Cooper
- Original Message -
From: "William Shulman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 11, 2001 2:47 PM
Subject: RE: RE-2: cvs commit:
jakarta-struts/src/share/org/apache/struts/acti on Action.java
ActionForm.java
>
> Sounds like another good solution might be to implement a parameter
> stack in the request object. The parameter stack is a stack of
> Dictionary objects. When parameters are introduced, they are placed
> in the Dictionary on the top of the stack. Similarly for lookup. Stack
> frames (i.e. the Dictionaries) are pushed and popped appropriately as
> you chain.
>
> Just a thought. There may be some details to work out, but the
> solution would be very general and useful in many places.
>
> -will
>
> Martin Cooper writes:
> > As far as I am aware, you cannot add parameters to the request.
> >
> > I think storing values as request attributes and then looking there for
> > parameter values would be very dangerous. You could potentially break
> > existing code that uses request attributes to store data for chaining
actions.
> >
> > Incidentally, Hal, I faced a similar problem in chaining actions. What
I
> > did was to instantiate a separate form bean and store the chaining
> > parameters in that, then use one well-known (between our Actions, I
mean)
> > request attribute to store that bean. The chained-to action checks for
that
> > bean first, otherwise it uses the one Struts passed to the perform()
method.
> >
> > --
> > Martin Cooper
> >
> >
> > At 12:38 PM 5/11/01, Deadman, Hal wrote:
> > >I thought of that too but I don't know how to add parameters to the
request.
> > >Maybe you could use request.setAttribute and store the multi-part
request
> > >String parameters as attributes in the requet object. Then code that
looks
> > >for parameters could be changed to a method that looks for parameters
or
> > >attributes. I don't know if that would help matters much.
> > >
> > >I use something similar in my application so that I can have an action
that
> > >is accessed from a link or from another action. In one case the
paramters
> > >are passed on the url and in the other case parameters are passed as
request
> > >attributes. The receiving action calls a method that checks for one
and then
> > >the other, using the first one it finds.
> > >
> > > protected String findStringParameter(HttpServletRequest request,
String
> > >key)
> > > {
> > > String value = request.getParameter(key);
> > > if (value == null)
> > > {
> > > value = (String) request.getAttribute(key);
> > > }
> > > return value;
> > > }
> > >
> > > > -Original Message-
> > > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
[mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, May 11, 2001 2:19 PM
> > > > To: '[EMAIL PROTECTED]'
> > > > Subject: RE-2: cvs commit:
> > > > jakarta-struts/src/share/org/apache/struts/acti on Action.java
> > > > ActionForm.java
> > > >
> > > >
> > > > On second thought, I'm going to toy around with putting the request
> > > > parameters
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/utilRequestUtils.java
On Fri, 11 May 2001, Martin Cooper wrote:
> At 03:44 PM 5/11/01, Craig R. McClanahan wrote:
>
>
> >On 11 May 2001 [EMAIL PROTECTED] wrote:
> >
> > > mschachter01/05/11 15:33:38
> > >
> > > Modified:src/share/org/apache/struts/action Action.java
> > > ActionServlet.java
> > >src/share/org/apache/struts/upload
> > > DiskMultipartRequestHandler.java
> > >src/share/org/apache/struts/util RequestUtils.java
> > > Added: src/share/org/apache/struts/upload
> > > MultipartRequestWrapper.java
> > > Log:
> > >- Added the MultipartRequestWrapper class, which is a class that
> > implements
> > > HttpServletRequest and wraps a normal request. All normal
> > HttpServletRequest
> > > methods will be called to the underlying request, except for
> > methods involving
> > > parameters, which were over-ridden to provide a transparent way of
> > accessing
> > > multipart elements. The version of the HttpServletRequest is
> > Servlet 2.2, however
> > > the new methods from Servlet 2.3 are also included in this class
> > with empty
> > > implementations so that Struts will build against the servlet 2.2
> > and 2.3 jars
> >
> >One thing to remember in 2.2 is that you cannot pass your wrapped request
> >object to a RequestDispatcher.forward() or RequestDispatcher.include()
> >call. In Tomcat 3.x, for example, you'd get a ClassCastException error if
> >you tried to use this in an RD call.
>
> You mean if I have an Action that is invoked via POST with a file upload,
> and I try to forward from there using mapping.findForward("nextAction"),
> where the forward has redirect="false, this will fail? This would be very
> bad - in every case where we have a file upload, we subsequently forward to
> another action.
>
As long as you forward the *original* request object (and not the
wrapper), you're fine. I'm fighting some security fires on Tomcat so I
haven't had time to look deeply into what Michael is changing, but wanted
to raise the flag in case some assumptions about this were being made
incorrectly.
> >Craig
>
> --
> Martin Cooper
>
>
>
Craig
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/utilRequestUtils.java
At 03:44 PM 5/11/01, Craig R. McClanahan wrote:
>On 11 May 2001 [EMAIL PROTECTED] wrote:
>
> > mschachter01/05/11 15:33:38
> >
> > Modified:src/share/org/apache/struts/action Action.java
> > ActionServlet.java
> >src/share/org/apache/struts/upload
> > DiskMultipartRequestHandler.java
> >src/share/org/apache/struts/util RequestUtils.java
> > Added: src/share/org/apache/struts/upload
> > MultipartRequestWrapper.java
> > Log:
> >- Added the MultipartRequestWrapper class, which is a class that
> implements
> > HttpServletRequest and wraps a normal request. All normal
> HttpServletRequest
> > methods will be called to the underlying request, except for
> methods involving
> > parameters, which were over-ridden to provide a transparent way of
> accessing
> > multipart elements. The version of the HttpServletRequest is
> Servlet 2.2, however
> > the new methods from Servlet 2.3 are also included in this class
> with empty
> > implementations so that Struts will build against the servlet 2.2
> and 2.3 jars
>
>One thing to remember in 2.2 is that you cannot pass your wrapped request
>object to a RequestDispatcher.forward() or RequestDispatcher.include()
>call. In Tomcat 3.x, for example, you'd get a ClassCastException error if
>you tried to use this in an RD call.
You mean if I have an Action that is invoked via POST with a file upload,
and I try to forward from there using mapping.findForward("nextAction"),
where the forward has redirect="false, this will fail? This would be very
bad - in every case where we have a file upload, we subsequently forward to
another action.
>Craig
--
Martin Cooper
Re: I'm back!
Hi, Craig, We are developing an application in-house with Struts and have built a rudimentary Workflow. Myself and another coworker would definitely like to be involved with the Workflow effort. Please put us down on the mailing list: [EMAIL PROTECTED] [EMAIL PROTECTED] Charles Craig Tataryn wrote: > Hi guys, I haven't been participating lately in the mailing list because > I recently moved from the US back to Canada so I haven't had too much > spare time. Any how, now that I am settled in I would like to start > work on the Struts Workflow TODO. I was wondering if anyone other than > my self and Nic would be interested in participating? > > Also, my webserver was down the other day. The owner had to do some > maintenance. It's back up, and actually instead of using the old us-eh > address to get to my struts tutorial you can get to it via: > > http://www.computer-programmer.org/articles/struts/ > > Ted, can you update your web page to point to the new > computer-programmer address? > > Thanks, > > > >
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/utilRequestUtils.java
On 11 May 2001 [EMAIL PROTECTED] wrote: > mschachter01/05/11 15:33:38 > > Modified:src/share/org/apache/struts/action Action.java > ActionServlet.java >src/share/org/apache/struts/upload > DiskMultipartRequestHandler.java >src/share/org/apache/struts/util RequestUtils.java > Added: src/share/org/apache/struts/upload > MultipartRequestWrapper.java > Log: >- Added the MultipartRequestWrapper class, which is a class that implements > HttpServletRequest and wraps a normal request. All normal HttpServletRequest > methods will be called to the underlying request, except for methods involving > parameters, which were over-ridden to provide a transparent way of accessing > multipart elements. The version of the HttpServletRequest is Servlet 2.2, >however > the new methods from Servlet 2.3 are also included in this class with empty > implementations so that Struts will build against the servlet 2.2 and 2.3 jars One thing to remember in 2.2 is that you cannot pass your wrapped request object to a RequestDispatcher.forward() or RequestDispatcher.include() call. In Tomcat 3.x, for example, you'd get a ClassCastException error if you tried to use this in an RD call. Craig
cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
mschachter01/05/11 15:33:38
Modified:src/share/org/apache/struts/action Action.java
ActionServlet.java
src/share/org/apache/struts/upload
DiskMultipartRequestHandler.java
src/share/org/apache/struts/util RequestUtils.java
Added: src/share/org/apache/struts/upload
MultipartRequestWrapper.java
Log:
- Added the MultipartRequestWrapper class, which is a class that implements
HttpServletRequest and wraps a normal request. All normal HttpServletRequest
methods will be called to the underlying request, except for methods involving
parameters, which were over-ridden to provide a transparent way of accessing
multipart elements. The version of the HttpServletRequest is Servlet 2.2, however
the new methods from Servlet 2.3 are also included in this class with empty
implementations so that Struts will build against the servlet 2.2 and 2.3 jars
- Removed the isCancelled(MultipartRequestHandler) method from Action, in favor
of isCancelled(HttpServletRequest), which now works for multipart requests
- The process() method of ActionServlet now determines whether or not the current
request is a multipart request, and if it is, wraps it in the new
MultipartRequestWrapper class temporarily, and right before the ActionForward
is processed, reverts the request back to the original one
- Modified DiskMultipartRequestHandler to populate the request with multipart
data if it's passed a request of type MultipartRequestWrapper
- Modified RequestUtils to check to make sure the method of the request is
"POST" before processing a multipart request (Submitted by Martin Cooper). It
does
this in RequestUtils as well as ActionServlet when it checks for multipart
requests
This change has been tested against all the webapps included with Struts,
and doesn't seem to cause any issues. Command tokens and cancel buttons
should now work fine for multipart requests without any modifications
Revision ChangesPath
1.21 +5 -27 jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- Action.java 2001/05/11 17:10:55 1.20
+++ Action.java 2001/05/11 22:33:31 1.21
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v 1.20
2001/05/11 17:10:55 mschachter Exp $
- * $Revision: 1.20 $
- * $Date: 2001/05/11 17:10:55 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v 1.21
2001/05/11 22:33:31 mschachter Exp $
+ * $Revision: 1.21 $
+ * $Date: 2001/05/11 22:33:31 $
*
*
*
@@ -108,7 +108,7 @@
* by this Action.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
+ * @version $Revision: 1.21 $ $Date: 2001/05/11 22:33:31 $
*/
public class Action {
@@ -423,7 +423,7 @@
}
}
-
+
/**
* Return the user's currently selected Locale.
@@ -470,28 +470,6 @@
}
-/**
- * Returns true if the current multipart form's cancel button was
- * pressed. This method will check if the cancel button generated by
- * CancelTag was pressed by the user in the
- * current request. If true, validation performed by an
- * ActionForm validate() method will have been
- * skipped by the controller servlet. A MultipartRequestHandler instance
- * can be obtained from a multipart form by calling
- * {@link ActionForm#getMultipartRequestHandler()
ActionForm.getMultipartRequestHandler()}.
- *
- * @param request The servlet request we are processing
- * @see org.apache.struts.taglib.CancelTag
- * @see org.apache.struts.action.ValidatingActionForm
- */
-protected boolean isCancelled(MultipartRequestHandler request) {
-
-Hashtable elements = request.getTextElements();
-return ((elements.get(Constants.CANCEL_PROPERTY) != null) ||
-(elements.get(Constants.CANCEL_PROPERTY_X) != null));
-}
-
-
/**
* Return true if there is a transaction token stored in
* the user's current session, and the value submitted as a request
1.68 +23 -5
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
Index: ActionServlet.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Acti
RE: RE-2: cvs commit:jakarta-struts/src/share/org/apache/struts/acti on Action.javaActionForm.java
Sounds like another good solution might be to implement a parameter
stack in the request object. The parameter stack is a stack of
Dictionary objects. When parameters are introduced, they are placed
in the Dictionary on the top of the stack. Similarly for lookup. Stack
frames (i.e. the Dictionaries) are pushed and popped appropriately as
you chain.
Just a thought. There may be some details to work out, but the
solution would be very general and useful in many places.
-will
Martin Cooper writes:
> As far as I am aware, you cannot add parameters to the request.
>
> I think storing values as request attributes and then looking there for
> parameter values would be very dangerous. You could potentially break
> existing code that uses request attributes to store data for chaining actions.
>
> Incidentally, Hal, I faced a similar problem in chaining actions. What I
> did was to instantiate a separate form bean and store the chaining
> parameters in that, then use one well-known (between our Actions, I mean)
> request attribute to store that bean. The chained-to action checks for that
> bean first, otherwise it uses the one Struts passed to the perform() method.
>
> --
> Martin Cooper
>
>
> At 12:38 PM 5/11/01, Deadman, Hal wrote:
> >I thought of that too but I don't know how to add parameters to the request.
> >Maybe you could use request.setAttribute and store the multi-part request
> >String parameters as attributes in the requet object. Then code that looks
> >for parameters could be changed to a method that looks for parameters or
> >attributes. I don't know if that would help matters much.
> >
> >I use something similar in my application so that I can have an action that
> >is accessed from a link or from another action. In one case the paramters
> >are passed on the url and in the other case parameters are passed as request
> >attributes. The receiving action calls a method that checks for one and then
> >the other, using the first one it finds.
> >
> > protected String findStringParameter(HttpServletRequest request, String
> >key)
> > {
> > String value = request.getParameter(key);
> > if (value == null)
> > {
> > value = (String) request.getAttribute(key);
> > }
> > return value;
> > }
> >
> > > -Original Message-
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 2:19 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE-2: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/acti on Action.java
> > > ActionForm.java
> > >
> > >
> > > On second thought, I'm going to toy around with putting the request
> > > parameters
> > > directly into the request from MultipartRequestHandler
> > > instead of using
> > > MultipartRequestHandler itself to store attributes. If I can
> > > get it to work
> > > this will solve all
> > > the problems without adding any new methods to anything, or changing
> > > anything.
> > >
> > > -Original Message-
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> > > Sent: Friday, May 11, 2001 2:08 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > >
> > >
> > > Is this an acceptable resolution to this problem for
> > > everybody? If so, I'll
> > > go ahead and fix the token problem in the Action class, be
> > > creating new
> > > isTokenValid() method that takes an HttpServletRequest and a
> > > MultipartRequestHandler
> > > as arguments, when using it for multipart forms. The other
> > > token methods
> > > don't
> > > need to be changed, as they only deal with retrieiving
> > > session information.
> > >
> > > -Original Message-
> > > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 1:29 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > >
> > >
> > > Hal,
> > >
> > > It was my understanding that since isCancelled is a protected
> > > method in the
> > > Action class,
> > > that it was the Action developer's job to call the method.
> > >
> > > -Original Message-
> > > From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 1:24 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: cvs commit:
> > > jakarta-struts/src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > >
> > >
> > > Doesn't the Struts framework need to call this new method
> > > somewhere? The
> > > application code can't call the isCancelled method because
> > > the Action class
> > > code will never be called. If Struts ActionServlet calls the
> > > form validate
> > > when a user clicked cancel, the validation will likely fail
RE: RE-2: cvs commit:jakarta-struts/src/share/org/apache/struts/acti on Action.javaActionForm.java
As far as I am aware, you cannot add parameters to the request.
I think storing values as request attributes and then looking there for
parameter values would be very dangerous. You could potentially break
existing code that uses request attributes to store data for chaining actions.
Incidentally, Hal, I faced a similar problem in chaining actions. What I
did was to instantiate a separate form bean and store the chaining
parameters in that, then use one well-known (between our Actions, I mean)
request attribute to store that bean. The chained-to action checks for that
bean first, otherwise it uses the one Struts passed to the perform() method.
--
Martin Cooper
At 12:38 PM 5/11/01, Deadman, Hal wrote:
>I thought of that too but I don't know how to add parameters to the request.
>Maybe you could use request.setAttribute and store the multi-part request
>String parameters as attributes in the requet object. Then code that looks
>for parameters could be changed to a method that looks for parameters or
>attributes. I don't know if that would help matters much.
>
>I use something similar in my application so that I can have an action that
>is accessed from a link or from another action. In one case the paramters
>are passed on the url and in the other case parameters are passed as request
>attributes. The receiving action calls a method that checks for one and then
>the other, using the first one it finds.
>
> protected String findStringParameter(HttpServletRequest request, String
>key)
> {
> String value = request.getParameter(key);
> if (value == null)
> {
> value = (String) request.getAttribute(key);
> }
> return value;
> }
>
> > -Original Message-
> > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 11, 2001 2:19 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE-2: cvs commit:
> > jakarta-struts/src/share/org/apache/struts/acti on Action.java
> > ActionForm.java
> >
> >
> > On second thought, I'm going to toy around with putting the request
> > parameters
> > directly into the request from MultipartRequestHandler
> > instead of using
> > MultipartRequestHandler itself to store attributes. If I can
> > get it to work
> > this will solve all
> > the problems without adding any new methods to anything, or changing
> > anything.
> >
> > -Original Message-
> > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> > Sent: Friday, May 11, 2001 2:08 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: cvs commit:
> > jakarta-struts/src/share/org/apache/struts/action Action.java
> > ActionForm.java
> >
> >
> > Is this an acceptable resolution to this problem for
> > everybody? If so, I'll
> > go ahead and fix the token problem in the Action class, be
> > creating new
> > isTokenValid() method that takes an HttpServletRequest and a
> > MultipartRequestHandler
> > as arguments, when using it for multipart forms. The other
> > token methods
> > don't
> > need to be changed, as they only deal with retrieiving
> > session information.
> >
> > -Original Message-
> > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 11, 2001 1:29 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: cvs commit:
> > jakarta-struts/src/share/org/apache/struts/action Action.java
> > ActionForm.java
> >
> >
> > Hal,
> >
> > It was my understanding that since isCancelled is a protected
> > method in the
> > Action class,
> > that it was the Action developer's job to call the method.
> >
> > -Original Message-
> > From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 11, 2001 1:24 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: cvs commit:
> > jakarta-struts/src/share/org/apache/struts/action Action.java
> > ActionForm.java
> >
> >
> > Doesn't the Struts framework need to call this new method
> > somewhere? The
> > application code can't call the isCancelled method because
> > the Action class
> > code will never be called. If Struts ActionServlet calls the
> > form validate
> > when a user clicked cancel, the validation will likely fail
> > and the user
> > will be presented with the input form again. Clicking cancel
> > needs to bypass
> > the call to the form validate method. If that is done then the new
> > isCancelled method may be used in the perform method.
> >
> > Hal
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 11, 2001 1:11 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: cvs commit:
> > jakarta-struts/src/share/org/apache/struts/action
> > > Action.java ActionForm.java
> > >
> > >
> > > mschachter01/05/11 10:11:06
> > >
> > > Modified:doc todo-1.1.xml
> > >src/share/org/apache/struts/action Action.java
> > > ActionForm.java
> > > Log:
> > >- Add an isCancelled() method to the Action class that takes a
> > > MultipartRequ
RE: RE-2: cvs commit: jakarta-struts/src/share/org/apache/struts/acti on Action.java ActionForm.java
What I'm doing is creating a MultipartRequestWrapper class, very similar to
what
HttpServletRequestWrapper does in the Servlet 2.3 API, and setting the
request to
that wrapper instead. That way, I can handle the getParameter() method
calls on the
request myself for multipart requests, and set parameters at will. Once
Struts requires
that Servlet 2.3 is used, I'll extend the HttpServletRequestWrapper instead
of implementing
the HttpServletRequest interface.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 3:39 PM
To: [EMAIL PROTECTED]
Subject: RE: RE-2: cvs commit:
jakarta-struts/src/share/org/apache/struts/acti on Action.java
ActionForm.java
I thought of that too but I don't know how to add parameters to the request.
Maybe you could use request.setAttribute and store the multi-part request
String parameters as attributes in the requet object. Then code that looks
for parameters could be changed to a method that looks for parameters or
attributes. I don't know if that would help matters much.
I use something similar in my application so that I can have an action that
is accessed from a link or from another action. In one case the paramters
are passed on the url and in the other case parameters are passed as request
attributes. The receiving action calls a method that checks for one and then
the other, using the first one it finds.
protected String findStringParameter(HttpServletRequest request, String
key)
{
String value = request.getParameter(key);
if (value == null)
{
value = (String) request.getAttribute(key);
}
return value;
}
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 2:19 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE-2: cvs commit:
> jakarta-struts/src/share/org/apache/struts/acti on Action.java
> ActionForm.java
>
>
> On second thought, I'm going to toy around with putting the request
> parameters
> directly into the request from MultipartRequestHandler
> instead of using
> MultipartRequestHandler itself to store attributes. If I can
> get it to work
> this will solve all
> the problems without adding any new methods to anything, or changing
> anything.
>
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> Sent: Friday, May 11, 2001 2:08 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Is this an acceptable resolution to this problem for
> everybody? If so, I'll
> go ahead and fix the token problem in the Action class, be
> creating new
> isTokenValid() method that takes an HttpServletRequest and a
> MultipartRequestHandler
> as arguments, when using it for multipart forms. The other
> token methods
> don't
> need to be changed, as they only deal with retrieiving
> session information.
>
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:29 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Hal,
>
> It was my understanding that since isCancelled is a protected
> method in the
> Action class,
> that it was the Action developer's job to call the method.
>
> -Original Message-
> From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:24 PM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Doesn't the Struts framework need to call this new method
> somewhere? The
> application code can't call the isCancelled method because
> the Action class
> code will never be called. If Struts ActionServlet calls the
> form validate
> when a user clicked cancel, the validation will likely fail
> and the user
> will be presented with the input form again. Clicking cancel
> needs to bypass
> the call to the form validate method. If that is done then the new
> isCancelled method may be used in the perform method.
>
> Hal
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 11, 2001 1:11 PM
> > To: [EMAIL PROTECTED]
> > Subject: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action
> > Action.java ActionForm.java
> >
> >
> > mschachter01/05/11 10:11:06
> >
> > Modified:doc todo-1.1.xml
> >src/share/org/apache/struts/action Action.java
> > ActionForm.java
> > Log:
> >- Add an isCancelled() method to the Action class that takes a
> > MultipartRequestHandler as an argument. This should address
> > issues with the html:cancel tag, as long as the new isCancelled
> > method is called on for multipart forms.
> >- Add myself to the EJB Design Pattern TODO
> >
> > Revision
RE: RE-2: cvs commit: jakarta-struts/src/share/org/apache/struts/acti on Action.java ActionForm.java
I thought of that too but I don't know how to add parameters to the request.
Maybe you could use request.setAttribute and store the multi-part request
String parameters as attributes in the requet object. Then code that looks
for parameters could be changed to a method that looks for parameters or
attributes. I don't know if that would help matters much.
I use something similar in my application so that I can have an action that
is accessed from a link or from another action. In one case the paramters
are passed on the url and in the other case parameters are passed as request
attributes. The receiving action calls a method that checks for one and then
the other, using the first one it finds.
protected String findStringParameter(HttpServletRequest request, String
key)
{
String value = request.getParameter(key);
if (value == null)
{
value = (String) request.getAttribute(key);
}
return value;
}
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 2:19 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE-2: cvs commit:
> jakarta-struts/src/share/org/apache/struts/acti on Action.java
> ActionForm.java
>
>
> On second thought, I'm going to toy around with putting the request
> parameters
> directly into the request from MultipartRequestHandler
> instead of using
> MultipartRequestHandler itself to store attributes. If I can
> get it to work
> this will solve all
> the problems without adding any new methods to anything, or changing
> anything.
>
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
> Sent: Friday, May 11, 2001 2:08 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Is this an acceptable resolution to this problem for
> everybody? If so, I'll
> go ahead and fix the token problem in the Action class, be
> creating new
> isTokenValid() method that takes an HttpServletRequest and a
> MultipartRequestHandler
> as arguments, when using it for multipart forms. The other
> token methods
> don't
> need to be changed, as they only deal with retrieiving
> session information.
>
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:29 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Hal,
>
> It was my understanding that since isCancelled is a protected
> method in the
> Action class,
> that it was the Action developer's job to call the method.
>
> -Original Message-
> From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:24 PM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Doesn't the Struts framework need to call this new method
> somewhere? The
> application code can't call the isCancelled method because
> the Action class
> code will never be called. If Struts ActionServlet calls the
> form validate
> when a user clicked cancel, the validation will likely fail
> and the user
> will be presented with the input form again. Clicking cancel
> needs to bypass
> the call to the form validate method. If that is done then the new
> isCancelled method may be used in the perform method.
>
> Hal
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 11, 2001 1:11 PM
> > To: [EMAIL PROTECTED]
> > Subject: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action
> > Action.java ActionForm.java
> >
> >
> > mschachter01/05/11 10:11:06
> >
> > Modified:doc todo-1.1.xml
> >src/share/org/apache/struts/action Action.java
> > ActionForm.java
> > Log:
> >- Add an isCancelled() method to the Action class that takes a
> > MultipartRequestHandler as an argument. This should address
> > issues with the html:cancel tag, as long as the new isCancelled
> > method is called on for multipart forms.
> >- Add myself to the EJB Design Pattern TODO
> >
> > Revision ChangesPath
> > 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
> >
> > Index: todo-1.1.xml
> >
> ===
> > RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- todo-1.1.xml 2001/04/12 16:00:42 1.2
> > +++ todo-1.1.xml 2001/05/11 17:10:47 1.3
> > @@ -159,6 +159,9 @@
> >
> >mailto:[EMAIL PROTECTED]";>Nic Hobbs
> >
> > +
> > +mailto:[EMAIL PROTECTED]";>Mike Schachter
> > +
> >
> >
> >
> >
> >
> >
> > 1.20 +27 -4
> > jakarta-struts/src
RE: Re[2]: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)
We actually now have gone for a similar approach. We have defined a Mapper class that encapsulate Mappings and MappedObjects, each Mapping being a relationship between one or more MappedObjects and containing the name of the fields to "import/export". We also created the notion of Converters, meaning that each individual Mapping can use its own Converter. If there is a conversion problem, the Mapper call the ConvertExceptionHandler which has been provided during its initialization. This handler can easily create ActionError. Initialization of Mappers will be done by an XML config file, using the digester. Also each MappedObject can define its own Getter and Setter classes, allowing us to not only support JavaBeans, but also query strings, query and result buffers, etc. This mapper functionality will be used at different stages: during the validation of a form (ActionForm.validate()), during the parsing/handling of backend result messages, and whenever we need to transfer data from one object to another. It will include other features such as object creation during the mapping, internationalization, the possibility to use mappers within a mapper in order to process tree structures. I think Struts would benefit a lot of such addition. Form validation is on the to do list for Struts 1.1, but I'm not sure if anybody has done some work in this area already... Whoever is working on this should really consider the fact that validating user input is not just about parsing text but also about creating the corresponding objects. Therefore it would be great if the Struts validation feature allows you to do this as well. Otherwise the risk is that the validation is done twice: a first time when validating the form attributes, and a second time when creating objects. I strongly recommend to envision validation and object creation in one single framework. François Rey Financial WebSuite Capco http://www.capco.com/ -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: 07 May 2001 23:31 To: Rey Francois Subject: Re[2]: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.) Hello Rey, Some time ago I implement similar mechanism to support validation at string2object conversion phase. - BaseActionForm - class extended from ActionForm and contains base logic to support string2object conversion with i18n support with to special methods - import() and export() - public void import( Object entity, HttpServletRequest request, ActionErrors errors ) throws ServletException this method takes entity and converts it's properties from objects to string values with i18n support. All handled errors are in errors container after the conversion process. - public Object export( EntityBean entity, HttpServletRequest request, ActionErrors errors ) throws ServletException this method takes string properties from current form and converts its to the target types with i18n support. All successfully converted values will be written to the object and all handled errors will be written to the errors container. - each form extends BaseActionForm and implements its own versions of export() and import() methods to support it's own version of string2object conversion - import() method will be called at init form process and export() method will called at start of perform method in Action class to init data object from string values collected from the form. - such approach let me to concern all conversion logic in two methods and avoid init of conversion utilites at every setXXX/getXXX call. Monday, May 07, 2001, 5:18:06 PM, you wrote: RF> It has been a while since David replied to my post, but it's only now that I RF> get a chance to work on this aspect in our case. I have been giving this RF> further thoughts and have chosen an approach which I'm now starting to RF> implement: RF> - The ActionForm will be derived into a base class which will contain two RF> lists: the list of errors (ActionErrors instance) and a list of property RF> objects RF> - The property object is encapsulating the name of the property, the string RF> value, the object value, each of them having get/set methods. RF> - The ActionForm implements protected generic get/set methods for string and RF> object values. String get/set methods are used by the plain getXXX/setXXX of RF> the form, while the generic get/set methods for object values are used RF> externally, by whatever logic needs to get object values out of the form. RF> When setting the string value, the corresponding object value is set as well RF> using the provided format class, and vice-versa. RF> - The action form contains helper methods for adding and getting errors. RF> This is particularly useful when a (backend) validation is also performed in RF> the Action: it can now add errors to the form and forward to the i
RE-2: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
On second thought, I'm going to toy around with putting the request parameters directly into the request from MultipartRequestHandler instead of using MultipartRequestHandler itself to store attributes. If I can get it to work this will solve all the problems without adding any new methods to anything, or changing anything. -Original Message- From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) Sent: Friday, May 11, 2001 2:08 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java Is this an acceptable resolution to this problem for everybody? If so, I'll go ahead and fix the token problem in the Action class, be creating new isTokenValid() method that takes an HttpServletRequest and a MultipartRequestHandler as arguments, when using it for multipart forms. The other token methods don't need to be changed, as they only deal with retrieiving session information. -Original Message- From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:29 PM To: '[EMAIL PROTECTED]' Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java Hal, It was my understanding that since isCancelled is a protected method in the Action class, that it was the Action developer's job to call the method. -Original Message- From: Deadman, Hal [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 1:24 PM To: [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java Doesn't the Struts framework need to call this new method somewhere? The application code can't call the isCancelled method because the Action class code will never be called. If Struts ActionServlet calls the form validate when a user clicked cancel, the validation will likely fail and the user will be presented with the input form again. Clicking cancel needs to bypass the call to the form validate method. If that is done then the new isCancelled method may be used in the perform method. Hal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 11, 2001 1:11 PM > To: [EMAIL PROTECTED] > Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action > Action.java ActionForm.java > > > mschachter01/05/11 10:11:06 > > Modified:doc todo-1.1.xml >src/share/org/apache/struts/action Action.java > ActionForm.java > Log: >- Add an isCancelled() method to the Action class that takes a > MultipartRequestHandler as an argument. This should address > issues with the html:cancel tag, as long as the new isCancelled > method is called on for multipart forms. >- Add myself to the EJB Design Pattern TODO > > Revision ChangesPath > 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml > > Index: todo-1.1.xml > === > RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- todo-1.1.xml2001/04/12 16:00:42 1.2 > +++ todo-1.1.xml2001/05/11 17:10:47 1.3 > @@ -159,6 +159,9 @@ > >mailto:[EMAIL PROTECTED]";>Nic Hobbs > > + > +mailto:[EMAIL PROTECTED]";>Mike Schachter > + > > > > > > > 1.20 +27 -4 > jakarta-struts/src/share/org/apache/struts/action/Action.java > > Index: Action.java > === > RCS file: > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac > tion.java,v > retrieving revision 1.19 > retrieving revision 1.20 > diff -u -r1.19 -r1.20 > --- Action.java 2001/02/23 21:13:09 1.19 > +++ Action.java 2001/05/11 17:10:55 1.20 > @@ -1,7 +1,7 @@ >/* > - * $Header: > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac > tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $ > - * $Revision: 1.19 $ > - * $Date: 2001/02/23 21:13:09 $ > + * $Header: > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac > tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $ > + * $Revision: 1.20 $ > + * $Date: 2001/05/11 17:10:55 $ > * > * > > * > @@ -67,6 +67,7 @@ >import java.security.MessageDigest; >import java.security.NoSuchAlgorithmException; >import java.util.Locale; > +import java.util.Hashtable; >import javax.servlet.ServletException; >import javax.servlet.ServletRequest; >import javax.servlet.ServletResponse; > @@ -75,6 +76,7 @@ >import javax.servlet.http.HttpSession; >import org.apache.struts.taglib.html.Constants; >import org.apache.struts.util.MessageResources; > +import org.apache.struts.upload.Multipart
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
The controller servlet needs to correctly recognize a cancelled transaction, even on multi-part input, as Hal points out. The simplest approach is to update the logic in processValidate() that checks for cancellation so that it works in this case as well. Craig On Fri, 11 May 2001, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote: > Is this an acceptable resolution to this problem for everybody? If so, I'll > go ahead and fix the token problem in the Action class, be creating new > isTokenValid() method that takes an HttpServletRequest and a > MultipartRequestHandler > as arguments, when using it for multipart forms. The other token methods > don't > need to be changed, as they only deal with retrieiving session information. > > -Original Message- > From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 11, 2001 1:29 PM > To: '[EMAIL PROTECTED]' > Subject: RE: cvs commit: > jakarta-struts/src/share/org/apache/struts/action Action.java > ActionForm.java > > > Hal, > > It was my understanding that since isCancelled is a protected method in the > Action class, > that it was the Action developer's job to call the method. > > -Original Message- > From: Deadman, Hal [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 11, 2001 1:24 PM > To: [EMAIL PROTECTED] > Subject: RE: cvs commit: > jakarta-struts/src/share/org/apache/struts/action Action.java > ActionForm.java > > > Doesn't the Struts framework need to call this new method somewhere? The > application code can't call the isCancelled method because the Action class > code will never be called. If Struts ActionServlet calls the form validate > when a user clicked cancel, the validation will likely fail and the user > will be presented with the input form again. Clicking cancel needs to bypass > the call to the form validate method. If that is done then the new > isCancelled method may be used in the perform method. > > Hal > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 11, 2001 1:11 PM > > To: [EMAIL PROTECTED] > > Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action > > Action.java ActionForm.java > > > > > > mschachter01/05/11 10:11:06 > > > > Modified:doc todo-1.1.xml > >src/share/org/apache/struts/action Action.java > > ActionForm.java > > Log: > >- Add an isCancelled() method to the Action class that takes a > > MultipartRequestHandler as an argument. This should address > > issues with the html:cancel tag, as long as the new isCancelled > > method is called on for multipart forms. > >- Add myself to the EJB Design Pattern TODO > > > > Revision ChangesPath > > 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml > > > > Index: todo-1.1.xml > > === > > RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v > > retrieving revision 1.2 > > retrieving revision 1.3 > > diff -u -r1.2 -r1.3 > > --- todo-1.1.xml 2001/04/12 16:00:42 1.2 > > +++ todo-1.1.xml 2001/05/11 17:10:47 1.3 > > @@ -159,6 +159,9 @@ > > > >mailto:[EMAIL PROTECTED]";>Nic Hobbs > > > > + > > +mailto:[EMAIL PROTECTED]";>Mike Schachter > > + > > > > > > > > > > > > > > 1.20 +27 -4 > > jakarta-struts/src/share/org/apache/struts/action/Action.java > > > > Index: Action.java > > === > > RCS file: > > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac > > tion.java,v > > retrieving revision 1.19 > > retrieving revision 1.20 > > diff -u -r1.19 -r1.20 > > --- Action.java 2001/02/23 21:13:09 1.19 > > +++ Action.java 2001/05/11 17:10:55 1.20 > > @@ -1,7 +1,7 @@ > >/* > > - * $Header: > > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac > > tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $ > > - * $Revision: 1.19 $ > > - * $Date: 2001/02/23 21:13:09 $ > > + * $Header: > > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac > > tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $ > > + * $Revision: 1.20 $ > > + * $Date: 2001/05/11 17:10:55 $ > > * > > * > > > > * > > @@ -67,6 +67,7 @@ > >import java.security.MessageDigest; > >import java.security.NoSuchAlgorithmException; > >import java.util.Locale; > > +import java.util.Hashtable; > >import javax.servlet.ServletException; > >import javax.servlet.ServletRequest; > >import javax.servlet.ServletResponse; > > @@ -75,6 +76,7 @@ > >import javax.servlet.http.HttpSession; > >import org.apache.struts.taglib.html.Constants; > >import org.apache.struts.util.MessageResources; > > +import org.apache.struts
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
Is this an acceptable resolution to this problem for everybody? If so, I'll
go ahead and fix the token problem in the Action class, be creating new
isTokenValid() method that takes an HttpServletRequest and a
MultipartRequestHandler
as arguments, when using it for multipart forms. The other token methods
don't
need to be changed, as they only deal with retrieiving session information.
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:29 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method somewhere? The
application code can't call the isCancelled method because the Action class
code will never be called. If Struts ActionServlet calls the form validate
when a user clicked cancel, the validation will likely fail and the user
will be presented with the input form again. Clicking cancel needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action
> Action.java ActionForm.java
>
>
> mschachter01/05/11 10:11:06
>
> Modified:doc todo-1.1.xml
>src/share/org/apache/struts/action Action.java
> ActionForm.java
> Log:
>- Add an isCancelled() method to the Action class that takes a
> MultipartRequestHandler as an argument. This should address
> issues with the html:cancel tag, as long as the new isCancelled
> method is called on for multipart forms.
>- Add myself to the EJB Design Pattern TODO
>
> Revision ChangesPath
> 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
>
> Index: todo-1.1.xml
> ===
> RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- todo-1.1.xml2001/04/12 16:00:42 1.2
> +++ todo-1.1.xml2001/05/11 17:10:47 1.3
> @@ -159,6 +159,9 @@
>
>mailto:[EMAIL PROTECTED]";>Nic Hobbs
>
> +
> +mailto:[EMAIL PROTECTED]";>Mike Schachter
> +
>
>
>
>
>
>
> 1.20 +27 -4
> jakarta-struts/src/share/org/apache/struts/action/Action.java
>
> Index: Action.java
> ===
> RCS file:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -u -r1.19 -r1.20
> --- Action.java 2001/02/23 21:13:09 1.19
> +++ Action.java 2001/05/11 17:10:55 1.20
> @@ -1,7 +1,7 @@
>/*
> - * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
> - * $Revision: 1.19 $
> - * $Date: 2001/02/23 21:13:09 $
> + * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
> + * $Revision: 1.20 $
> + * $Date: 2001/05/11 17:10:55 $
> *
> *
>
> *
> @@ -67,6 +67,7 @@
>import java.security.MessageDigest;
>import java.security.NoSuchAlgorithmException;
>import java.util.Locale;
> +import java.util.Hashtable;
>import javax.servlet.ServletException;
>import javax.servlet.ServletRequest;
>import javax.servlet.ServletResponse;
> @@ -75,6 +76,7 @@
>import javax.servlet.http.HttpSession;
>import org.apache.struts.taglib.html.Constants;
>import org.apache.struts.util.MessageResources;
> +import org.apache.struts.upload.MultipartRequestHandler;
>
>
>/**
> @@ -106,7 +108,7 @@
> * by this Action.
> *
> * @author Craig R. McClanahan
> - * @version $Revision: 1.19 $ $Date: 2001/02/23 21:13:09 $
> + * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
> */
>
>public class Action {
> @@ -466,6 +468,27 @@
> return
> ((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
>
> (request.getParameter(Constants.CANCEL_PROPERTY_X) != null));
>
> +}
> +
> +/**
> + * Returns true if the current multipart
> form's cancel button w
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
The developer should call isCancelled() but the check for the cancel tag in
the request also exists in ActionServlet:
protected boolean processValidate(ActionMapping mapping,
ActionForm formInstance, HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Was this submit cancelled?
if ((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
(request.getParameter(Constants.CANCEL_PROPERTY_X) != null)) {
if (debug >= 1)
log(" Cancelled transaction, no validation");
return (true);
}
That check is done in order to avoid calling the validate function on the
form if the cancel button was pressed. The action class perform method is
then called and it is up to the developer to call isCancelled and return the
appropriate forward.
Hal
> -Original Message-
> From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:29 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Hal,
>
> It was my understanding that since isCancelled is a protected
> method in the
> Action class,
> that it was the Action developer's job to call the method.
>
> -Original Message-
> From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:24 PM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action Action.java
> ActionForm.java
>
>
> Doesn't the Struts framework need to call this new method
> somewhere? The
> application code can't call the isCancelled method because
> the Action class
> code will never be called. If Struts ActionServlet calls the
> form validate
> when a user clicked cancel, the validation will likely fail
> and the user
> will be presented with the input form again. Clicking cancel
> needs to bypass
> the call to the form validate method. If that is done then the new
> isCancelled method may be used in the perform method.
>
> Hal
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 11, 2001 1:11 PM
> > To: [EMAIL PROTECTED]
> > Subject: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action
> > Action.java ActionForm.java
> >
> >
> > mschachter01/05/11 10:11:06
> >
> > Modified:doc todo-1.1.xml
> >src/share/org/apache/struts/action Action.java
> > ActionForm.java
> > Log:
> >- Add an isCancelled() method to the Action class that takes a
> > MultipartRequestHandler as an argument. This should address
> > issues with the html:cancel tag, as long as the new isCancelled
> > method is called on for multipart forms.
> >- Add myself to the EJB Design Pattern TODO
> >
> > Revision ChangesPath
> > 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
> >
> > Index: todo-1.1.xml
> >
> ===
> > RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- todo-1.1.xml 2001/04/12 16:00:42 1.2
> > +++ todo-1.1.xml 2001/05/11 17:10:47 1.3
> > @@ -159,6 +159,9 @@
> >
> >mailto:[EMAIL PROTECTED]";>Nic Hobbs
> >
> > +
> > +mailto:[EMAIL PROTECTED]";>Mike Schachter
> > +
> >
> >
> >
> >
> >
> >
> > 1.20 +27 -4
> > jakarta-struts/src/share/org/apache/struts/action/Action.java
> >
> > Index: Action.java
> >
> ===
> > RCS file:
> > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> > tion.java,v
> > retrieving revision 1.19
> > retrieving revision 1.20
> > diff -u -r1.19 -r1.20
> > --- Action.java 2001/02/23 21:13:09 1.19
> > +++ Action.java 2001/05/11 17:10:55 1.20
> > @@ -1,7 +1,7 @@
> >/*
> > - * $Header:
> > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> > tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
> > - * $Revision: 1.19 $
> > - * $Date: 2001/02/23 21:13:09 $
> > + * $Header:
> > /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> > tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
> > + * $Revision: 1.20 $
> > + * $Date: 2001/05/11 17:10:55 $
> > *
> > *
> >
> > *
> > @@ -67,6 +67,7 @@
> >import java.security.MessageDigest;
> >import java.security.NoSuchAlgorithmException;
> >import java.util.Locale;
> > +import java.util.Hashtable;
> >import javax.servlet.ServletException;
> >import javax.servlet.ServletRequest;
> >import javax.servlet.ServletResponse;
> > @@ -75,6 +76,7 @@
> >import javax.
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method somewhere? The
application code can't call the isCancelled method because the Action class
code will never be called. If Struts ActionServlet calls the form validate
when a user clicked cancel, the validation will likely fail and the user
will be presented with the input form again. Clicking cancel needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action
> Action.java ActionForm.java
>
>
> mschachter01/05/11 10:11:06
>
> Modified:doc todo-1.1.xml
>src/share/org/apache/struts/action Action.java
> ActionForm.java
> Log:
>- Add an isCancelled() method to the Action class that takes a
> MultipartRequestHandler as an argument. This should address
> issues with the html:cancel tag, as long as the new isCancelled
> method is called on for multipart forms.
>- Add myself to the EJB Design Pattern TODO
>
> Revision ChangesPath
> 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
>
> Index: todo-1.1.xml
> ===
> RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- todo-1.1.xml2001/04/12 16:00:42 1.2
> +++ todo-1.1.xml2001/05/11 17:10:47 1.3
> @@ -159,6 +159,9 @@
>
>mailto:[EMAIL PROTECTED]";>Nic Hobbs
>
> +
> +mailto:[EMAIL PROTECTED]";>Mike Schachter
> +
>
>
>
>
>
>
> 1.20 +27 -4
> jakarta-struts/src/share/org/apache/struts/action/Action.java
>
> Index: Action.java
> ===
> RCS file:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -u -r1.19 -r1.20
> --- Action.java 2001/02/23 21:13:09 1.19
> +++ Action.java 2001/05/11 17:10:55 1.20
> @@ -1,7 +1,7 @@
>/*
> - * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
> - * $Revision: 1.19 $
> - * $Date: 2001/02/23 21:13:09 $
> + * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
> + * $Revision: 1.20 $
> + * $Date: 2001/05/11 17:10:55 $
> *
> *
>
> *
> @@ -67,6 +67,7 @@
>import java.security.MessageDigest;
>import java.security.NoSuchAlgorithmException;
>import java.util.Locale;
> +import java.util.Hashtable;
>import javax.servlet.ServletException;
>import javax.servlet.ServletRequest;
>import javax.servlet.ServletResponse;
> @@ -75,6 +76,7 @@
>import javax.servlet.http.HttpSession;
>import org.apache.struts.taglib.html.Constants;
>import org.apache.struts.util.MessageResources;
> +import org.apache.struts.upload.MultipartRequestHandler;
>
>
>/**
> @@ -106,7 +108,7 @@
> * by this Action.
> *
> * @author Craig R. McClanahan
> - * @version $Revision: 1.19 $ $Date: 2001/02/23 21:13:09 $
> + * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
> */
>
>public class Action {
> @@ -466,6 +468,27 @@
> return
> ((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
>
> (request.getParameter(Constants.CANCEL_PROPERTY_X) != null));
>
> +}
> +
> +/**
> + * Returns true if the current multipart
> form's cancel button was
> + * pressed. This method will check if the cancel
> button generated by
> + * CancelTag was pressed by the user in the
> + * current request. If true, validation performed by an
> + * ActionForm validate() method will have been
> + * skipped by the controller servlet. A
> MultipartRequestHandler instance
> + * can be obtained from a multipart form by calling
> + * {@link ActionForm#getMultipartRequestHandler()
> ActionForm.getMultipartRequestHandler()}.
> + *
> + * @param request The servlet request we are processing
> + * @see org.apache.struts.taglib.CancelTag
> + * @se
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
Doesn't the Struts framework need to call this new method somewhere? The
application code can't call the isCancelled method because the Action class
code will never be called. If Struts ActionServlet calls the form validate
when a user clicked cancel, the validation will likely fail and the user
will be presented with the input form again. Clicking cancel needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/action
> Action.java ActionForm.java
>
>
> mschachter01/05/11 10:11:06
>
> Modified:doc todo-1.1.xml
>src/share/org/apache/struts/action Action.java
> ActionForm.java
> Log:
>- Add an isCancelled() method to the Action class that takes a
> MultipartRequestHandler as an argument. This should address
> issues with the html:cancel tag, as long as the new isCancelled
> method is called on for multipart forms.
>- Add myself to the EJB Design Pattern TODO
>
> Revision ChangesPath
> 1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
>
> Index: todo-1.1.xml
> ===
> RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- todo-1.1.xml2001/04/12 16:00:42 1.2
> +++ todo-1.1.xml2001/05/11 17:10:47 1.3
> @@ -159,6 +159,9 @@
>
>mailto:[EMAIL PROTECTED]";>Nic Hobbs
>
> +
> +mailto:[EMAIL PROTECTED]";>Mike Schachter
> +
>
>
>
>
>
>
> 1.20 +27 -4
> jakarta-struts/src/share/org/apache/struts/action/Action.java
>
> Index: Action.java
> ===
> RCS file:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v
> retrieving revision 1.19
> retrieving revision 1.20
> diff -u -r1.19 -r1.20
> --- Action.java 2001/02/23 21:13:09 1.19
> +++ Action.java 2001/05/11 17:10:55 1.20
> @@ -1,7 +1,7 @@
>/*
> - * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
> - * $Revision: 1.19 $
> - * $Date: 2001/02/23 21:13:09 $
> + * $Header:
> /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
> tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
> + * $Revision: 1.20 $
> + * $Date: 2001/05/11 17:10:55 $
> *
> *
>
> *
> @@ -67,6 +67,7 @@
>import java.security.MessageDigest;
>import java.security.NoSuchAlgorithmException;
>import java.util.Locale;
> +import java.util.Hashtable;
>import javax.servlet.ServletException;
>import javax.servlet.ServletRequest;
>import javax.servlet.ServletResponse;
> @@ -75,6 +76,7 @@
>import javax.servlet.http.HttpSession;
>import org.apache.struts.taglib.html.Constants;
>import org.apache.struts.util.MessageResources;
> +import org.apache.struts.upload.MultipartRequestHandler;
>
>
>/**
> @@ -106,7 +108,7 @@
> * by this Action.
> *
> * @author Craig R. McClanahan
> - * @version $Revision: 1.19 $ $Date: 2001/02/23 21:13:09 $
> + * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
> */
>
>public class Action {
> @@ -466,6 +468,27 @@
> return
> ((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
>
> (request.getParameter(Constants.CANCEL_PROPERTY_X) != null));
>
> +}
> +
> +/**
> + * Returns true if the current multipart
> form's cancel button was
> + * pressed. This method will check if the cancel
> button generated by
> + * CancelTag was pressed by the user in the
> + * current request. If true, validation performed by an
> + * ActionForm validate() method will have been
> + * skipped by the controller servlet. A
> MultipartRequestHandler instance
> + * can be obtained from a multipart form by calling
> + * {@link ActionForm#getMultipartRequestHandler()
> ActionForm.getMultipartRequestHandler()}.
> + *
> + * @param request The servlet request we are processing
> + * @see org.apache.struts.taglib.CancelTag
> + * @see org.apache.struts.action.ValidatingActionForm
> + */
> +protected boolean isCancelled(MultipartRequestHandler
> request) {
> +
> +Hashtable elements = request.getTextElements();
> +return ((elements.get(Constants.CANCEL_PROPERTY)
> != null) ||
> +(elements.get(Constants.CANCEL_PROPERTY_X)
> != null));
>}
>
>
>
>
>
> 1.7
cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
mschachter01/05/11 10:11:06
Modified:doc todo-1.1.xml
src/share/org/apache/struts/action Action.java
ActionForm.java
Log:
- Add an isCancelled() method to the Action class that takes a
MultipartRequestHandler as an argument. This should address
issues with the html:cancel tag, as long as the new isCancelled
method is called on for multipart forms.
- Add myself to the EJB Design Pattern TODO
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
Index: todo-1.1.xml
===
RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- todo-1.1.xml 2001/04/12 16:00:42 1.2
+++ todo-1.1.xml 2001/05/11 17:10:47 1.3
@@ -159,6 +159,9 @@
mailto:[EMAIL PROTECTED]";>Nic Hobbs
+
+mailto:[EMAIL PROTECTED]";>Mike Schachter
+
1.20 +27 -4 jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Action.java 2001/02/23 21:13:09 1.19
+++ Action.java 2001/05/11 17:10:55 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v 1.19
2001/02/23 21:13:09 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/02/23 21:13:09 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v 1.20
2001/05/11 17:10:55 mschachter Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/05/11 17:10:55 $
*
*
*
@@ -67,6 +67,7 @@
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Locale;
+import java.util.Hashtable;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
@@ -75,6 +76,7 @@
import javax.servlet.http.HttpSession;
import org.apache.struts.taglib.html.Constants;
import org.apache.struts.util.MessageResources;
+import org.apache.struts.upload.MultipartRequestHandler;
/**
@@ -106,7 +108,7 @@
* by this Action.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.19 $ $Date: 2001/02/23 21:13:09 $
+ * @version $Revision: 1.20 $ $Date: 2001/05/11 17:10:55 $
*/
public class Action {
@@ -466,6 +468,27 @@
return ((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
(request.getParameter(Constants.CANCEL_PROPERTY_X) != null));
+}
+
+/**
+ * Returns true if the current multipart form's cancel button was
+ * pressed. This method will check if the cancel button generated by
+ * CancelTag was pressed by the user in the
+ * current request. If true, validation performed by an
+ * ActionForm validate() method will have been
+ * skipped by the controller servlet. A MultipartRequestHandler instance
+ * can be obtained from a multipart form by calling
+ * {@link ActionForm#getMultipartRequestHandler()
ActionForm.getMultipartRequestHandler()}.
+ *
+ * @param request The servlet request we are processing
+ * @see org.apache.struts.taglib.CancelTag
+ * @see org.apache.struts.action.ValidatingActionForm
+ */
+protected boolean isCancelled(MultipartRequestHandler request) {
+
+Hashtable elements = request.getTextElements();
+return ((elements.get(Constants.CANCEL_PROPERTY) != null) ||
+(elements.get(Constants.CANCEL_PROPERTY_X) != null));
}
1.7 +7 -5
jakarta-struts/src/share/org/apache/struts/action/ActionForm.java
Index: ActionForm.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionForm.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ActionForm.java 2001/02/21 00:35:43 1.6
+++ ActionForm.java 2001/05/11 17:10:58 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionForm.java,v 1.6
2001/02/21 00:35:43 craigmcc Exp $
- * $Revision: 1.6 $
- * $Date: 2001/02/21 00:35:43 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionForm.java,v 1.7
2001/05/11 17:10:58 mschachter Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/05/11 17:10:58 $
*
* =
Re: [BeanUtils] Need a type conversion hook
Sorry to interject...
>From personal experience I would recommend coming up with a custom
solution in this case. I've built an entire GUI framework partially
around PropertyEditors and their short-comings are numerous. For
simple data conversion I think they are overkill.
PropertyEdiors are designed to be used by taking the value out of
the bean, editing it, and then asking the property editor for the
value so you can put it back into the bean... or alternately,
registering a PropertyChangeListener to watch the value change. This
seems a bit heavy for just data conversion and in a transactional
environment all/most of the other features of PropertyEditors are
wasted.
Something like a filtering/conversion layer seems more appropriate.
I've usually put conversions like this in the validation layer, but
I'm not sure how that would fit in struts.
Just my $0.02,
-Paul Speed
"Craig R. McClanahan" wrote:
>
> Hi Dmitri,
>
> No, I don't think that your problem is unique -- but it's definitely one I
> haven't had time to think much about in a Struts 1.0 time frame.
>
> In addition to the two alternatives you have proposed, the JavaBeans spec
> provides a standard API for doing custom type conversions -- the
> PropertyEditor class, where you end up calling the getAsText() and
> setAsText() methods to do the conversion. Would it be helpful to you if
> the conversion utilities supported that mechanism automatically?
>
> Even if we do, that wouldn't necessarily preclude building our own
> conversion registration system in addition -- but I like to support the
> standard mechanisms when they are available.
>
> Craig
>
> On Fri, 11 May 2001, Dmitri Plotnikov wrote:
>
> > BeanUtils are fantastic. There is just one minor issue
> > I have with them. There are no hooks for me to
> > augment their behavoir.
> >
> > Here's my specific problem. I am using an Enum
> > framework that gives me very nice, fully automatic
> > support for Enum types like Gender{Male, Female}. It
> > is internationalized, easy to use etc. Each enum type
> > is represented by its own class, like
> > "com.plotix.enums.Gender". One of nice aspects of
> > Enums is that they lend themselves perfectly to HTML:
> > I am using them to populate select/option tags. With
> > select/option tags, I don't have the possibility of
> > invalid user input, so I really don't have a need to
> > declare String getters/setters on my ActionForm.
> > Those getters/setters take Gender objects. So far so
> > good.
> >
> > The problems begin in Struts when a POST comes to
> > ActionServlet and ActionServlet invokes
> > BeanUtils.populate() to copy parameters of the POST
> > into the ActionForm. The conversion from String
> > (that's what comes in the POST) to Gender (that's the
> > type of the setter on the ActionBean) fails, because
> > BeanUtils don't know anything about my Enums, nor
> > would I want them to. All I want is for them to
> > delegate their work to a custom object that would help
> > them with type conversion when they discover they are
> > unable to perform the job on their own.
> >
> > I have two specific solutions in mind:
> >
> > 1. We could introduce a registration mechanism for
> > custom type converters. BeanUtils would then invoke
> > these type converters one after another until it found
> > one that could do the job. The interface of the
> > converter could be something like:
> >
> >public interface TypeConverter {
> > boolean canConvert(Class from, Class to);
> > Object convert(Object from, Class to)
> > throws ConversionException;
> >}
> >
> > The registration mechanism could either be static
> > (which I don't think would be cool) or it could be
> > dynamic, with a registry of converters passed to
> > BeanUtils in the methods calls. In a web app, the
> > registry could be hosted by the application context,
> > in Struts - ActionServlet.
> >
> > 2. Alternatively, we could introduce some generic API
> > on ActionBean like: setProperty(String propertyName,
> > Object value). BeanUtils would call this method for
> > every property. I would then override this method,
> > do special things to my special fields and then let
> > the superclass do the rest. The superclass would then
> > call BeanUtils back. We don't want to introduce a
> > dependency between BeanUtils and Struts, so the
> > setProperty() method would have to be declared on an
> > interface defined in Commons. ActionForm would
> > implement that interface.
> >
> > If this approach is accepted, I will, of course,
> > volunteer to do the work.
> >
> > I wonder if this issue is unique to my project? Is
> > anybody else experiencing similar problems?
> >
> > Best regards,
> >
> > - Dmitri Plotnikov
> > [EMAIL PROTECTED]
> >
> > __
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great prices
> > http://auctions.yahoo.com/
> >
cvs commit: jakarta-struts/doc struts-html.xml
craigmcc01/05/11 09:55:40 Modified:doc struts-html.xml Log: Make the "size" attribute available on the custom tag. The underlying base class already supports this. Submitted by: Andy Brook <[EMAIL PROTECTED]> Revision ChangesPath 1.10 +9 -0 jakarta-struts/doc/struts-html.xml Index: struts-html.xml === RCS file: /home/cvs/jakarta-struts/doc/struts-html.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- struts-html.xml 2001/05/09 19:31:01 1.9 +++ struts-html.xml 2001/05/11 16:55:38 1.10 @@ -1055,6 +1055,15 @@ +size +false +true + +Size of the file selection box to be displayed. + + + + style false true
Re: [BeanUtils] Need a type conversion hook
Hi Dmitri,
No, I don't think that your problem is unique -- but it's definitely one I
haven't had time to think much about in a Struts 1.0 time frame.
In addition to the two alternatives you have proposed, the JavaBeans spec
provides a standard API for doing custom type conversions -- the
PropertyEditor class, where you end up calling the getAsText() and
setAsText() methods to do the conversion. Would it be helpful to you if
the conversion utilities supported that mechanism automatically?
Even if we do, that wouldn't necessarily preclude building our own
conversion registration system in addition -- but I like to support the
standard mechanisms when they are available.
Craig
On Fri, 11 May 2001, Dmitri Plotnikov wrote:
> BeanUtils are fantastic. There is just one minor issue
> I have with them. There are no hooks for me to
> augment their behavoir.
>
> Here's my specific problem. I am using an Enum
> framework that gives me very nice, fully automatic
> support for Enum types like Gender{Male, Female}. It
> is internationalized, easy to use etc. Each enum type
> is represented by its own class, like
> "com.plotix.enums.Gender". One of nice aspects of
> Enums is that they lend themselves perfectly to HTML:
> I am using them to populate select/option tags. With
> select/option tags, I don't have the possibility of
> invalid user input, so I really don't have a need to
> declare String getters/setters on my ActionForm.
> Those getters/setters take Gender objects. So far so
> good.
>
> The problems begin in Struts when a POST comes to
> ActionServlet and ActionServlet invokes
> BeanUtils.populate() to copy parameters of the POST
> into the ActionForm. The conversion from String
> (that's what comes in the POST) to Gender (that's the
> type of the setter on the ActionBean) fails, because
> BeanUtils don't know anything about my Enums, nor
> would I want them to. All I want is for them to
> delegate their work to a custom object that would help
> them with type conversion when they discover they are
> unable to perform the job on their own.
>
> I have two specific solutions in mind:
>
> 1. We could introduce a registration mechanism for
> custom type converters. BeanUtils would then invoke
> these type converters one after another until it found
> one that could do the job. The interface of the
> converter could be something like:
>
>public interface TypeConverter {
> boolean canConvert(Class from, Class to);
> Object convert(Object from, Class to)
> throws ConversionException;
>}
>
> The registration mechanism could either be static
> (which I don't think would be cool) or it could be
> dynamic, with a registry of converters passed to
> BeanUtils in the methods calls. In a web app, the
> registry could be hosted by the application context,
> in Struts - ActionServlet.
>
> 2. Alternatively, we could introduce some generic API
> on ActionBean like: setProperty(String propertyName,
> Object value). BeanUtils would call this method for
> every property. I would then override this method,
> do special things to my special fields and then let
> the superclass do the rest. The superclass would then
> call BeanUtils back. We don't want to introduce a
> dependency between BeanUtils and Struts, so the
> setProperty() method would have to be declared on an
> interface defined in Commons. ActionForm would
> implement that interface.
>
> If this approach is accepted, I will, of course,
> volunteer to do the work.
>
> I wonder if this issue is unique to my project? Is
> anybody else experiencing similar problems?
>
> Best regards,
>
> - Dmitri Plotnikov
> [EMAIL PROTECTED]
>
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
>
RE: Adding a new "workflow" scope type
We have also explored such idea, although this was just a discussion in our team. We however have also concluded that the notion of workflow, or "contexts" in our terms, is strongly related to the notion of command token already discussed in this user list in Dec. 2000, and therefore both should be looked into at the same time. Indeed, a workflow very often relates to form submissions, sometimes several forms across multiple pages. In those cases, a better management of the data associated to the workflow is needed, so that the session context can be cleaned up correctly. And wherever forms are submitted, transaction integrity is also required. And in both cases, tokens are required to handle them. This has suggested me the notion of contexts, some being standards (request, session, etc.), others being custom defined (like your notion of workflow). Each context type would carry different behavior in terms of: - how many context of this type can be started during a session - how many context of this type can run concurrently in a session - whether going through the starting point of a context will create a new instance of a context, reuse an existing one, etc. - critical section handling (useful for form submission and transaction processing) - etc. We haven't given any further thoughts than this, and certainly not in terms of implementation. But the need has been identified and put in a list of things to look into someday. I'd be curious to know whether anybody else agrees with this idea of joining together into the same concept of custom contexts, things like : workflow, sensitive forms, and transaction integrity. François Rey Financial WebSuite Capco http://www.capco.com/ -Original Message- From: TKV Tyler VanGorder [mailto:[EMAIL PROTECTED]] Sent: 11 May 2001 02:07 To: [EMAIL PROTECTED] Subject: Adding a new "workflow" scope type I have seen this asked a couple of times on the strut users mailing list. The problem this new "workflow" scope is meant to address is as follows: When a browser client establishes a session with the servlet engine, there is nothing stopping the user from opening up more than one browser window during that session. This means that any data stored in the session scope will be shared by both windows. A user can proceed through an instance of the same workflow in each of their browser windows and there is no way of distinguishing which data belongs to each instance. The "request" scope doesn't solve this problem if a workflow spans more than one browser request. Thus a new scope type: "workflow" A workflow is started by a particular action mapping and a token is generated to identify the workflow context. That ID is set on an attribute of the request. The workflow context is passed along by encoding the additional workflow context ID into any URL that is embedded in the JSPs. So, encoding a standard URL now goes through two layers - First we grab the workflow context ID from the request attributes. - We encode the workflow context ID into our URL. - Finally, we encode the new URL with the servlet's session ID. You then modify the ActionServlet, so that when it gets a request, it can parse out the workflow ID out of the encoded URL and place it back into the request object. Objects that are in "workflow" scope are stored in the user's session using the workflow context ID as the key. The value of that entry is another hashmap that allows arbitrary key/object mappings. Finally, you identify a particular action as ending a workflow. The action servlet parses our the workflow ID from the URL, does NOT put that into the request object and removes all the data for that workflow from the user's session. Any comments on this? Thanks Tyler Van Gorder [EMAIL PROTECTED] Landacorp. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: version that doesn't require name
Ok, my bad. Notice that the key is
org.apache.struts.taglib.Constants.BEAN_KEY instead of
org.apache.struts.taglib.html.Constants.BEAN_KEY. I was missing the "html"
node in the package. Boy I'll be glad when all that source is gone.
Thanks.
Wayne
-Original Message-
From: Young, Wayne [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 10:02 AM
To: Struts-Dev@Jakarta. Apache. Org (E-mail)
Subject: version that doesn't require name
I've been trying to make a version of that doesn't require the
"name" attribute and just uses the default form bean if it isn't supplied.
(like the HTML tags work)
I've tried changing the name to Contants.BEAN_KEY just like in BaseFieldTag.
// Look up the requested bean (if necessary)
if ("".equals(name) || name == null) {
name = org.apache.struts.taglib.Constants.BEAN_KEY;
}
I always get the message that the bean isn't found in the pagecontext. Any
ideas what I need to do to resolve this?
Thanks.
Wayne
[EMAIL PROTECTED]
[BeanUtils] Need a type conversion hook
BeanUtils are fantastic. There is just one minor issue
I have with them. There are no hooks for me to
augment their behavoir.
Here's my specific problem. I am using an Enum
framework that gives me very nice, fully automatic
support for Enum types like Gender{Male, Female}. It
is internationalized, easy to use etc. Each enum type
is represented by its own class, like
"com.plotix.enums.Gender". One of nice aspects of
Enums is that they lend themselves perfectly to HTML:
I am using them to populate select/option tags. With
select/option tags, I don't have the possibility of
invalid user input, so I really don't have a need to
declare String getters/setters on my ActionForm.
Those getters/setters take Gender objects. So far so
good.
The problems begin in Struts when a POST comes to
ActionServlet and ActionServlet invokes
BeanUtils.populate() to copy parameters of the POST
into the ActionForm. The conversion from String
(that's what comes in the POST) to Gender (that's the
type of the setter on the ActionBean) fails, because
BeanUtils don't know anything about my Enums, nor
would I want them to. All I want is for them to
delegate their work to a custom object that would help
them with type conversion when they discover they are
unable to perform the job on their own.
I have two specific solutions in mind:
1. We could introduce a registration mechanism for
custom type converters. BeanUtils would then invoke
these type converters one after another until it found
one that could do the job. The interface of the
converter could be something like:
public interface TypeConverter {
boolean canConvert(Class from, Class to);
Object convert(Object from, Class to)
throws ConversionException;
}
The registration mechanism could either be static
(which I don't think would be cool) or it could be
dynamic, with a registry of converters passed to
BeanUtils in the methods calls. In a web app, the
registry could be hosted by the application context,
in Struts - ActionServlet.
2. Alternatively, we could introduce some generic API
on ActionBean like: setProperty(String propertyName,
Object value). BeanUtils would call this method for
every property. I would then override this method,
do special things to my special fields and then let
the superclass do the rest. The superclass would then
call BeanUtils back. We don't want to introduce a
dependency between BeanUtils and Struts, so the
setProperty() method would have to be declared on an
interface defined in Commons. ActionForm would
implement that interface.
If this approach is accepted, I will, of course,
volunteer to do the work.
I wonder if this issue is unique to my project? Is
anybody else experiencing similar problems?
Best regards,
- Dmitri Plotnikov
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
version that doesn't require name
I've been trying to make a version of that doesn't require the
"name" attribute and just uses the default form bean if it isn't supplied.
(like the HTML tags work)
I've tried changing the name to Contants.BEAN_KEY just like in BaseFieldTag.
// Look up the requested bean (if necessary)
if ("".equals(name) || name == null) {
name = org.apache.struts.taglib.Constants.BEAN_KEY;
}
I always get the message that the bean isn't found in the pagecontext. Any
ideas what I need to do to resolve this?
Thanks.
Wayne
[EMAIL PROTECTED]
FeatureRequest for tagname 'file' in struts-html.xml
Hi, The html:file tag attributes as specified in struts-html.xml dont specify 'size', can someone please it, thats all that is required to enable resizeable file input field boxes... Cheers, andy.
