DO NOT REPLY [Bug 14471] - validator-rules.xml JavaScript fails when field not present in jsp
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=14471. 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=14471 validator-rules.xml JavaScript fails when field not present in jsp --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 12:35 --- I was thinking of pushing it deeper -- down into validation.xml as a field optional attribute. That way, the server side can also be clued in to the possibility of a field not being present. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23370] - Unable to validate indexed 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=23370. 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=23370 Unable to validate indexed properties --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 14:37 --- Thank you Jim... Yes, it seems pretty much the same thing. The worst thing about this bug, is sometimes it works... so, I can't predict what it is exactly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23337] - 'integer' rule doesn't work properly with indexed 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=23337. 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=23337 'integer' rule doesn't work properly with indexed properties [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||23370 nThis|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14471] - validator-rules.xml JavaScript fails when field not present in jsp
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=14471. 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=14471 validator-rules.xml JavaScript fails when field not present in jsp [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 16:07 --- Why can't the 'page' attribute in the validator.xml, be used for multi-page validations ? This seems to work cleanly for the struts-validator example. I am going to close this tricket as Invalid, but if there is a use case that this doesn't work for then please reopen this ticket, and attach the use case. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23391] New: - scaffold RelayAction: allow defined relay parameter name
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=23391. 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=23391 scaffold RelayAction: allow defined relay parameter name Summary: scaffold RelayAction: allow defined relay parameter name Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] org.apache.struts.scaffold.RelayAction currently requires the use of dispatch (Tokens.DISPATCH)as the request parameter name to use when finding an ActionForward. This is okay, but RelayAction would be hard to plug into an existing Struts application that used a different parameter name (like method, as suggested in Mr Husted's book, no less!). So, why not allow RelayAction to do something like this: action path=/savecustomerrelay type=org.apache.struts.scaffold.RelayAction name=customerForm validate=false scope=request parameter=method forward name=save path=/savecustomerdispatch.do redirect=false / forward name=cancel path=website.welcome redirect=false / /action Now, method is being used because it is set as the ActionMapping's parameter attribute. If parameter isn't specified, then RelayAction should fall back to dispatch. Also, some logging for debugging purposes would be nice, like what relay name is being used and a dump of the found ActionForward. So, a patch is to follow. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23391] - scaffold RelayAction: allow defined relay parameter name
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=23391. 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=23391 scaffold RelayAction: allow defined relay parameter name --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 17:30 --- Created an attachment (id=8334) set relay param name in config and use commons-logging - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23355] - DynaActionForm should have getInteger, getBoolean, 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=23355. 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=23355 DynaActionForm should have getInteger, getBoolean, etc [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 17:33 --- Adding these would encourage a behavior that Struts discourages -- using non-String data types in a form bean. The problem with using such things is that you can't redisplay the user input if they typed 1a3 instead of 123 in a field backed by an int or a java.lang.Integer. You're perfectly free to define something like this in your own extension of the fundamental DynaBean APIs for use in transfer objects. But it does not belong on DynaActionForm. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14471] - validator-rules.xml JavaScript fails when field not present in jsp
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=14471. 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=14471 validator-rules.xml JavaScript fails when field not present in jsp --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 17:37 --- The big reason is that my form is not used in a multi-page layout. It is a single form that represents one of 4-5 objects (all with the same base class). I have nested:equals tags to sub in subclass-specific data with the majority used by all. The page attribute would never work in this case. Even requiredIf and when are lacking and/or add large amounts of difficult-to-maintain business logic tied to the UI (and not in the business layer). I have already added a few custom tags (w/ associated Java and CDATA to support client/server validation) for processing a collection of checkboxes (generalized so that it allows for 'none', 'any', 'all', and - in the case of 2 - 'xor'). I've even added a custom tag to force some CDATA into the generated HTML that does no validation -- only initializes the page based on what it thinks is there. Much of this (save the booleanCompare) would not be necessary if Struts cleanly supported a 'variable' page content as opposed (rather in addition) to the multi-page wizard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23355] - DynaActionForm should have getInteger, getBoolean, 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=23355. 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=23355 DynaActionForm should have getInteger, getBoolean, etc --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 18:24 --- I used to think that using ints and booleans on web-forms *was* the recommended approach. Anyway, I guess the problem is that conversion and validation are mixed where they shouldn't be. This is an area of improvement that remains open. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14471] - validator-rules.xml JavaScript fails when field not present in jsp
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=14471. 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=14471 validator-rules.xml JavaScript fails when field not present in jsp [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 02:49 --- See prior comments for usage. Not really a use case...but I'm too tired at the moment to flush out a good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Editable Fields V/S Static Text
Has anyone considered a feature which toggles between an editable form element and read only text / static text. I find myself developing JSPs where depending on the Use Case fieldA could be an editalbe text box (input name=fieldA value=My Text Value /) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case 2 (My Text Value) on the same jsp. Presently I am using the logic:equal/logic:equal tags. Which get really messy. Here is some sample code. logic:equals name=actionForm property=myFieldEditable value=true html:text name=actionForm propertymyField / /logic:equal logic:equals name=actionForm property=myFieldEditable value=false bean:write name=actionForm propertymyField / /logic:equal It would be nice to add an attribute to the current tag libraries, which is a boolean, and does this toggling for you. Here is what I am envisioning If actionForm.myField = My Text Value; This tag html:text name=actionForm propertymyField readOnlyText=true/ would output My Text Value. Where html:text name=actionForm propertymyField readOnlyText=false/ the following tag would output input name=fieldA value=My Text Value / As you can imagine this would not be a huge undertaking to add this feature to the current tag libraries in struts. I could use this feature, and I am sure other could too. I am willing to contribute my time to the development effort. I am not stuck on the attribute name readOnlyText, and would welcome suggestions. Does this sound like a good idea, and if the answer is yes, what is the next step. Chris Gastin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]