DO NOT REPLY [Bug 26168] New: - wildcard action mapping doesn't work
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=26168.
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=26168
wildcard action mapping doesn't work
Summary: wildcard action mapping doesn't work
Product: Struts
Version: 1.1 Final
Platform: Other
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I'm having problem with making the wildcard action mapping to get to work, as
described in section 4.10 of the user guide:
http://jakarta.apache.org/struts/userGuide/building_controller.html#action_mapping_wildcards
I have the action servlet properly configured in web.xml, and have the following
static mapping in stuts-config.xml, which works properly:
struts-config
action-mappings
action path=/showUrlList
type=hu.tilos.site.ShowUrlListAction
forward name=success path=/showUrlList.jsp/
/action
/action-mappings
/struts-config
if I change this to a dynamic mapping that should invoke the same action:
struts-config
action-mappings
action path=/show*
type=hu.tilos.site.Show{1}Action
forward name=success path=/show{1}.jsp/
/action
/action-mappings
/struts-config
it simply doesn't work, my catalina.out says:
15:14:18,896 ERROR RequestProcessor:683 - Invalid path /showUrlList was requested
it seems that the wildcard is expanded to /showUrlList , but the an action map
by that name is not found. the following config, without {1} marks, has the same
effect:
action path=/show*
type=hu.tilos.site.ShowUrlListAction
forward name=success path=/showUrlList.jsp/
/action
I'm using Tomcat 5.0.16, and the action servlet mapping in my web.xml file is as
follows:
servlet
servlet-nameaction/servlet-name
servlet-classorg.apache.struts.action.ActionServlet/servlet-class
init-param
param-nameconfig/param-name
param-value/WEB-INF/struts-config.xml/param-value
/init-param
init-param
param-namedebug/param-name
param-value2/param-value
/init-param
init-param
param-namedetail/param-name
param-value2/param-value
/init-param
load-on-startup2/load-on-startup
/servlet
!-- Standard Struts Action Servlet Mapping --
servlet-mapping
servlet-nameaction/servlet-name
url-pattern*.do/url-pattern
/servlet-mapping
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tiles and struts-chain
I just committed a new command and a support class to the struts-chain to support using Tiles with Struts chain. I tried to explain it all in the JavaDoc, but basically, if you plug this command in somewhere after the action has executed (or something else has placed a ForwardConfig into the chain context) and before PerformForward (or anything else which expects to have a valid request dispatcher URI as the path of the ForwardConfig which is in context), you'll get Tiles support. There's one gotcha, which is that you have to use the new org.apache.struts.chain.legacy.TilesPlugin, which does nothing more than extend the original TilesPlugin but suppress its init method that fools with the RequestProcessor. Just change the package on the plug-in in your struts config and you should be good to go. Along the way I fixed a couple of bugs in other commands, and came upon two related questions: when looking up either an ActionConfig or an ExceptionHandler, we have two layers of logic in the core of Struts. The first is simply matching a name to a config, but both lookups have fallback strategies. For ActionConfigs, Struts will look for the unknown action if none matches exactly, and for ExceptionHandler, it will walk the inheritance tree of the thrown exception to see if there are registered handlers for any of its superclasses. I copied the unknown action logic into struts-chain, but then when I came upon the analogous problem in the chain's exception handling, I thought again. And actually, for exceptions, ActionMapping has a method (findException) which is the home of the superclass-search logic. Is there a rationale behind having that in ActionMapping and not having it in ActionConfig (ActionMapping's parent class)? For the similar case in ModuleConfigImpl.findActionConfig() we actually already have the logic which applies regular expressions to the action path; is there any reason not to push the walk looking for unknown='true' into there as well? I have to say, I'm pretty excited to finally get my hands dirty with struts-chain! 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 NOT REPLY [Bug 26168] - wildcard action mapping doesn't work
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=26168. 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=26168 wildcard action mapping doesn't work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-15 14:50 --- Wildcards were added after 1.1. Use a nightly build to get this feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tiles and struts-chain
Thank you very much for doing this. I've looked at implementing Tiles support on several occasions and just haven't had the time to do it. Soon as I get a chance I'll download it and see how it works. Greg Joe Germuska wrote: I just committed a new command and a support class to the struts-chain to support using Tiles with Struts chain. I tried to explain it all in the JavaDoc, but basically, if you plug this command in somewhere after the action has executed (or something else has placed a ForwardConfig into the chain context) and before PerformForward (or anything else which expects to have a valid request dispatcher URI as the path of the ForwardConfig which is in context), you'll get Tiles support. There's one gotcha, which is that you have to use the new org.apache.struts.chain.legacy.TilesPlugin, which does nothing more than extend the original TilesPlugin but suppress its init method that fools with the RequestProcessor. Just change the package on the plug-in in your struts config and you should be good to go. Along the way I fixed a couple of bugs in other commands, and came upon two related questions: when looking up either an ActionConfig or an ExceptionHandler, we have two layers of logic in the core of Struts. The first is simply matching a name to a config, but both lookups have fallback strategies. For ActionConfigs, Struts will look for the unknown action if none matches exactly, and for ExceptionHandler, it will walk the inheritance tree of the thrown exception to see if there are registered handlers for any of its superclasses. I copied the unknown action logic into struts-chain, but then when I came upon the analogous problem in the chain's exception handling, I thought again. And actually, for exceptions, ActionMapping has a method (findException) which is the home of the superclass-search logic. Is there a rationale behind having that in ActionMapping and not having it in ActionConfig (ActionMapping's parent class)? For the similar case in ModuleConfigImpl.findActionConfig() we actually already have the logic which applies regular expressions to the action path; is there any reason not to push the walk looking for unknown='true' into there as well? I have to say, I'm pretty excited to finally get my hands dirty with struts-chain! Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validating Formatted Numbers Patch [Bugzilla 26151]
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 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: why are form beans required for html:form?
I think this is a great idea. We often use buttons on the form for navigation between inquiry/dispaly pages which requires that we use a default formbean. Maybe you could add the attributre to the action noded of the struts config file instead of making it a custom tag attribute? This would allow you to let the request processor do the check and instantiate a base/dummy action form. Then you wouldn't have to refactor the tag libraries? I suppose this might sound like a kluge. Gary VanMatre -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 7:09 AM To: Struts Developers List Subject: RE: why are form beans required for html:form? At 8:59 PM -0700 1/14/04, Richard Hightower wrote: how about another attribute, i.e., html:form checkFormBean=false ... The checkFormBean defaults to true so it is backwards compatible with other versions. I like the idea that html:form checks for the form bean. It makes it easier to debug the way it is. However, I can see when you would not want that Well, I'm figuring that if you actually NEED the form bean, then something else would throw an exception; presumably the first input tag which isn't backed by some explicitly named bean. I'd probably leave out the parameter in preference of error checking at the right spot. I think what Ted was getting at in his email was that other tags might not be doing good error checking because they've always deferred to html:form -- and yes, it would be bad to remove the check and then start having NPEs thrown that might be much harder to debug. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
At 8:25 AM -0700 1/15/04, [EMAIL PROTECTED] wrote: I think this is a great idea. We often use buttons on the form for navigation between inquiry/dispaly pages which requires that we use a default formbean. Maybe you could add the attributre to the action noded of the struts config file instead of making it a custom tag attribute? This would allow you to let the request processor do the check and instantiate a base/dummy action form. Then you wouldn't have to refactor the tag libraries? I suppose this might sound like a kluge. Gary: which is the great idea? Using some config param to make the form optional? Or just making it optional in general? I'm not sure what the dummy form is for, unless the form wasn't optional. I'm wondering if I might not also like behavior that also let you use HTML form tags in the absence of a backing form bean; just skip the re-filling instead of throwing an error. That would allow us to have non-programmers flesh out JSPs including forms with the right Struts tags at any time ahead of programmers coming along and implementing the form pieces. They're already familiar with substituting html:* for input type=* in production apps, but they aren't ready to do a lot of struts-config work defining form beans and action mappings. Would people object to reworking the form tags for more graceful degradation at all levels in the absence of a form bean, instead of exception throwing? Joe Gary VanMatre -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 7:09 AM To: Struts Developers List Subject: RE: why are form beans required for html:form? At 8:59 PM -0700 1/14/04, Richard Hightower wrote: how about another attribute, i.e., html:form checkFormBean=false ... The checkFormBean defaults to true so it is backwards compatible with other versions. I like the idea that html:form checks for the form bean. It makes it easier to debug the way it is. However, I can see when you would not want that Well, I'm figuring that if you actually NEED the form bean, then something else would throw an exception; presumably the first input tag which isn't backed by some explicitly named bean. I'd probably leave out the parameter in preference of error checking at the right spot. I think what Ted was getting at in his email was that other tags might not be doing good error checking because they've always deferred to html:form -- and yes, it would be bad to remove the check and then start having NPEs thrown that might be much harder to debug. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Action Config wild cards -- why not use regular expressions?
Unless there's a solid use case, I'd prefer to leave things as they are. You're right that only Validator uses ORO and the plan for Validator 2.0 is to replace it with the standard java.util.regex system which is twice as fast. Since Struts 2.0 will depend on Java 1.4 we could add regex action mapping then if there was a use for it. David --- Joe Germuska [EMAIL PROTECTED] wrote: Since Struts already depends on jakarta-oro, is there a reason not to use it for doing pattern-based mapping, rather than the home-grown methodology that's in the current builds? I don't have a use case for it yet, but since I was a perl hacker before I came to Java, I speak regex reasonably fluently, so it seems to me more useful to have the full power of regular expressions available. If there are strong feelings in favor of the status quo, I think it would be easy enough to make matcherClassName a property of ModuleConfigImpl and support pluggable matchers. I guess technically, only Validator depends on jakarta-oro; I might be persuaded that that's a reason to keep from adding it to the core, maybe... 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: Action Config wild cards -- why not use regular expressions?
Joe Germuska wrote: Since Struts already depends on jakarta-oro, is there a reason not to use it for doing pattern-based mapping, rather than the home-grown methodology that's in the current builds? I don't have a use case for it yet, but since I was a perl hacker before I came to Java, I speak regex reasonably fluently, so it seems to me more useful to have the full power of regular expressions available. I have a few questions about simulating the ~= operation in ORO and Javascript for the validator code, but I'll save those for later. If there are strong feelings in favor of the status quo, I think it would be easy enough to make matcherClassName a property of ModuleConfigImpl and support pluggable matchers. I guess technically, only Validator depends on jakarta-oro; I might be persuaded that that's a reason to keep from adding it to the core, maybe... I doubt anyone could object on the basis of performance, unless they create a benchmark to support the claim it's much slower. Anywhere we can simplify the logic and eliminate duplication is a good thing. Joe Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
as long as it was clear, the distinction between a form bean missing because it should be there, and a form bean missing because it was optional. I would think it might be better as a tag attr, because a form could be shared with different actions, and it might be sticky if it's optional for some but not all. my 2 cents. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 10:46 AM To: Struts Developers List Subject: RE: why are form beans required for html:form? At 8:25 AM -0700 1/15/04, [EMAIL PROTECTED] wrote: I think this is a great idea. We often use buttons on the form for navigation between inquiry/dispaly pages which requires that we use a default formbean. Maybe you could add the attributre to the action noded of the struts config file instead of making it a custom tag attribute? This would allow you to let the request processor do the check and instantiate a base/dummy action form. Then you wouldn't have to refactor the tag libraries? I suppose this might sound like a kluge. Gary: which is the great idea? Using some config param to make the form optional? Or just making it optional in general? I'm not sure what the dummy form is for, unless the form wasn't optional. I'm wondering if I might not also like behavior that also let you use HTML form tags in the absence of a backing form bean; just skip the re-filling instead of throwing an error. That would allow us to have non-programmers flesh out JSPs including forms with the right Struts tags at any time ahead of programmers coming along and implementing the form pieces. They're already familiar with substituting html:* for input type=* in production apps, but they aren't ready to do a lot of struts-config work defining form beans and action mappings. Would people object to reworking the form tags for more graceful degradation at all levels in the absence of a form bean, instead of exception throwing? Joe Gary VanMatre -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 7:09 AM To: Struts Developers List Subject: RE: why are form beans required for html:form? At 8:59 PM -0700 1/14/04, Richard Hightower wrote: how about another attribute, i.e., html:form checkFormBean=false ... The checkFormBean defaults to true so it is backwards compatible with other versions. I like the idea that html:form checks for the form bean. It makes it easier to debug the way it is. However, I can see when you would not want that Well, I'm figuring that if you actually NEED the form bean, then something else would throw an exception; presumably the first input tag which isn't backed by some explicitly named bean. I'd probably leave out the parameter in preference of error checking at the right spot. I think what Ted was getting at in his email was that other tags might not be doing good error checking because they've always deferred to html:form -- and yes, it would be bad to remove the check and then start having NPEs thrown that might be much harder to debug. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Formatted Numbers Patch [Bugzilla 26151]
Niall Pemberton wrote: 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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 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 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 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]
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: [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]
Using Tiles With Message Resource Bundles
I want customize the text inside a tile using Message Resources. e.g. tiles:insert page=My.jsp flush=true tiles:put name=mylabel value=bean:message key=welcome.title/ /tiles:insert Obviously, the above usage of bean:message is illegal. What is the option with tiles. How can we specify a reference to a key in resource bundles to be used as a value into an tiles attribute Thanks __ 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]
cvs commit: jakarta-struts/web/examples/exercise logic-redirect-test-page.jsp logic-redirect-test-forward.jsp logic-redirect-test-action.jsp logic-forward.jsp logic-forward-test-forward.jsp html-img.jsp
husted 2004/01/15 19:52:15 Added: web/examples/exercise logic-redirect-test-page.jsp logic-redirect-test-forward.jsp logic-redirect-test-action.jsp logic-forward.jsp logic-forward-test-forward.jsp html-img.jsp Log: Add test pages for html:img and logic:forward,redirect tags Revision ChangesPath 1.1 jakarta-struts/web/examples/exercise/logic-redirect-test-page.jsp Index: logic-redirect-test-page.jsp === %@ taglib uri=/tags/struts-logic prefix=logic % logic:redirect page=/logic-forward.do/ 1.1 jakarta-struts/web/examples/exercise/logic-redirect-test-forward.jsp Index: logic-redirect-test-forward.jsp === %@ taglib uri=/tags/struts-logic prefix=logic % logic:redirect forward=logic-forward/ 1.1 jakarta-struts/web/examples/exercise/logic-redirect-test-action.jsp Index: logic-redirect-test-action.jsp === %@ taglib uri=/tags/struts-logic prefix=logic % logic:redirect action=/logic-forward/ 1.1 jakarta-struts/web/examples/exercise/logic-forward.jsp Index: logic-forward.jsp === %@ taglib uri=/tags/struts-html prefix=html % html head titleTest struts-logic:forward and struts-logic:redirect Tags/title /head body div align=center h1Test struts-logic:forward and struts-logic:redirect Tags/h1 /div pThe following links should return to this page./p ul lia href=logic-forward.do?value=testStandard hyperlink back to this page/a/li lihtml:link action=/logic-forward-test-forward?value=testForward to this page/html:link/li lihtml:link action=/logic-redirect-test-forward?value=testRedirect to this page, via forward attribute/html:link/li lihtml:link action=/logic-redirect-test-page?value=testRedirect to this page, via page attribute/html:link/li liRedirect to this page, via action attribute [:TODO:]/li /ul hr / ul li html:link forward=relativeTaglibs Exercise welcome page/html:link /li /ul /body /html 1.1 jakarta-struts/web/examples/exercise/logic-forward-test-forward.jsp Index: logic-forward-test-forward.jsp === %@ taglib uri=/tags/struts-logic prefix=logic % logic:forward name=logic-forward / 1.1 jakarta-struts/web/examples/exercise/html-img.jsp Index: html-img.jsp === %@ taglib uri=/tags/struts-html prefix=html % html head titleTest struts-html:img Tag/title /head body div align=center h1Test struts-html:img Tag/h1 /div table border=1 cellspacing=2 cellpadding=4 align=center tr td Standard img tag /td td img src=struts-power.gif /td /tr td Struts img tag via page attribute /td td html:img page=/struts-power.gif / /td /tr tr td Struts img tag via action attribute /td td [:TODO:] %-- html:img action=/struts-power / --% /td /tr /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validating Formatted Numbers Patch [Bugzilla 26151]
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: [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]
cvs commit: jakarta-struts build-webapps.xml
husted 2004/01/15 19:54:52
Modified:.build-webapps.xml
Log:
Add test pages for html:img and logic:forward,redirect tags
Revision ChangesPath
1.26 +3 -0 jakarta-struts/build-webapps.xml
Index: build-webapps.xml
===
RCS file: /home/cvs/jakarta-struts/build-webapps.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- build-webapps.xml 8 Jan 2004 16:24:47 - 1.25
+++ build-webapps.xml 16 Jan 2004 03:54:52 - 1.26
@@ -125,6 +125,9 @@
!-- Copy validator-rules.xml for the Struts examples application --
copy tofile=${build.home}/examples/WEB-INF/validator-rules.xml
file=${basedir}/conf/share/validator-rules.xml/
+!-- Copy required image for the Struts examples exercise module --
+copy tofile=${build.home}/examples/exercise/struts-power.gif
+file=${doc.dir}/images/struts-power.gif/
!-- Copy required image for the Struts examples validator module --
copy tofile=${build.home}/examples/validator/struts-power.gif
file=${doc.dir}/images/struts-power.gif/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 03:57 --- Do you have handy an Action that returns an image, so that we could test the change? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validating Formatted Numbers Patch [Bugzilla 26151]
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 http://hotjobs.sweepstakes.yahoo.com/signingbonus -- --- To unsubscribe, e-mail: struts-dev- [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el/doc/userGuide struts-bean-el.xml struts-html-el.xml struts-logic-el.xml struts-tiles-el.xml
rleland 2004/01/15 20:10:58 Modified:contrib/struts-el/doc/userGuide struts-bean-el.xml struts-html-el.xml struts-logic-el.xml struts-tiles-el.xml Log: Update tlibversion to read 1.2 Revision ChangesPath 1.7 +1 -1 jakarta-struts/contrib/struts-el/doc/userGuide/struts-bean-el.xml Index: struts-bean-el.xml === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/doc/userGuide/struts-bean-el.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- struts-bean-el.xml27 Nov 2003 22:07:44 - 1.6 +++ struts-bean-el.xml16 Jan 2004 04:10:58 - 1.7 @@ -12,7 +12,7 @@ taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamebean/shortname display-nameStruts Bean Tags/display-name 1.23 +1 -1 jakarta-struts/contrib/struts-el/doc/userGuide/struts-html-el.xml Index: struts-html-el.xml === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/doc/userGuide/struts-html-el.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- struts-html-el.xml27 Nov 2003 22:07:44 - 1.22 +++ struts-html-el.xml16 Jan 2004 04:10:58 - 1.23 @@ -12,7 +12,7 @@ taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamehtml/shortname display-namePage Construction Tags/display-name 1.7 +1 -1 jakarta-struts/contrib/struts-el/doc/userGuide/struts-logic-el.xml Index: struts-logic-el.xml === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/doc/userGuide/struts-logic-el.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- struts-logic-el.xml 27 Nov 2003 22:07:44 - 1.6 +++ struts-logic-el.xml 16 Jan 2004 04:10:58 - 1.7 @@ -11,7 +11,7 @@ taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamelogic/shortname display-nameStruts Logic Tags/display-name 1.3 +1 -1 jakarta-struts/contrib/struts-el/doc/userGuide/struts-tiles-el.xml Index: struts-tiles-el.xml === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/doc/userGuide/struts-tiles-el.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- struts-tiles-el.xml 27 Nov 2003 22:07:44 - 1.2 +++ struts-tiles-el.xml 16 Jan 2004 04:10:58 - 1.3 @@ -14,7 +14,7 @@ !-- == Tag Library Description Elements = -- - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnametiles/shortname display-nameTiles Tag Library/display-name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide struts-bean.xml struts-html.xml struts-logic.xml struts-nested.xml struts-tiles.xml
rleland 2004/01/15 20:12:07 Modified:doc/userGuide struts-bean.xml struts-html.xml struts-logic.xml struts-nested.xml struts-tiles.xml Log: Update tlibversion to read 1.2 Revision ChangesPath 1.19 +1 -1 jakarta-struts/doc/userGuide/struts-bean.xml Index: struts-bean.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-bean.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- struts-bean.xml 17 Sep 2003 18:54:25 - 1.18 +++ struts-bean.xml 16 Jan 2004 04:12:06 - 1.19 @@ -11,7 +11,7 @@ taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamebean/shortname display-nameStruts Bean Tags/display-name 1.69 +1 -1 jakarta-struts/doc/userGuide/struts-html.xml Index: struts-html.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v retrieving revision 1.68 retrieving revision 1.69 diff -u -r1.68 -r1.69 --- struts-html.xml 9 Jan 2004 14:00:14 - 1.68 +++ struts-html.xml 16 Jan 2004 04:12:06 - 1.69 @@ -15,7 +15,7 @@ taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamehtml/shortname display-namePage Construction Tags/display-name 1.18 +1 -1 jakarta-struts/doc/userGuide/struts-logic.xml Index: struts-logic.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-logic.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- struts-logic.xml 2 Jan 2004 11:55:38 - 1.17 +++ struts-logic.xml 16 Jan 2004 04:12:06 - 1.18 @@ -10,7 +10,7 @@ taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamelogic/shortname display-nameStruts Logic Tags/display-name 1.25 +1 -1 jakarta-struts/doc/userGuide/struts-nested.xml Index: struts-nested.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-nested.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- struts-nested.xml 30 Dec 2003 17:13:13 - 1.24 +++ struts-nested.xml 16 Jan 2004 04:12:06 - 1.25 @@ -9,7 +9,7 @@ body taglib - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnamenested/shortname display-nameStruts Nested Tags/display-name 1.12 +1 -1 jakarta-struts/doc/userGuide/struts-tiles.xml Index: struts-tiles.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-tiles.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- struts-tiles.xml 11 Sep 2003 21:31:23 - 1.11 +++ struts-tiles.xml 16 Jan 2004 04:12:06 - 1.12 @@ -13,7 +13,7 @@ !-- == Tag Library Description Elements = -- - tlibversion1.0/tlibversion + tlibversion1.2/tlibversion jspversion1.1/jspversion shortnametiles/shortname display-nameTiles Tag Library/display-name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: why are form beans required for html:form?
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 / -Ted. On Thu, 15 Jan 2004 09:45:41 -0600, Joe Germuska wrote: At 8:25 AM -0700 1/15/04, [EMAIL PROTECTED] wrote: I think this is a great idea. We often use buttons on the form for navigation between inquiry/dispaly pages which requires that we use a default formbean. Maybe you could add the attributre to the action noded of the struts config file instead of making it a custom tag attribute? This would allow you to let the request processor do the check and instantiate a base/dummy action form. Then you wouldn't have to refactor the tag libraries? I suppose this might sound like a kluge. Gary: which is the great idea? Using some config param to make the form optional? Or just making it optional in general? I'm not sure what the dummy form is for, unless the form wasn't optional. I'm wondering if I might not also like behavior that also let you use HTML form tags in the absence of a backing form bean; just skip the re-filling instead of throwing an error. That would allow us to have non-programmers flesh out JSPs including forms with the right Struts tags at any time ahead of programmers coming along and implementing the form pieces. They're already familiar with substituting html:* for input type=* in production apps, but they aren't ready to do a lot of struts-config work defining form beans and action mappings. Would people object to reworking the form tags for more graceful degradation at all levels in the absence of a form bean, instead of exception throwing? Joe Gary VanMatre -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 7:09 AM To: Struts Developers List Subject: RE: why are form beans required for html:form? At 8:59 PM -0700 1/14/04, Richard Hightower wrote: how about another attribute, i.e., html:form checkFormBean=false ... The checkFormBean defaults to true so it is backwards compatible with other versions. I like the idea that html:form checks for the form bean. It makes it easier to debug the way it is. However, I can see when you would not want that Well, I'm figuring that if you actually NEED the form bean, then something else would throw an exception; presumably the first input tag which isn't backed by some explicitly named bean. I'd probably leave out the parameter in preference of error checking at the right spot. I think what Ted was getting at in his email was that other tags might not be doing good error checking because they've always deferred to html:form -- and yes, it would be bad to remove the check and then start having NPEs thrown that might be much harder to debug. 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: struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validating Formatted Numbers Patch [Bugzilla 26151]
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. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 9:10 PM To: Struts Developers List Subject: RE: Validating Formatted Numbers Patch [Bugzilla 26151] 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 http://hotjobs.sweepstakes.yahoo.com/signingbonus -- --- To unsubscribe, e-mail: struts-dev- [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] - To unsubscribe, e-mail: [EMAIL
Re: Feedback on xml-filtering for message parameters (#26112) ?
We've been quite negligent when it comes to patches. There's at least 26 outstanding, the eldest dating to October 2002. As soon we roll out 1.2.0, handling these, one way or the other, is my next priority. -Ted. On Thu, 15 Jan 2004 14:25:54 +, Roberto Tyley wrote: If anyone with a bit of experience has got a second, could they venture a one-line opinion on the patch I submitted for #26112? The xml-filtering for message parameters is only a minor feature, and I'd just like to know if what I'm submitting is ok, whether the feature itself is just a dumb idea, or if I should just be more patient :-) Cheers, Roberto http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26112 --- - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. - 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]
cvs commit: jakarta-struts/web/examples/exercise logic-forward.jsp
husted 2004/01/15 20:55:00
Modified:doc/userGuide struts-logic.xml
src/share/org/apache/struts/taglib/logic RedirectTag.java
web/examples/WEB-INF/exercise struts-config.xml
web/examples/exercise logic-forward.jsp
Log:
Resolve #26133 logic:redirect tag lacks action attribute, suggested by
(Firepica)
Revision ChangesPath
1.19 +17 -0 jakarta-struts/doc/userGuide/struts-logic.xml
Index: struts-logic.xml
===
RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-logic.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- struts-logic.xml 16 Jan 2004 04:12:06 - 1.18
+++ struts-logic.xml 16 Jan 2004 04:55:00 - 1.19
@@ -1573,6 +1573,23 @@
same query parameter name will be created./p
/info
+attribute
+ nameaction/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ info
+ pLogical name of a global codeAction/code that
+ contains the actual content-relative URI of the
destination
+ of this transfer. This hyperlink may be dynamically
+ modified by the inclusion of query parameters, as
described
+ in the tag description. You strongmust/strong specify
+ exactly one of the codeaction/code attribute, the
+ codeforward/code attribute, the
+ codehref/code attribute,
+ or the codepage/code attribute./p
+ /info
+ /attribute
+
attribute
nameanchor/name
requiredfalse/required
1.22 +20 -5
jakarta-struts/src/share/org/apache/struts/taglib/logic/RedirectTag.java
Index: RedirectTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/RedirectTag.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- RedirectTag.java 10 Jan 2004 21:03:32 - 1.21
+++ RedirectTag.java 16 Jan 2004 04:55:00 - 1.22
@@ -155,6 +155,20 @@
}
/**
+ * The module-relative action (beginning with a slash) which will be
+ * called by this link
+ */
+protected String action = null;
+
+public String getAction() {
+return (this.action);
+}
+
+public void setAction(String action) {
+this.action = action;
+}
+
+/**
* The single-parameter request parameter name to generate.
*/
protected String paramId = null;
@@ -311,7 +325,7 @@
forward,
href,
page,
-null,
+action,
params,
anchor,
true,
@@ -356,6 +370,7 @@
href = null;
name = null;
page = null;
+action = null;
paramId = null;
paramName = null;
paramProperty = null;
1.3 +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.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- struts-config.xml 16 Jan 2004 03:51:31 - 1.2
+++ struts-config.xml 16 Jan 2004 04:55:00 - 1.3
@@ -38,6 +38,7 @@
/action
action path=/logic-forward forward=/logic-forward.jsp /
action path=/logic-forward-test-forward
forward=/logic-forward-test-forward.jsp /
+action path=/logic-redirect-test-action
forward=/logic-redirect-test-action.jsp /
action path=/logic-redirect-test-forward
forward=/logic-redirect-test-forward.jsp /
action path=/logic-redirect-test-page
forward=/logic-redirect-test-page.jsp /
1.2 +1 -1 jakarta-struts/web/examples/exercise/logic-forward.jsp
Index: logic-forward.jsp
===
RCS file: /home/cvs/jakarta-struts/web/examples/exercise/logic-forward.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- logic-forward.jsp 16 Jan 2004 03:52:15 - 1.1
+++ logic-forward.jsp 16 Jan 2004 04:55:00 - 1.2
@@ -11,9 +11,9 @@
ul
lia href=logic-forward.do?value=testStandard hyperlink back to this
DO NOT REPLY [Bug 26133] - logic:redirect 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=26133. 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=26133 logic:redirect tag lacks action attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
u, hmmm. snip This could answer the case where the target property is not a String (or boolean). /snip imho, people who dont use strings exclusively in their AFs deserve whatever is coming to them... ;- Seriously though, I dont think I like the idea of changing the form and view population methodology too much. snip 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 /snip Especially if this necessitates changes to the logic required to render the values out again. One of the advantages of keeping everything buffered in the ActionForm is that using a bean as the input buffer makes it nice and easy to find and render these values back into the html in pretty much all the rendering technologies. It also means even if you are using JSP (shudder) you dont have to stuff around checking several places for a value to render the field with when your not using struts tags. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, 16 January 2004 12:21 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26184] New: - Update UploadResources_ja.properties
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=26184. 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=26184 Update UploadResources_ja.properties Summary: Update UploadResources_ja.properties Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Example AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] src/examples/org/apache/struts/webapp/upload/UploadResources_ja.properties # :FIXME: We need a JA translaction of maxLengthExplanation Please use the following attached file. You can just replace old UploadResources_ja.properties with it. Thaks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26184] - Update UploadResources_ja.properties
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=26184. 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=26184 Update UploadResources_ja.properties --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 06:13 --- Created an attachment (id=9972) Updated UploadResources_ja.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
