DO NOT REPLY [Bug 26127] - html:img tag lacks action attribute
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=26127.
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=26127
html:img tag lacks action attribute
--- Additional Comments From [EMAIL PROTECTED] 2004-01-16 11:55 ---
Will something like this do?
public ActionForward execute(ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServletResponse response) throws
Exception {
try {
byte[] buffer = new byte[2048];
int bytesRead;
InputStream input =
getServlet().getServletContext().getResourceAsStream(image.jpg);
OutputStream
out = response.getOutputStream();
while ((bytesRead = input.read(buffer)) != -1) {
out.write(buffer, 0, bytesRead);
}
out.close();
}
catch (Exception e)
{
}
return null;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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]
DO NOT REPLY [Bug 26192] New: - forward element redirect and className attributes not honored
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=26192. 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=26192 forward element redirect and className attributes not honored Summary: forward element redirect and className attributes not honored Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm trying to get a redirecting action forward to work, with the following forward element within an action element: forward name=failure path=/ redirect=true/ it seems that the redirect attribute is not honored, as the following code in the corresponding action element: ActionForward forward = mapping.findForward(failure); System.err.println(redirect: + forward.getRedirect()); will result in the output: redirect: false I also tried forcing the RedirectingActionForward class to be used with: forward name=failure path=/ redirect=true className=org.apache.struts.action.RedirectingActionForward/ but it seems that the className attribute is not honored either, as the following code: ActionForward forward = mapping.findForward(failure); System.err.println(redirect: + forward.getRedirect()); System.err.println(class: + forward.getClass()); will output: redirect: false class: class org.apache.struts.action.ActionForward I'm using nightly build: jakarta-struts-20040113.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
RE: why are form beans required for html:form?
The data not going to a form bean seem to be a 'very' limited use, especially with the ease of DynaActionForms. There already exists a fair amount of technology to handle this sort of situation. Additionally, the idea of struts was to put a framework around this. To compliciate the tags for this situation seems...like it should be thought about further. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 11:21 PM To: Struts Developers List Subject: RE: why are form beans required for html:form? On Thu, 15 Jan 2004 12:14:46 -0600, Joe Germuska wrote: Now, at the risk of sidetracking this discussion, I have to bring up my other Struts pet-peeve -- the over complexity of pre-filling forms from data rather than from the request. I'm wondering if bringing up some questions about how the form bean is looked up gives me a chance to scratch that itch too...? I don't think this is what you meant, but I've wondered whether the tags should check the request for a corresponding attribute if the formbean property returns null. This could answer the case where the target property is not a String (or boolean). If the bean property is null, and the same property exists in the request, then we have the case where validation failed and the attribute could not be stored in the target property. If the tag then displayed the request attribute, we could have typed input field on ActionForms. (Essentially, we are using the request as our String buffer.) Though for consistency, a better idea (if this first idea is even good) would be to check the request for a corresponding attribute first, and then look to the formbean property if the attribute is absent. Again, this would let us use the request for an input buffer, and reserve the ActionForm for validated input. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
--- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
--- Niall Pemberton [EMAIL PROTECTED] wrote: I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? There wasn't a vote so my -1 is more of an indication that I don't like the idea. Mask is the most flexible validation that allows many things like formatted number validations. If you can't get your regex to work you might try writing a custom validation action that uses DecimalFormat. If that works you could post a patch to bugzilla. I encourage you to get the regex to work though because it will make life easier in the long run :-). David Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
OK hey, appreciate your feedback - and the mask/regexp gives me another string to my bow! I do think using the DecimalFormat style patterns is much easier and intuitive, but there is the issue over JavaScript and there are issues with the DecimalFormat parse() method. I think I need to re-think this enhacement request so I'll drop it for the moment and perhaps submit something different at a later date. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:46 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? There wasn't a vote so my -1 is more of an indication that I don't like the idea. Mask is the most flexible validation that allows many things like formatted number validations. If you can't get your regex to work you might try writing a custom validation action that uses DecimalFormat. If that works you could post a patch to bugzilla. I encourage you to get the regex to work though because it will make life easier in the long run :-). David Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct)
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Niall - If you do add on to this patch to support JavaScript validations of numberFormats, there is probably some existing JavaScript code available that you can use. I would start by looking at Matt Kruse's JavaScript Date Functions, which you can find here: http://www.mattkruse.com/javascript/date/ Matt - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 9:48 AM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK hey, appreciate your feedback - and the mask/regexp gives me another string to my bow! I do think using the DecimalFormat style patterns is much easier and intuitive, but there is the issue over JavaScript and there are issues with the DecimalFormat parse() method. I think I need to re-think this enhacement request so I'll drop it for the moment and perhaps submit something different at a later date. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:46 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: I agree with both of you! Not having JavaScript implementation shouldn't be an issue - if people want it then someone would come up with it. However, because the approach I took was to modify the exiting number validations (byte, short, long, integer, float, double) then it means that where there is JavaScript validation (not all of them seem to have) these will now fail if a pattern is used, because they don't take into account the pattern. I would put some additional time on this, if a committer was willing to implement it. But since David Graham has said he is -1 on this, doesn't that effectively make this enhacement request dead? There wasn't a vote so my -1 is more of an indication that I don't like the idea. Mask is the most flexible validation that allows many things like formatted number validations. If you can't get your regex to work you might try writing a custom validation action that uses DecimalFormat. If that works you could post a patch to bugzilla. I encourage you to get the regex to work though because it will make life easier in the long run :-). David Niall Richard Hightower wrote ... I agree about that sticky wicket, but There are already validation rules that do not have client-side support (via JavaScript). At least this type of stuff would be nice in the contrib area. Ted Husted wrote ... In principle, I'd agree with Rick, since these type of patterns are the standard way of doing this sort of thing on the Java platform. But, the sticky wicket is lack of a JavaScript implementation. People would expect an implementation like this to include client-side support, as the other validations do. -Ted. On Thu, 15 Jan 2004 20:54:17 -0700, Richard Hightower wrote: Niall, I don't get a vote. I am not a committer. But if I did I would vote +1 on the idea (I have not studied your implementation). I can write regular expressions in a pinch, but why not support all of the java.text.* in the validator rules (including currencey). I like the idea. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc- mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:38 PM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] OK so how can it be done with mask? also, it doesn't get more basic than numbers...if it can be done with mask, but its complicated, doesn't ease of use cut any ice? Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
--- Niall Pemberton [EMAIL PROTECTED] wrote: Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. I think you meant $ instead of % but yes that's correct. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. I really haven't looked at the differences between matches() and contains() so I don't know if it's backwards compatible. You could try changing it and let us know what happens. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If
DO NOT REPLY [Bug 26151] - Optionally specify patterns for byte, short, int, long, float, double validation
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=26151. 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=26151 Optionally specify patterns for byte, short, int, long, float, double validation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 15:05 --- Following discussion and comments on the list, I'm dropping this enhacement request - it needs to be re-thought and I may re-submit something at a later date. A summary of the points raised were: 1) Specifying a RegExp mask validation can do a similar job (I accept this but also think DecimalFormat's style patterns are eaier and more intuitive). 2) Existing JavaScript validation would need to be changed to cater for patterns, otherwise it would reject valid input in the pattern format. 3) There are limitations with the DecimalFormat.parse() method. 3.1) It always accepts decimals whatever the pattern specified. This was got round in this enahacement by checking the returned value was not a Double type (for byte, short, integer long) - but the javadoc for DecimalFormat says that this shouldn't be relied on for future versions. 3.2) Once it reaches non-numeric data after parsing a number, then DecimalFormat just stops so if someone enters 123x456 by mistake, it would be parsed as 123 and accepted as valid, rather than rejected as an error. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
I already tried it, and it is backward compatible. The thing about Perl5Util is it provides a convinience method of match(value, pattern) which creates a Perl5Compiler, builds a cache of compiled patterns and calls the Perl5Matcher.contains() method. There isn't an equivalent convinience method that calls the Perl5Matcher.matches() method. Replacing: boolean match = Perl5Util.match(value, pattern) requires: Perl5Compiler compiler = new Perl5Compiler(); Pattern compiledPattern = compiler.compile(pattern); Perl5Matcher matcher = new Perl5Matcher(); boolean match = matcher.matches(value, compiledPattern); But then, it would be less efficient as the pattern is being compiled every time. It would be straight forward to do the equivalent of Perl5Util and create a cache. I might have a look at this later and submit a patch to Commons. Niall - Original Message - David Graham [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. I think you meant $ instead of % but yes that's correct. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. I really haven't looked at the differences between matches() and contains() so I don't know if it's backwards compatible. You could try changing it and let us know what happens. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request:
DO NOT REPLY [Bug 24856] - Struts doesn´t accept internationalized form inputs for Number, Date, Timestamp etc
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=24856. 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=24856 Struts doesn´t accept internationalized form inputs for Number, Date, Timestamp etc --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 16:05 --- I can see part of an answer for closing this bug in Ted Husted comment to bug #22703: not having plain Strings in a Struts Form will make it difficult to use validation and redisplay input values. Probably you are better using some sort of DynaBean first and an additional layer to make conversions from String(s) DynaBean to typed java objects once the page has bean validated. In any event, solving Commons BeanUtils bug #24941 first would come handy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Push find 'unknown' ActionConfig into ModuleConfigImpl.findActionConfig?
I'm still a little gun-shy about changing core struts classes. I think the below is the right thing to do, but I thought I'd see first. ModuleConfigImpl.findActionConfig(String path) currently looks for an exact match of the path, and then uses the wild-card matching. However, it does not honor the unknown setting of action configs. That fallback is implemented in the RequestProcessor. I'd propose moving that from the RequestProcessor into the ModuleConfigImpl. This would then also involve removing a similar fallback that I committed to the struts-chain AbstractSelectAction class yesterday. Does anyone object? I mentioned this in my posting about struts-chain, but didn't get any responses on this piece. Similarly, I believe that the findException(Class clazz) method in ActionMapping should be pushed up into ActionConfig so that its fallback strategy of looking for superclass exception handlers is available. Is there any controversy to doing this? How annoyed would people be if I had just made these changes and committed them rather than asking for opinions? 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: Push find 'unknown' ActionConfig into ModuleConfigImpl.findActionConfig?
--- Joe Germuska [EMAIL PROTECTED] wrote: I'm still a little gun-shy about changing core struts classes. I think the below is the right thing to do, but I thought I'd see first. ModuleConfigImpl.findActionConfig(String path) currently looks for an exact match of the path, and then uses the wild-card matching. However, it does not honor the unknown setting of action configs. That fallback is implemented in the RequestProcessor. I'd propose moving that from the RequestProcessor into the ModuleConfigImpl. This would then also involve removing a similar fallback that I committed to the struts-chain AbstractSelectAction class yesterday. How would removing it from RequestProcessor affect backwards compatibility? Could subclasses be relying on the fallback being there? Does anyone object? I mentioned this in my posting about struts-chain, but didn't get any responses on this piece. Similarly, I believe that the findException(Class clazz) method in ActionMapping should be pushed up into ActionConfig so that its fallback strategy of looking for superclass exception handlers is available. Is there any controversy to doing this? How annoyed would people be if I had just made these changes and committed them rather than asking for opinions? It's nice to discuss major changes first but most of the time you can just commit a change and wait for someone to speak up if they disagree. David 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] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
At 11:21 PM -0500 1/15/04, Ted Husted wrote: On Thu, 15 Jan 2004 12:14:46 -0600, Joe Germuska wrote: Now, at the risk of sidetracking this discussion, I have to bring up my other Struts pet-peeve -- the over complexity of pre-filling forms from data rather than from the request. I'm wondering if bringing up some questions about how the form bean is looked up gives me a chance to scratch that itch too...? I don't think this is what you meant, but I've wondered whether the tags should check the request for a corresponding attribute if the formbean property returns null. Since I've adopted the use strings as ActionForm properties, I don't have much use for this kind of solution, but it also just seems kind of complicated. I think the trickiest bit about getting the ActionForm for prefilling involves the dependency on ActionMappings in the API around getting form instances. Right now you need an ActionMapping to get a DynaActionForm, although the mapping is just used to look up the FormBeanConfig. Someone has probably suggested this before, but what about adding a newInstance() method to FormBeanConfig? From there, one could create an alternate method on RequestUtils: public static ActionForm createActionForm( HttpServletRequest request, String formName, String scope, ModuleConfig moduleConfig, ActionServlet servlet) presumably it's not asking too much to know the form's name if you intend to set properties on it, and besides, you need to know it so that you can put it in either request or session someplace where the form tag would find it. 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: Push find 'unknown' ActionConfig into ModuleConfigImpl.findActionConfig?
At 8:36 AM -0800 1/16/04, David Graham wrote: I'd propose moving that from the RequestProcessor into the ModuleConfigImpl. This would then also involve removing a similar fallback that I committed to the struts-chain AbstractSelectAction class yesterday. How would removing it from RequestProcessor affect backwards compatibility? Could subclasses be relying on the fallback being there? The fallback is inside processMapping(). processMapping already calls moduleConfig.findActionConfig() so the behavior would be identical. 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: Push find 'unknown' ActionConfig into ModuleConfigImpl.findActionConfig?
At 11:10 AM -0600 1/16/04, Joe Germuska wrote: At 8:36 AM -0800 1/16/04, David Graham wrote: I'd propose moving that from the RequestProcessor into the ModuleConfigImpl. This would then also involve removing a similar fallback that I committed to the struts-chain AbstractSelectAction class yesterday. How would removing it from RequestProcessor affect backwards compatibility? Could subclasses be relying on the fallback being there? The fallback is inside processMapping(). processMapping already calls moduleConfig.findActionConfig() so the behavior would be identical. Whoops. I take that back. If anyone is using a different implementation of ModuleConfig, they may be relying on that behavior. I forgot since ModuleConfig is one of the few interfaces at that layer of struts. ModuleConfig doesn't mention any fallback strategy in the doc for findActionConfig(): Return the action configuration for the specified path, if any; otherwise return null. It's arguable that the wildcard mapping in ModuleConfigImpl honors this, but that returning the unknown action would not. Strictly speaking, perhaps this change isn't appropriate, and the code to walk through the configs looking for an unknown is easy enough to write... I just don't like duplicating it. 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: why are form beans required for html:form?
At 11:29 PM -0500 1/15/04, Ted Husted wrote: My only comment is that it seems we're throwing a lot of technology at a problem that could be solved by putting an empty DynaActionForm in the Struts config, and just referring to that. Perhaps something like: form-bean name=buttonForm type=org.apache.struts.action.DynaForm / That doesn't solve the problem if you want to use html:input tags when you haven't created the form-beans yet. That's kind of a corner case, but we are gradually getting non-developers who can write JSPs and tags ok but haven't yet learned struts-config syntax. Eventually I hope that they will, and then this might not be so important. I still prefer to err on the side of permissiveness -- a blank form rather than a stack trace. 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: Validating Formatted Numbers Patch [Bugzilla 26151]
I can vouch that the mask works. Send me your complete xml file or at least cut and paste the field element in the email and I will take a look. -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 5:03 AM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the Perl5Matcher.contains(value, pattern) method which only checks that the value contains the pattern - not that matches (it says so in the Perl5Util documentation). Isn't this the wrong thing to do - shouldn't validator be using the Perl5Matcher.matches(value, pattern) method. I had a look at commons validator test thinking this must be tested for and I must be mis-understanding it - but mask seems to be the one thing there are no tests for - and there don't seem to be any in struts either for FieldChecks.validateMask()) Anyway, am I right - is this a bug, or am I just using it wrongly? Niall P.S. If I am right, then it implies no one is using mask and I think thats an argument for my simpler number validation. - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:19 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] The point of having the mask validation is so we don't have to support all variations of patterns. I'm -1 on adding validators that duplicate what can already be done with mask. David --- Niall Pemberton [EMAIL PROTECTED] wrote: Robert, I tried to get mask to work (although until today I had no knowledge of regular expressions) using the ORA demonstration applet and I couldn't get it to (including your suggestion). I'm not saying regular expressions couldn't work (only I don't know how to make them!), but the pattern's used in DecimalFormat are so much more straight forward and designed for the task. Typically as people are probably using a pattern with DecimalFormat to output the data to screen, it then is much easier and intuitive to specify the same pattern for validation. I say horses for courses and to me using a number pattern to validate numbers is a better way to do it - hence the enhacement request: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Thanks Niall Robert Leland wrote: So using mask won't work ? (my syntax below is probably not correct) field property=amount depends=required,mask arg0 key=sale.amount / var var-namemask/var-name var-value\d,\d\d0\:\(\d,\d\d0\)/var-value /var /field I need to validate numbers which are formatted and have posted a patch to bugzilla which enhances validator the existing number validations to do this. This patch allows an optional numberPattern variable to be specified for the existing byte, short, integer, long, float and double validations. For Example: field property=amount depends=required,integer arg0 key=sale.amount / var var-namenumberPattern/var-name var-value#,##0:(#,##0)/var-value /var /field If the pattern is specified, then java.text.DecimalFormat is used to parse the number and check if it is valid (catering for Locale). I have also posted a patch to add a new section the Validator User Guide which describes all the standard suppiled validations and shows examples of usage, including using the new numberPattern variable. Thanks in advance for any feedback. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
At 11:29 PM -0500 1/15/04, Ted Husted wrote: My only comment is that it seems we're throwing a lot of technology at a problem that could be solved by putting an empty DynaActionForm in the Struts config, and just referring to that. Perhaps something like: form-bean name=buttonForm type=org.apache.struts.action.DynaForm / That doesn't solve the problem if you want to use html:input tags when you haven't created the form-beans yet. That's kind of a corner case, but we are gradually getting non-developers who can write JSPs and tags ok but haven't yet learned struts-config syntax. Eventually I hope that they will, and then this might not be so important. From the writ, page 172? My favorite romance novel :) form-bean name=buttonForm type=org.apache.struts.action.DynaForm form-property name=value type=java.util.TreeMap / /form-bean html:text propety='value(key)'/ bean:write name=buttonForm property='value(key)' / I still prefer to err on the side of permissiveness -- a blank form rather than a stack trace. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT RE: Validating Formatted Numbers Patch [Bugzilla 26151]
Heres to lots more grief in the future hey lol! - Original Message - From: Richard Hightower [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 10:42 PM Subject: OT RE: Validating Formatted Numbers Patch [Bugzilla 26151] Grief imparts the most knowledge. What would joy mean if we did not have agony?! I've learned a few things from you grief. You contributed a patch, and found another bug with the mask rule. Your grief has benefitted the group. Thanks for sharing your grief. Rick Hightower Developer Struts/J2EE training -- http://www.arc-mind.com/strutsCourse.htm Struts/J2EE consulting -- http://www.arc-mind.com/consulting.htm#StrutsMentoring -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 11:23 AM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] Caused me some griefplus a complete lack knowledge of RegExp until yesterday. Anyway, thanks to everyone for the help and input - I know more today than I did yesterday. I've put a enhancement request into Bugzilla with patch on Commons to change this - fingers crossed it will be approved. Niall - Original Message - From: Richard Hightower [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 6:00 PM Subject: RE: Validating Formatted Numbers Patch [Bugzilla 26151] Niall, Good catch! I was wondering why I had to always specify ^ and $. I wrote a few of my own validator rules (e.g., zip code and phone number), and I used regex from java. I used the match function. This explains some mysteries in my head. -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Friday, January 16, 2004 8:30 AM To: Struts Developers List Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] I already tried it, and it is backward compatible. The thing about Perl5Util is it provides a convinience method of match(value, pattern) which creates a Perl5Compiler, builds a cache of compiled patterns and calls the Perl5Matcher.contains() method. There isn't an equivalent convinience method that calls the Perl5Matcher.matches() method. Replacing: boolean match = Perl5Util.match(value, pattern) requires: Perl5Compiler compiler = new Perl5Compiler(); Pattern compiledPattern = compiler.compile(pattern); Perl5Matcher matcher = new Perl5Matcher(); boolean match = matcher.matches(value, compiledPattern); But then, it would be less efficient as the pattern is being compiled every time. It would be straight forward to do the equivalent of Perl5Util and create a cache. I might have a look at this later and submit a patch to Commons. Niall - Original Message - David Graham [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: Hey thanks for your help - what you suggested worked (i.e. using ^[\d,]*$) - I was using the ORO demo, but if you don't put the right stuff in:-) OK, I'm picking up regex slowly - so this works because ^ is for the beginning of a line and % is for the end of a line. I think you meant $ instead of % but yes that's correct. Apologies for the doesn't work slander then - but wouldn't it be better to use Perl5Matcher.matches(value, pattern) and then there would be no need to specify the ^ and $ characters at the start and end - simpler and less confusing? This could be done and would be backward compatible. I really haven't looked at the differences between matches() and contains() so I don't know if it's backwards compatible. You could try changing it and let us know what happens. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 16, 2004 1:39 PM Subject: Re: Validating Formatted Numbers Patch [Bugzilla 26151] --- Niall Pemberton [EMAIL PROTECTED] wrote: Graham OK, I decided to look further into your suggestion, but didn't get very far and I think its because mask doesn't work. I know it works because I use it in my apps :-). I started with a simple expression of [\d,]* to validate that the input only contains numbers or a comma. Whatever I input though validator always passed it as valid. ORO's test applet is really helpful when testing regexs. Try putting ^ at the front and $ at the end of the pattern. ORO seems to need these to work properly unlike Java 1.4 regexs. David Looking into validator it uses Perl5Util.match(pattern, value) This utility uses the
DO NOT REPLY [Bug 26209] New: - Validator User Guide: New Section Listing Standard Validations
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=26209. 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=26209 Validator User Guide: New Section Listing Standard Validations Summary: Validator User Guide: New Section Listing Standard Validations Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am attaching a patch with a new section for the Validator User Guide. It lists the standard validations that are shipped with struts with a brief description and example for each. Currently the way to find out what the standard shipped validations are is either look at the validator example webapp or read through the validation- rules.xml which is shipped. I would have found this useful. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26209] - Validator User Guide: New Section Listing Standard Validations
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=26209. 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=26209 Validator User Guide: New Section Listing Standard Validations --- Additional Comments From [EMAIL PROTECTED] 2004-01-17 02:14 --- Created an attachment (id=9990) Patch for Validator User Guide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26209] - Validator User Guide: New Section Listing Standard Validations
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=26209. 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=26209 Validator User Guide: New Section Listing Standard Validations [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
DynaBeans are specified in the Struts-Config. They are not Java classes that an engineer needs to writes. http://jakarta.apache.org/struts/userGuide/building_controller.html#dyna_action_form_classes A JSP author should be able to define one without any problem. And the one suggested here, could be a standard part of your team's starter Struts config. Heck, if you throw the JSF extension into the mix, I wager you could write significant Struts applications now without writing any Java code at all. :) http://struts.sourceforge.net/struts-bsf/index.html -Ted. On Fri, 16 Jan 2004 11:31:46 -0600, Joe Germuska wrote: At 11:29 PM -0500 1/15/04, Ted Husted wrote: My only comment is that it seems we're throwing a lot of technology at a problem that could be solved by putting an empty DynaActionForm in the Struts config, and just referring to that. Perhaps something like: form-bean name=buttonForm type=org.apache.struts.action.DynaForm / That doesn't solve the problem if you want to use html:input tags when you haven't created the form-beans yet. That's kind of a corner case, but we are gradually getting non-developers who can write JSPs and tags ok but haven't yet learned struts-config syntax. Eventually I hope that they will, and then this might not be so important. I still prefer to err on the side of permissiveness -- a blank form rather than a stack trace. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide dev_validator.xml
husted 2004/01/16 19:32:11
Modified:doc/userGuide dev_validator.xml
Log:
Apply #26209 Validator User Guide: New Section Listing Standard Validations
submitted by Niall Pemberton.
Revision ChangesPath
1.41 +179 -0jakarta-struts/doc/userGuide/dev_validator.xml
Index: dev_validator.xml
===
RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- dev_validator.xml 2 Jan 2004 11:55:38 - 1.40
+++ dev_validator.xml 17 Jan 2004 03:32:11 - 1.41
@@ -9,6 +9,7 @@
authorDavid Winterfeldt/author
authorJames Turner/author
authorRob Leland/author
+ authorNiall Pemberton/author
titleThe Struts User's Guide - Validator Guide/title
/properties
@@ -153,6 +154,184 @@
]]/code/pre
/section
+
+section href=builtin name=Standard Built In Validations
+
+p
+Validator is shipped with the following set of pre-defined validation rules.
+/p
+ul
+ listrongrequired/strong - mandatory field validation. Has no
variables.
+precode![CDATA[
+field property=name depends=required
+arg0 key=customer.name/
+/field
+]]/code/pre
+ /li
+ listrongrequiredif/strong - field dependant validator
+ preDeprecated, use validwhen./pre
+ /li
+ listrongvalidwhen/strong - validator for checking one field
against another.
+ presee later section titled strongDesigning Complex
Validations with validwhen/strong./pre
+ /li
+ listrongminlength/strong - validate input data isn't less than
a specified minimum length.
+ Requires a codeminlength/code variable.
+precode![CDATA[
+field property=name depends=required,minlength
+arg0 key=customer.name/
+arg1 name=minlength key=${var:minlength} resource=false/
+varvar-nameminlength/var-namevar-value3/var-value/var
+/field
+]]/code/pre
+ /li
+ listrongmaxlength/strong - validate input data doesn't exceed a
specified maximum length.
+ Requires a codemaxlength/code variable.
+precode![CDATA[
+field property=name depends=required,maxlength
+arg0 key=customer.name/
+arg1 name=maxlength key=${var:maxlength} resource=false/
+varvar-namemaxlength/var-namevar-value30/var-value/var
+/field
+]]/code/pre
+ /li
+ listrongmask/strong - validate format according to a regular
expression.
+ Requires a codemask/code variable to specify the regular
expression.
+ Since version 1.1, the regular expression must start
+ with a code^/code and end with a code$/code (see example
below).
+precode![CDATA[
+field property=name depends=required,mask
+msg name=mask key=registrationForm.lastname.maskmsg/
+arg0 key=registration.name/
+varvar-namemask/var-namevar-value^[a-zA-Z]*$/var-value/var
+/field
+]]/code/pre
+ /li
+ listrongbyte/strong - validates that a field can be converted
to a Byte.
+precode![CDATA[
+field property=age depends=byte
+arg0 key=employee.age/
+/field
+]]/code/pre
+ /li
+ listrongshort/strong - validates that a field can be converted
to a Short.
+precode![CDATA[
+field property=productnumber depends=short
+arg0 key=order.prodno/
+/field
+]]/code/pre
+ /li
+ listronginteger/strong - validates that a field can be
converted to an Integer.
+precode![CDATA[
+field property=ordernumber depends=integer
+arg0 key=order.number/
+/field
+]]/code/pre
+ /li
+ listronglong/strong - validates that a field can be converted
to a Long.
+precode![CDATA[
+field property=ordernumber depends=long
+arg0 key=order.number/
+/field
+]]/code/pre
+ /li
+ listrongfloat/strong - validates that a field can be converted
to a Float.
+precode![CDATA[
+field property=amount depends=float
+arg0 key=sale.amount/
+/field
+]]/code/pre
+ /li
+ listrongdouble/strong - validates that a field can be converted
to a Double.
+precode![CDATA[
+field property=amount depends=double
+arg0 key=sale.amount/
+/field
+]]/code/pre
+ /li
+ listrongdate/strong - validates that a field can be converted
to a Date.
+ This validation rule uses
DO NOT REPLY [Bug 26209] - Validator User Guide: New Section Listing Standard Validations
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=26209. 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=26209 Validator User Guide: New Section Listing Standard Validations [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-17 03:32 --- Thanks, Niall! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/examples/exercise html-link.jsp
husted 2004/01/16 20:15:00 Modified:web/examples/WEB-INF/exercise struts-config.xml web/examples/exercise html-link.jsp Log: To hmlt:link page, add test for redirecting to the default path (/). Revision ChangesPath 1.4 +1 -0 jakarta-struts/web/examples/WEB-INF/exercise/struts-config.xml Index: struts-config.xml === RCS file: /home/cvs/jakarta-struts/web/examples/WEB-INF/exercise/struts-config.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- struts-config.xml 16 Jan 2004 04:55:00 - 1.3 +++ struts-config.xml 17 Jan 2004 04:15:00 - 1.4 @@ -14,6 +14,7 @@ forward name=absolute path=http://jakarta.apache.org/struts; / forward name=context-relative path=/welcome.do contextRelative=true / forward name=relative path=/welcome.do / +forward name=redirect-default path=/ redirect=true / forward name=logic-forward path=/logic-forward.do / /global-forwards action-mappings 1.2 +3 -0 jakarta-struts/web/examples/exercise/html-link.jsp Index: html-link.jsp === RCS file: /home/cvs/jakarta-struts/web/examples/exercise/html-link.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- html-link.jsp 8 Jan 2004 16:20:19 - 1.1 +++ html-link.jsp 17 Jan 2004 04:15:00 - 1.2 @@ -139,6 +139,9 @@ li html:link forward=absoluteStruts website/html:link /li + li +html:link forward=redirect-defaultRedirect to the default page (/)/html:link + /li /ul /body /html:html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/examples welcome.html index.html
husted 2004/01/16 20:15:43 Added: web/examples welcome.html index.html Log: Add welcome pages Revision ChangesPath 1.1 jakarta-struts/web/examples/welcome.html Index: welcome.html === !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; !-- :TODO: It would be interesting to try this with frames and modules -- html xmlns=http://www.w3.org/1999/xhtml; head meta name=generator content=HTML Tidy for Windows (vers 1st July 2003), see www.w3.org / titleStruts Examples/title /head body h1Struts Examples/h1 pEach of these links lead to a separate module within this application./p ul lia href=./exercise/welcome.doTaglib Test Pages/a/li lia href=./upload/upload.doUpload examples/a/li lia href=./validator/welcome.doValidator and Localization examples/a/li /ul pThese modules follow the learn by example school. Be sure to look under the hood to see how it's done./p h2a href=./exercise/welcome.doTaglib Test Pages/a/h2 pThese pages are designed to test the operation of the various taglibs that come bundled with Struts. If you examine the JSP templates, you'll see that these pages use a lot of scriptlets. We use scriptlets here in order to test the tags. strongMost production pages will not need to use scriplets./strong In fact many Struts developers emnever/em use scriplets in a production page./p h2a href=./upload/upload.doUpload example/a/h2 pStruts uses the Commons Upload package to provide support for uploading files. This example shows you how to upload a page for processing or how to just display it./p h2a href=./validator/welcome.doValidator examples/a/h2 pThe Struts Validator uses the same resource bundles as the rest of your Struts application, making localization easy to do. These examples show you how to use the validator with and without JavaScript, as well as how to localize your validations./p h2But, wait, there's more .../h2 pIn addion to this application, there are four other applications bundled with Struts, ready for you to install:/p ul liStruts Blank/li liStruts Documentation/li liStruts MailReader/li liStruts Tiles Documentation/li /ul pstrongStruts Blank/strong is an application template. Explode this WAR under your own application's name, and you can start coding! strongStruts Documentation/strong is a copy of everything you'll find on the website: User Guide, Developer's Guide, FAQs, and How-Tos. strongStruts Mailreader/strong is a starter business application, much like the one most of you need to developer. strongStruts Tiles Documentation/strong explores the more advanced features of Tiles./p hr / /body /html 1.1 jakarta-struts/web/examples/index.html Index: index.html === !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; head meta name=generator content=HTML Tidy for Windows (vers 1st July 2003), see www.w3.org / meta http-equiv=Refresh content=0;URL=./welcome.do / title/title /head body /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26192] - forward element redirect and className attributes not honored
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=26192. 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=26192 forward element redirect and className attributes not honored [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-17 04:22 --- The redirect doesn't occur when the ActionForward is access, but when it is process by the controller, after it is returned by the Action class. The ActionForward beans are not actors, but merely descriptors that the RequestProcesor uses to execute the redirect later. The question is not what was printed to standard error, but what page was displayed in the browser. To the taglib exercise module of the new examples application, I added a test to the html:link page that shows a forward ... redirect=true path=/ / does work as expected. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
