DO NOT REPLY [Bug 26639] New: - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639
Multipart request parameters lost after validation failure
Summary: Multipart request parameters lost after validation
failure
Product: Struts
Version: 1.1 Final
Platform: PC
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This happens when the input attribute of an action is set to another .do
instead of a jsp page. The form has enctype set and after validation failure
request becomes empty.
Here is how I solved this in RequestProcessor:
Note that getAllParametersForMultipartRequest() was copied from RequestUtils.
protected boolean processValidate(HttpServletRequest request,
HttpServletResponse response,
ActionForm form,
ActionMapping mapping)
throws IOException, ServletException {
if (form == null) {
return (true);
}
// Was this request cancelled?
if (request.getAttribute(Globals.CANCEL_KEY) != null) {
if (log.isDebugEnabled()) {
log.debug( Cancelled transaction, skipping validation);
}
return (true);
}
// Special handling for multipart request
if (form.getMultipartRequestHandler() != null) {
// Handle repopulation of parameters.
MultipartRequestWrapper wrapper = (MultipartRequestWrapper)
request;
if(request.getAttribute(PARSED_MULTIPART_REQUEST) != null){
Map params = (Map)request.getAttribute
(PARSED_MULTIPART_REQUEST);
// Populate fresh request.
Iterator iter = params.keySet().iterator();
while (iter.hasNext()) {
String key = (String) iter.next();
Object value = params.get(key);
if(value instanceof String[]){
String[] val = (String[]) value;
if(val.length 0){
System.out.println
( Setting parameter + key + to + val[0]);
wrapper.setParameter
(key, val[0]);
}
}
}
}
else{
// Retrive form values and put into properties.
Map multipartParameters = getAllParametersForMultipartRequest(
request, form.getMultipartRequestHandler());
request.setAttribute(PARSED_MULTIPART_REQUEST,
multipartParameters);
}
}
return super.processValidate(request, response, form, mapping);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667 Client-side validation with multi-form page --- Additional Comments From [EMAIL PROTECTED] 2004-02-03 18:20 --- Thanks Matt, I have applied this patch locally but since it requires a change to both struts and Validator to work, I can't commit it just yet. If I apply it to Commons-validator Commons-Validator will no longer work with nightly build of Struts. So once Struts 1.2.0 is out could you remind us to apply this patch ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26643] - StrutsRequestWrapper needs to implement getParameterMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26643 StrutsRequestWrapper needs to implement getParameterMap [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Component|Test|File Upload Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2004-02-03 19:48 --- I assume you're referring to the MultipartRequestWrapper class used for file upload (since there is no StrutsRequestWrapper class, related to test code or otherwise). I'm marking this as LATER because getParameterMap() is a Servlets 2.3 feature, while Struts 1.x is targetted at Servlets 2.2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26643] - StrutsRequestWrapper needs to implement getParameterMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26643 StrutsRequestWrapper needs to implement getParameterMap --- Additional Comments From [EMAIL PROTECTED] 2004-02-03 20:14 --- I was referring to servletunit.struts.StrutsRequestWrapper, packaged in strutstest-2.0.0.jar. I've seen this documented at http://strutstestcase.sourceforge.net/api/servletunit/struts/StrutsRequestWrappe r.html I thought it was part of the struts distribution - perhaps it is part of Cactus? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26643] - StrutsRequestWrapper needs to implement getParameterMap
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26643 StrutsRequestWrapper needs to implement getParameterMap [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2004-02-03 20:18 --- Um, the information you need is in the entry you just posted - that class is part of StrutsTestCase on SourceForge. Although obviously related to Struts, that project is not a part of Struts itself, and indeed is not related to either Jakarta or Apache. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
html:javascript behavior when form is not found
Right now, if you accidentally enter a bogus form name in the html:javascript tag, it omits the wrapping script tags, but prints all the javascript anyway. This doesn't seem right, but for some reason I have a feeling that the solutions I'm thinking of are a bit contentious, so rather than just change it, I thought I'd test the waters. My first thought was to print an HTML comment, something like !-- No form 'formName' found in 'formSet' -- But I think some people might not like that. Alternatives include throwing a JSPException; logging a warning and returning quietly, or doing something more in-your-face that would actually be visible, as opposed to in a comment. Part of me really likes the last because this is something that should only ever happen during development time, and the current spew of javascript is certainly in-your-face, but... Anyway, I don't really have a strong feeling about it. If no one weighs in, I'll probably stick with the comment, but I'll take any other direction. Hopefully the direction will come soon, though, because I'm also going to fix the tag class to escape error messages that contain quote-characters, and I'd just as soon commit 'em both at once. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:javascript behavior when form is not found
I'm not sure if struts itself has a design philosophy, but java itself has the fail fast philosophy. Iterators are one of the most widely cited examples. If something is wrong you want to fail as quickly as possible. A developer should be made aware of the mistake. Leaving a comment is like going half way. As long as the exception message can point them to the error, I'd have a strong preference for that. Paul Joe Germuska wrote: Right now, if you accidentally enter a bogus form name in the html:javascript tag, it omits the wrapping script tags, but prints all the javascript anyway. This doesn't seem right, but for some reason I have a feeling that the solutions I'm thinking of are a bit contentious, so rather than just change it, I thought I'd test the waters. My first thought was to print an HTML comment, something like !-- No form 'formName' found in 'formSet' -- But I think some people might not like that. Alternatives include throwing a JSPException; logging a warning and returning quietly, or doing something more in-your-face that would actually be visible, as opposed to in a comment. Part of me really likes the last because this is something that should only ever happen during development time, and the current spew of javascript is certainly in-your-face, but... Anyway, I don't really have a strong feeling about it. If no one weighs in, I'll probably stick with the comment, but I'll take any other direction. Hopefully the direction will come soon, though, because I'm also going to fix the tag class to escape error messages that contain quote-characters, and I'd just as soon commit 'em both at once. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26647. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26647 srcKey in html:img/ tag needs matching size keys. Summary: srcKey in html:img/ tag needs matching size keys. Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On high-traffic web sites it is necessary to add the height and width of any image to allow for faster and more predictable loading. Under these circumstances, it is very difficult to manage the images using the srcKey attribute since the sizes must be either hard-coded into the tag or created using some type of obtuse code to populate the boxes. It would be much more desirable to have a sizeKey attribute where a height/width of an item would be entered into a property file in a comma delimited form (or other agreed upon format): in the property file myImage.image = /images/someFooImage.jpg myImage.image.size = 180,160 The JSP img tag would look like: html:img srcKey=myImage.image sizeKey=myImage.image.size/ We are moving a high-traffic site to struts (10-12+ million hits monthly) and this has been a thorn in our side. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
This looks like fun. I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? I'd be willing to take a whack at this one. Should this wait until after 1.2 so that can be wrapped up? I've been putting some other minor stuff on hold that I wanted to mention until after the release. If sizeKey was added to html:img, this brings up an issue. In the many places where we have sizes, there is not a key version of it. Text attributes like alt and title have resource versions like altKey and titleKey. Number attributes like size, width and height do not. While it's not a common thing to need varied sizes for numerical values, it's very plausible. Is it worth complicating the AI? Paul Sundling [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26647 srcKey in html:img/ tag needs matching size keys. On high-traffic web sites it is necessary to add the height and width of any image to allow for faster and more predictable loading. Under these circumstances, it is very difficult to manage the images using the srcKey attribute since the sizes must be either hard-coded into the tag or created using some type of obtuse code to populate the boxes. It would be much more desirable to have a sizeKey attribute where a height/width of an item would be entered into a property file in a comma delimited form (or other agreed upon format): in the property file myImage.image = /images/someFooImage.jpg myImage.image.size = 180,160 The JSP img tag would look like: html:img srcKey=myImage.image sizeKey=myImage.image.size/ We are moving a high-traffic site to struts (10-12+ million hits monthly) and this has been a thorn in our side. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
Quoting Paul Sundling [EMAIL PROTECTED]: I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? Just as a matter of note, height and width should work with Netscape 4+ IE 4+ for input type=image. Looks like your pocket reference skimped on the details :) In terms of adding the two attributes to the html:image tag, I personally think it would make a useful addition... Richard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:javascript behavior when form is not found
-Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Right now, if you accidentally enter a bogus form name in the html:javascript tag, it omits the wrapping script tags, but prints all the javascript anyway. This doesn't seem right, but for some reason I have a feeling that the solutions I'm thinking of are a bit contentious, so rather than just change it, I thought I'd test the waters. My first thought was to print an HTML comment, something like !-- No form 'formName' found in 'formSet' -- But I think some people might not like that. Alternatives include throwing a JSPException; logging a warning and returning quietly, or doing something more in-your-face that would actually be visible, as opposed to in a comment. Part of me really likes the last because this is something that should only ever happen during development time, and the current spew of javascript is certainly in-your-face, but... I am all for in-your-face. Tapestry has sort of a built in debugging web page that gives all sorts of stats, on your running web app. The least we can do is Blow up in a loud usefull way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
At 1:36 PM +1300 2/4/04, [EMAIL PROTECTED] wrote: Quoting Paul Sundling [EMAIL PROTECTED]: I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? Just as a matter of note, height and width should work with Netscape 4+ IE 4+ for input type=image. Looks like your pocket reference skimped on the details :) In terms of adding the two attributes to the html:image tag, I personally think it would make a useful addition... height and width are not valid attributes of the input tag: see http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:javascript behavior when form is not found
At 1:55 AM + 2/4/04, [EMAIL PROTECTED] wrote: I am all for in-your-face. Tapestry has sort of a built in debugging web page that gives all sorts of stats, on your running web app. The least we can do is Blow up in a loud usefull way. Alright, then; based on your input and Paul's, I'll make it throw a JSPException. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clean Up conf/share
Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd tiles-config.dtd -- This is for pre struts tiles. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clean Up conf/share
--- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd tiles-config.dtd -- This is for pre struts tiles. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd I agree that most of these should be removed but I think the webapp dtds are used when Struts uses Digester to parse web.xml. David -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clean Up conf/share
David Graham wrote: --- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd tiles-config.dtd -- This is for pre struts tiles. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd I agree that most of these should be removed but I think the webapp dtds are used when Struts uses Digester to parse web.xml. David I'm not the struts gurus that many of you are, but let me ask innocent questions for my own enlightment. If 1.1 is supporting 2.2, why do we have 2.3 dtd also. Since 2.4 uses XML schemas instead of DTD, has that been addressed? Granted, almost nothing changed from servlet 2.3 to 2.4, so DTD for 2.3 should pretty much work. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
Joe Germuska wrote: At 1:36 PM +1300 2/4/04, [EMAIL PROTECTED] wrote: Quoting Paul Sundling [EMAIL PROTECTED]: I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? Just as a matter of note, height and width should work with Netscape 4+ IE 4+ for input type=image. Looks like your pocket reference skimped on the details :) In terms of adding the two attributes to the html:image tag, I personally think it would make a useful addition... height and width are not valid attributes of the input tag: see http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Joe I can't say I'm surprised to hear that since it wasn't in my little book. At the same time, if a given attribute is not part of the official W3C HTML spec, does that mean we shouldn't support the feature if there is browser support for it? This is more a philosophical issue on wether you're supporting the HTML standard, or the browser implementations of the standard. Is there a project stance on that? Two main browsers since version 4 is pretty good support. If it's supported even in Safari and Opera or other, less common browsers, then I would say that's wide enough browser support to definitely consider. Of course, that's irrelevant if we're coding to spec and not implementation. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clean Up conf/share
On Wed, 4 Feb 2004, [EMAIL PROTECTED] wrote: Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd Yes, they should, but we still support config files with the 1.0 format. Are you suggesting we remove that support? I'm not so sure I'd agree with that, as it forces everyone to convert their config files, which may well be quite an onerous task for a large application that otherwise has no reason to change (but which wants to pick up bug fixes in later versions of Struts). tiles-config.dtd -- This is for pre struts tiles. OK. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 Same comment as for the Struts config files, above. web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd Struts parses these files, and wants to do a validating parse. We need local copies so that we're not forced to retrieve them across the net. -- Martin Cooper -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
On Tue, 3 Feb 2004, Paul Sundling wrote: Joe Germuska wrote: At 1:36 PM +1300 2/4/04, [EMAIL PROTECTED] wrote: Quoting Paul Sundling [EMAIL PROTECTED]: I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? Just as a matter of note, height and width should work with Netscape 4+ IE 4+ for input type=image. Looks like your pocket reference skimped on the details :) In terms of adding the two attributes to the html:image tag, I personally think it would make a useful addition... height and width are not valid attributes of the input tag: see http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Joe I can't say I'm surprised to hear that since it wasn't in my little book. At the same time, if a given attribute is not part of the official W3C HTML spec, does that mean we shouldn't support the feature if there is browser support for it? This is more a philosophical issue on wether you're supporting the HTML standard, or the browser implementations of the standard. Is there a project stance on that? Yes, there is. We currently support what's in the HTML 4.01 standard, no more and no less. -- Martin Cooper Two main browsers since version 4 is pretty good support. If it's supported even in Safari and Opera or other, less common browsers, then I would say that's wide enough browser support to definitely consider. Of course, that's irrelevant if we're coding to spec and not implementation. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
