Re: URL validation - anyone using it?
On 03/13/2004 07:46 AM [EMAIL PROTECTED] wrote: From: Adam Hardy I provide URL validation on a page which saves links for users. I put together the latest build of commons-validator (1.1.2) and struts (1.2) to see what the URL validation is like. The class for server-side validation is in place, but the javascript doesn't exist. It works very strictly, too strictly for me. Most users will want to save links such as http://www.google.com http://jakarta.apache.org/ http://marc.theaimsgroup.com/?l=struts-userm=105511005106573w=2 This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they still pass ? My guess is that it might not be expecting the '/' after the domain name. This would probably only require a small tweak to the regular expression thats used. I would apply any patches that were submitted I'm running the tests on the Validator via ant and I get this exception straight away. I assume that the bad date is a test date that is meant to fail - but I can't figure out the reason why junit is falling over. I've only got brief experience with junit and I'm not finding the relevant code. Thanks for any pointers, Adam [echo] Running tests ... [java] . [java] ..F...F...ValidatorTest.formatDate() - Unparseable date: 2/30/1999 [java] . [java] Mar 15, 2004 9:49:58 AM org.apache.commons.validator.ValidatorAction executeValidationMethod [java] SEVERE: Unhandled exception thrown during validation: RUNTIME-EXCEPTION [java] java.lang.RuntimeException: RUNTIME-EXCEPTION [java] at org.apache.commons.validator.TestValidator.validateRaiseException(TestValidator.java:53) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:324) [java] at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:570) -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL validation - anyone using it?
That's simply the result of another testcase that proves exception handling works as documented. Validator is logging the exception and passing it out to the caller. David --- Adam Hardy [EMAIL PROTECTED] wrote: On 03/13/2004 07:46 AM [EMAIL PROTECTED] wrote: From: Adam Hardy I provide URL validation on a page which saves links for users. I put together the latest build of commons-validator (1.1.2) and struts (1.2) to see what the URL validation is like. The class for server-side validation is in place, but the javascript doesn't exist. It works very strictly, too strictly for me. Most users will want to save links such as http://www.google.com http://jakarta.apache.org/ http://marc.theaimsgroup.com/?l=struts-userm=105511005106573w=2 This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they still pass ? My guess is that it might not be expecting the '/' after the domain name. This would probably only require a small tweak to the regular expression thats used. I would apply any patches that were submitted I'm running the tests on the Validator via ant and I get this exception straight away. I assume that the bad date is a test date that is meant to fail - but I can't figure out the reason why junit is falling over. I've only got brief experience with junit and I'm not finding the relevant code. Thanks for any pointers, Adam [echo] Running tests ... [java] . [java] ..F...F...ValidatorTest.formatDate() - Unparseable date: 2/30/1999 [java] . [java] Mar 15, 2004 9:49:58 AM org.apache.commons.validator.ValidatorAction executeValidationMethod [java] SEVERE: Unhandled exception thrown during validation: RUNTIME-EXCEPTION [java] java.lang.RuntimeException: RUNTIME-EXCEPTION [java] at org.apache.commons.validator.TestValidator.validateRaiseException(TestValidator.java:53) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:324) [java] at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:570) -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL validation - anyone using it?
From: Adam Hardy I provide URL validation on a page which saves links for users. I put together the latest build of commons-validator (1.1.2) and struts (1.2) to see what the URL validation is like. The class for server-side validation is in place, but the javascript doesn't exist. It works very strictly, too strictly for me. Most users will want to save links such as http://www.google.com http://jakarta.apache.org/ http://marc.theaimsgroup.com/?l=struts-userm=105511005106573w=2 This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they still pass ? My guess is that it might not be expecting the '/' after the domain name. This would probably only require a small tweak to the regular expression thats used. I would apply any patches that were submitted -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17667 Client-side validation with multi-form page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 23:32 --- This is fixed in the Nightly build of Validator as of March 9th. It may take a few days for the nightly build of Struts to start using this version, and so it's client side validation will be broken until that point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page
This is fixed in the Nightly build of Validator as of March 9th. It may take a few days for the nightly build of Struts to start using this version, and so it's client side validation will be broken until that point. I'm picking up the most recent changes for tonight's nightly build. Obviously, this is not a situation we really want, even for a nightly build. I hope we'll see an updated validator dot-dot release soon to pick up the fix. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 17667 - Client-side validation with multi-form page
OK sorry. No I haven't tried it - I only use server side validation. I was just following a message on the user list, found myself reading that bug and saw your note asking for a reminder after 1.2 was out - so I sent you one. - Original Message - From: Robert Leland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 6:01 AM Subject: Re: Bug 17667 - Client-side validation with multi-form page Thanks, you do want to remind me via the struts-dev list. That way if someone else gets free time first to apply the patch, or disagres with it they can object. I'll make time this weekend to reapply it. Have you tried the patch ? -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 3, 2004 12:45 AM To: [EMAIL PROTECTED] Subject: Bug 17667 - Client-side validation with multi-form page Rob, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667 I was just following a thread from the user list and came accross this bug with a request to remind you when Struts 1.2.0 was out (so that you could apply a patch). Niall - 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 26639] - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639 Multipart request parameters lost after validation failure --- Additional Comments From [EMAIL PROTECTED] 2004-02-29 14:00 --- Turns out that this is not directly related to 26675, which was a simple bug in the conversion of the RequestProcessor functionality into chain commands which hadn't been put to the test. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27317] New: - Server-side validation not called when validate=true
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=27317.
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=27317
Server-side validation not called when validate=true
Summary: Server-side validation not called when validate=true
Product: Struts
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have validation=true on a savePerson action-mapping. The client-side
JavaScript works fine to notify the user that firstName and lastName are
required fields - but the server-side validation never kicks in. This used to
work fine in the nightly build I had from December. I added some code to my
Action to verify that there were errors is validate() was called on my form:
errors = personForm.validate(mapping, request);
if (!errors.isEmpty()) {
log.debug(ERROORSS);
}
And when I run this, in my console I get:
PersonAction.save(89) | Entering 'save' method
PersonAction.save(100) | ERROORSS
I guess I'll back out the 1.2 upgrade and go back to the nightly build from
December. ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27317] - Server-side validation not called when validate=true
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=27317. 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=27317 Server-side validation not called when validate=true [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-28 20:36 --- Nevermind, I'm an idiot. I had the editPerson as my action instead of savePerson. (Bangs head against wall... thud, thud, thud) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validation working, but not stopping action from processing
I'm using the 1.2.0 test build on Windows XP.
I have the following XDoclet-generated action-mapping:
action
path=/savePerson
type=org.appfuse.webapp.action.PersonAction
name=personForm
scope=request
input=validationFailed
parameter=action
unknown=false
validate=true
forward
name=validationFailed
path=/editPerson.do
redirect=false
/
forward
name=edit
path=.personDetail
redirect=false
/
/action
When I click on a button to save my form, the validation kicks in -
but it let's my Action continue to execute. I thought that any
validation errors were supposed to call mapping.getInputForward()? Is
that correct? I'm stumped. Here's my save() method:
public ActionForward save(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
if (log.isDebugEnabled()) {
log.debug(Entering 'save' method);
}
// Extract attributes and parameters we will need
ActionMessages messages = getMessages(request);
PersonForm personForm = (PersonForm) form;
boolean isNew = (.equals(personForm.getId()));
if (log.isDebugEnabled()) {
log.debug(saving person: + personForm);
}
// Exceptions are caught by ActionExceptionHandler
PersonManager mgr = (PersonManager) getBean(personManager);
personForm = (PersonForm) mgr.savePerson(personForm);
// add success messages
if (isNew) {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.added,
personForm.getFirstName() +
+
personForm.getLastName()));
request.getSession().setAttribute(Globals.MESSAGE_KEY,
messages);
return mapping.findForward(mainMenu);
} else {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.updated,
personForm.getFirstName() +
+
personForm.getLastName()));
saveMessages(request, messages);
return mapping.findForward(edit);
}
}
The validation routes the user back to the form, but it also calles
mgr.savePerson and puts the message in the requestion. So on my page, I
end up with the following messages:
'First Name' is a required field.
'Last Name' is a required field.
Information for has been updated successfully.
Hopefully I'm just banging my head against the wall and it's something
simple...
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validation working, but not stopping action from processing
It's one of those days... As soon as I send something to this list, I
figure it out. The problem was my validationFailed forward was not
resetting the action parameter for my dispatch action and it was
hitting save even when it failed. I change the input attribute to
edit (removing the validationFailed forward) and it solved my problem.
If you're reading these - thanks for putting up with me. ;0)
Matt
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 28, 2004 1:56 PM
To: '[EMAIL PROTECTED]'
Subject: Validation working, but not stopping action from processing
I'm using the 1.2.0 test build on Windows XP.
I have the following XDoclet-generated action-mapping:
action
path=/savePerson
type=org.appfuse.webapp.action.PersonAction
name=personForm
scope=request
input=validationFailed
parameter=action
unknown=false
validate=true
forward
name=validationFailed
path=/editPerson.do
redirect=false
/
forward
name=edit
path=.personDetail
redirect=false
/
/action
When I click on a button to save my form, the validation
kicks in - but it let's my Action continue to execute. I
thought that any validation errors were supposed to call
mapping.getInputForward()? Is that correct? I'm stumped.
Here's my save() method:
public ActionForward save(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
if (log.isDebugEnabled()) {
log.debug(Entering 'save' method);
}
// Extract attributes and parameters we will need
ActionMessages messages = getMessages(request);
PersonForm personForm = (PersonForm) form;
boolean isNew = (.equals(personForm.getId()));
if (log.isDebugEnabled()) {
log.debug(saving person: + personForm);
}
// Exceptions are caught by ActionExceptionHandler
PersonManager mgr = (PersonManager) getBean(personManager);
personForm = (PersonForm) mgr.savePerson(personForm);
// add success messages
if (isNew) {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.added,
personForm.getFirstName() + +
personForm.getLastName()));
request.getSession().setAttribute(Globals.MESSAGE_KEY, messages);
return mapping.findForward(mainMenu);
} else {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.updated,
personForm.getFirstName() + +
personForm.getLastName()));
saveMessages(request, messages);
return mapping.findForward(edit);
}
}
The validation routes the user back to the form, but it also
calles mgr.savePerson and puts the message in the requestion.
So on my page, I end up with the following messages:
'First Name' is a required field.
'Last Name' is a required field.
Information for has been updated successfully.
Hopefully I'm just banging my head against the wall and it's
something simple...
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validation working, but not stopping action from processing
--- Matt Raible [EMAIL PROTECTED] wrote:
It's one of those days... As soon as I send something to this list, I
figure it out. The problem was my validationFailed forward was not
resetting the action parameter for my dispatch action and it was
hitting save even when it failed. I change the input attribute to
edit (removing the validationFailed forward) and it solved my problem.
If you're reading these - thanks for putting up with me. ;0)
I try to read all validator related posts and yours have been quite
entertaining ;-). Thanks for testing 1.2.0!
David
Matt
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 28, 2004 1:56 PM
To: '[EMAIL PROTECTED]'
Subject: Validation working, but not stopping action from processing
I'm using the 1.2.0 test build on Windows XP.
I have the following XDoclet-generated action-mapping:
action
path=/savePerson
type=org.appfuse.webapp.action.PersonAction
name=personForm
scope=request
input=validationFailed
parameter=action
unknown=false
validate=true
forward
name=validationFailed
path=/editPerson.do
redirect=false
/
forward
name=edit
path=.personDetail
redirect=false
/
/action
When I click on a button to save my form, the validation
kicks in - but it let's my Action continue to execute. I
thought that any validation errors were supposed to call
mapping.getInputForward()? Is that correct? I'm stumped.
Here's my save() method:
public ActionForward save(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
if (log.isDebugEnabled()) {
log.debug(Entering 'save' method);
}
// Extract attributes and parameters we will need
ActionMessages messages = getMessages(request);
PersonForm personForm = (PersonForm) form;
boolean isNew = (.equals(personForm.getId()));
if (log.isDebugEnabled()) {
log.debug(saving person: + personForm);
}
// Exceptions are caught by ActionExceptionHandler
PersonManager mgr = (PersonManager) getBean(personManager);
personForm = (PersonForm) mgr.savePerson(personForm);
// add success messages
if (isNew) {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.added,
personForm.getFirstName() + +
personForm.getLastName()));
request.getSession().setAttribute(Globals.MESSAGE_KEY, messages);
return mapping.findForward(mainMenu);
} else {
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage(person.updated,
personForm.getFirstName() + +
personForm.getLastName()));
saveMessages(request, messages);
return mapping.findForward(edit);
}
}
The validation routes the user back to the form, but it also
calles mgr.savePerson and puts the message in the requestion.
So on my page, I end up with the following messages:
'First Name' is a required field.
'Last Name' is a required field.
Information for has been updated successfully.
Hopefully I'm just banging my head against the wall and it's
something simple...
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen) - watch out for ActionErrors - ActionMessages in validation code
I notice that the most recent version of your splendid two-fields
validator (looking in CVS at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/struts/appfuse/src/web/
org/appfuse/webapp/util/ValidationUtil.java) still has the ActionErrors
class in it's method signature:
boolean validateTwoFields(Object bean, ValidatorAction va, Field field,
ActionErrors errors, HttpServletRequest request)
However, you can get some nasty silent errors from struts if you do
this, as the 'errors' variable won't be populated (it'll be null, due to
struts now expecting it to be the ActionMessages class), and when the
null pointer exception occurs in your method (when you attempt to report
a validation error), it will cause some difficult-to-diagnose errors
higher up the stack.
For a bit more insight into the nullness of the 'errors' variable, look
at the initValidator() method in the Resources class:
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/st
ruts/validator/Resources.java
The ActionErrors-ActionMessages change occurred somewhere around rev
1.22 of that class.
The updated version of your validateTwoFields method looks like this:
public static boolean validateTwoFields(
Object bean,
ValidatorAction va,
Field field,
ActionMessages errors,
HttpServletRequest request) {
String value1 = ValidatorUtils.getValueAsString(bean,
field.getProperty());
String sProperty2 = field.getVarValue(secondProperty);
String value2 = ValidatorUtils.getValueAsString(bean,
sProperty2);
try {
boolean equal = GenericValidator.isBlankOrNull(value1) ?
GenericValidator.isBlankOrNull(value2) : value1.equals(value2);
if (!equal) {
errors.add(field.getKey(),
Resources.getActionMessage(request, va, field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionMessage(request, va, field));
return false;
}
return true;
}
(I also corrected a small bug at line 44 of the old method where
value1=null, value2='some text' would validate ok!).
Best regards,
Roberto
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: 25 February 2004 09:15
To: 'Struts Developers List'
Subject: RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)
The first thing I noticed is that struts-el is missing from the
download. I used the one I had from a nightly build in December and it
didn't seem to cause conflicts.
I tried 1.2.0 in AppFuse and all tests pass! Nice work gents. I didn't
even have to modify any files - my last Struts update was December 2,
2003.
Matt
--- -
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]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |2.0 Family --- Additional Comments From [EMAIL PROTECTED] 2004-02-20 15:04 --- I don't understand why this was changed to 'enhancement' as it is a bug - it doesn't work properly. I classed it as 'major' because allowing invalid data seems serious to me - I could accept a down grading to 'normal', but its not an enhacement for sure. Anyway I changed the severity back to 'major' Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-02-19 20:28 --- Apparently, I only thought I applied it. I tried again, but now I'm having trouble applying the patch for some reason. Could you run the patch again or send me the patched file directly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates --- Additional Comments From [EMAIL PROTECTED] 2004-02-18 00:31 --- Ted, You changed this to RESOLVED/FIXED, but the patch hasn't been applied yet - just wondering if you forgot to apply or didn't yet intend to - or is the status/resolution a mistake? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26486] - enhance required and other validation actions for form reuse
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=26486. 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=26486 enhance required and other validation actions for form reuse --- Additional Comments From [EMAIL PROTECTED] 2004-02-15 19:31 --- Is there any reason why ValidatorActionForm and DynaValidatorActionForm don't serve this purpose? They look up validator forms by the action path, not the form name, allowing you to have different validation rules for the same form bean used in different contexts. http://jakarta.apache.org/struts/api/org/apache/struts/validator/ValidatorActionForm.html http://jakarta.apache.org/struts/api/org/apache/struts/validator/DynaValidatorActionForm.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-13 11:25 --- Thanks, Niall! If you were able to drum up a test instance for the examples/validator application demonstrating that the validator will not stop at the first null value for indexed fields, we'd be happy to have that as well. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates --- Additional Comments From [EMAIL PROTECTED] 2004-02-13 12:01 --- I know you are right and I did have a quick look at doing that hoping to copy an existing struts validator test - but unfortunately there arn't any and I haven't used junit before. I am snowed under with my current project at the moment, but will try have a go at a test in the next couple of weeks, but its not a promise. I did set up my own small test harness and I tested each of the FieldChecks methods I changed with a valid value, an invalid value a blank value and a null value. I also run tests for the Date and Integer validations in my current struts project verifying that indexed fields failed with a nightly build, but passed when I switched in the patched version of FieldChecks. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
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=26873. 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=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2004-02-12 13:59 --- Thanks for your comments. Niall, I am hitting the submit button in the browser. So, why is this not a bug in this case? Please explain. I still think it is a bug unless it is supposed to work this way. Joe, I am passing an Action in the input field. But this is just a fix.I tried passing a JSP to the input field, but whenever the validation error occured, all attributes I had put in request scope were gone. Only form data was present. Therefore to fix this problem I had to pass an action and put the attrubutes in request scope again. It doesnt matter if I pass an action or jsp , it always removes the request scope attributes. I havent tried with tiles. Thanks Garima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
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=26873. 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=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2004-02-12 17:00 --- Garima, You need to close this bug and mark the resolution as INVALID and then go and ask this question on the User list or read the documentation. The people who develop and maintain Struts put in alot of effort for free so that users like you and me can get this great software for free. The least we can do is not waste their time by asking questions in the right place. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
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=26873. 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=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates --- Additional Comments From [EMAIL PROTECTED] 2004-02-13 02:24 --- Created an attachment (id=10347) Change validate methods to return boolean rather than object - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable --- Additional Comments From [EMAIL PROTECTED] 2004-02-13 02:27 --- OK I added a patch changing FieldChecks so that it doesn't return the validated value but a boolean instead. If the value is blank/null it returns 'true' to indicate valid. This means that validator will not now stop at the first null value for indexed fields, but carry on validating the other indexed values - rather than letting through invalid values - which was a serious problem. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | Version|1.1 Final |Nightly Build --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 14:51 --- Sorry I didn't get back to you earlier. I have now tried this using the nightly build from 10th Feb 20004 and the problem is still exists. In fact this problem occurs in all the FieldChecks validations that return null if the value is null. From looking at the source validateByte(), validateShort (), validateInteger(), validateLong(), validateFloat(), validateDouble() and validateCreditCard() are all affected by the same issue. I tried it out for the integer validation and it didn't work properly either for indexed fields. I think the best solution is for all these methods to just return a boolean rather than the value they are validating - and return 'true' (i.e. valid) if the value is blank or null. What do you think - if I do a patch on this basis would you be willing to commit it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] New: - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
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=26873. 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=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping Summary: Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping Product: Struts Version: 1.1 Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of Actionmapping When a validation error occurs in a DynaValidatorForm, it is observed that all request scope attributes, except the Form data are lost after the input page is reloaded. The Input page is specified in the input attribute of action mapping. For example in ViewDetailFormAction I set some request attributes by request.setAttribute(list, MyList); Now I hit submit on the ViewDetailForm which validates the data through validation.xml. If there are no errors, it works fine. But if there is an error, and it tries to reload the page, a message that the list is not in scope appears. However if this is put in session, it works fine and all form data appears as before. This means that Form data is preserved but request scope data is not preserved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
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=26873. 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=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 23:17 --- Is your input path an Action? Routing to an action causes the request processing chain to be re-fired, which generally causes exactly what you described. If you can change your input path to be a tile or a JSP, you won't have this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26873] - Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping
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=26873. 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=26873 Validation error in DynaValidatorForm does not maintain request scope attributes when forwarding to the page defined in the input attribute of ActionMapping --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 23:39 --- Garima, When you say Now I hit submit on the ViewDetailForm ... it makes me think you are talking about when you are in the browser you are clicking on the submit button - is that the case? If it is then, this is a very simple question for the user list - not a bug. If its not then what do you mean by now I hit submit? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:51 --- Marking as INVALID pending confirmation that the issue persists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26639] - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639 Multipart request parameters lost after validation failure [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Keywords||PatchAvailable Target Milestone|--- |1.2.1 Milestone --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:00 --- Marking this as an enhancement for 1.2.1. We should be switching to the command-based RequestProcessor soon, and we can consider this change in that context. We've been seeing a lot of issues specific to file uploading. Perhaps we need a specialized request processor catalog for applications that utilize file uploading. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26639] - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639 Multipart request parameters lost after validation failure --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:03 --- See also #26675. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26639] New: - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639
Multipart request parameters lost after validation failure
Summary: Multipart request parameters lost after validation
failure
Product: Struts
Version: 1.1 Final
Platform: PC
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This happens when the input attribute of an action is set to another .do
instead of a jsp page. The form has enctype set and after validation failure
request becomes empty.
Here is how I solved this in RequestProcessor:
Note that getAllParametersForMultipartRequest() was copied from RequestUtils.
protected boolean processValidate(HttpServletRequest request,
HttpServletResponse response,
ActionForm form,
ActionMapping mapping)
throws IOException, ServletException {
if (form == null) {
return (true);
}
// Was this request cancelled?
if (request.getAttribute(Globals.CANCEL_KEY) != null) {
if (log.isDebugEnabled()) {
log.debug( Cancelled transaction, skipping validation);
}
return (true);
}
// Special handling for multipart request
if (form.getMultipartRequestHandler() != null) {
// Handle repopulation of parameters.
MultipartRequestWrapper wrapper = (MultipartRequestWrapper)
request;
if(request.getAttribute(PARSED_MULTIPART_REQUEST) != null){
Map params = (Map)request.getAttribute
(PARSED_MULTIPART_REQUEST);
// Populate fresh request.
Iterator iter = params.keySet().iterator();
while (iter.hasNext()) {
String key = (String) iter.next();
Object value = params.get(key);
if(value instanceof String[]){
String[] val = (String[]) value;
if(val.length 0){
System.out.println
( Setting parameter + key + to + val[0]);
wrapper.setParameter
(key, val[0]);
}
}
}
}
else{
// Retrive form values and put into properties.
Map multipartParameters = getAllParametersForMultipartRequest(
request, form.getMultipartRequestHandler());
request.setAttribute(PARSED_MULTIPART_REQUEST,
multipartParameters);
}
}
return super.processValidate(request, response, form, mapping);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667 Client-side validation with multi-form page --- Additional Comments From [EMAIL PROTECTED] 2004-02-03 18:20 --- Thanks Matt, I have applied this patch locally but since it requires a change to both struts and Validator to work, I can't commit it just yet. If I apply it to Commons-validator Commons-Validator will no longer work with nightly build of Struts. So once Struts 1.2.0 is out could you remind us to apply this patch ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667 Client-side validation with multi-form page --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 16:31 --- Created an attachment (id=10184) Update to patch latest version (1.44) of JavascriptValidatorTag.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17667 Client-side validation with multi-form page --- Additional Comments From [EMAIL PROTECTED] 2004-02-02 16:32 --- Created an attachment (id=10185) Patch the javascript in individual .js files in Commons Validator instead of in validator-rules.xml in struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26486] New: - enhance required and other validation actions for form reuse
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=26486. 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=26486 enhance required and other validation actions for form reuse Summary: enhance required and other validation actions for form reuse Product: Struts Version: 1.1 Final Platform: Other URL: http://jakarta.apache.org/commons/dtds/validator_1_1.dtd OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The registration form is the example used often. What should a programmer do if a registered user later can change her/his profile? My assumption would be to re-use the same form since the fields are almost identical? Except that in this case, a user should no longer be able to change the login name or for example a once chosen price plan that last several month as per the TC. When using validator actions in this scenario, I expect several problems to occur: Depending on the the form's action context (e.g. registerAction.do or changeProfileAction.do) 1) a field required in one context is not required in another (or even not allowed in the other) 2) if both form action contexts are using a wizard, the page number for a particular field may not be the same? Conclusion -- Suggestion: == - the required value of the depends attribute might better be an attribute to a rule element that has an action attribute and page attribute? e.g. your example fieldproperty=lastName depends=required,mask page=1 msg name=mask key=registrationForm.lastname.maskmsg/ arg0 key=registrationForm.lastname.displayname/ var var-namemask/var-name var-value^[a-zA-Z]*$/var-value /var /field ... fieldproperty=email depends=required,email page=2 arg0 key=registrationForm.email.displayname/ /field could then be fieldproperty=lastName rule required action=registerAction page=1 / rule required action=changeProfileAction page=2 / rule mask action=registerAction page=1 / rule mask action=changeProfileAction page=3 / msg name=mask key=registrationForm.lastname.maskmsg/ arg position=0 key=registrationForm.lastname.displayname/ var var-namemask/var-name var-value^[a-zA-Z]*$/var-value /var /field ... field property=emailLogin page=2 rule required action=registerAction / rule email action=registerAction / !-- no need to have an unchanged rule since changeProfileAction.java would not act upon an emailLogin form field submitted by a browser anyway -- arg position=0 key=registrationForm.email.displayname/ /field What do you think? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
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=26413. 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=26413 Indexed Field Date Validation Allows Invalid Dates --- Additional Comments From [EMAIL PROTECTED] 2004-01-27 09:43 --- Please confirm that the problem exists against the nightly build. If the problem persists, please also provide a patch that implements the proposed solution. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
DO NOT REPLY [Bug 26151] New: - 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 Summary: Optionally specify patterns for byte, short, int, long, float, double validation Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I would like to be able to specify a 'pattern' [for example #,##0;(#,##0)] for number validation. I am attaching patches which do this for the existing byte, short, integer, long, float and double validations. An optional 'numberPattern' variable causes the number to be parsed using DecimalFormat. I have also added a section to the Validator user guide, which details the standard validations shipped with struts and it includes an examples showing their variables and how to use them. One thing this patch doesn't do, is cater for these patterns in the javascript validation - sorry I know v.little about javascript. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19161] - validateDate javascript validation doesn't handle non-strict date parsing
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=19161. 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=19161 validateDate javascript validation doesn't handle non-strict date parsing [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||22703 nThis|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19161] - validateDate javascript validation doesn't handle non-strict date parsing
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=19161. 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=19161 validateDate javascript validation doesn't handle non-strict date parsing [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16810] - Javascript Date validation for datePattern not supported
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=16810. 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=16810 Javascript Date validation for datePattern not supported [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 22:59 --- See #22384 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16249] - localized float 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=16249. 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=16249 localized float validation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Keywords||PatchAvailable Priority|Other |High Resolution|LATER | Target Milestone|--- |1.2 Family --- Additional Comments From [EMAIL PROTECTED] 2003-12-19 00:33 --- Reopening for handling in 1.2.x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25421] New: - [VALIDATOR] radio button validation with javascritp
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=25421. 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=25421 [VALIDATOR] radio button validation with javascritp Summary: [VALIDATOR] radio button validation with javascritp Product: Struts Version: 1.1 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Critical Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, guys I have some problems validating multiple radio buttons and checkboxes, selections on the client side. Tracking down to the javascript code defined in validator-rules.xml, I found that the validateRequired(form) function doesn't deal with multiple checkboxes, selections at all. For multiples radios, checkboxes etc, the field.type = undefined. I try to use a nightly build, but nothing diff happend. On the server side, the validation is normal. If you it will be able to answer me, would be very grateful. I am annexing jsp, validation.xml and struts-config.xml you to analyze. tks! **deleteme.jsp** ** %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % html:html HEAD BODY html:errors / html:form action=/saida2 onsubmit=return validateDeleteme(this); method=get FIELDSET TITLE=r1 html:checkbox property=r1 value=r1 r1/html:checkbox br html:checkbox property=r1 value=r2 r2/html:checkbox br html:checkbox property=r1 value=r3 r3/html:checkbox br html:checkbox property=r1 value=r4 r4/html:checkbox br html:checkbox property=r1 value=r5 r5/html:checkbox br /FIELDSET html:submit / /html:form /BODY /html:html **deleteme.jsp** ** **struts- config.xml ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.1//EN http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd; !-- This is a blank Struts configuration file with an example welcome action/page and other commented sample elements. Tiles and the Struts Validator are configured using the factory defaults and are ready-to-use. NOTE: If you have a generator tool to create the corresponding Java classes for you, you could include the details in the form-bean declarations. Otherwise, you would only define the form-bean element itself, with the corresponding name and type attributes, as shown here. -- struts-config !-- Data Source Configuration -- !-- data-sources data-source set-property property=autoCommit value=false/ set-property property=description value=Example Data Source Configuration/ set-property property=driverClass value=org.postgresql.Driver/ set-property property=maxCount value=4/ set-property property=minCount value=2/ set-property property=password value=mypassword/ set-property property=url value=jdbc:postgresql://localhost/mydatabase/ set-property property=user value=myusername/ /data-source /data-sources -- !-- Form Bean Definitions -- !-- O formulário contém os campos com as seguintes validações: * Nome (requerido, pode somente ser
DO NOT REPLY [Bug 25421] - multiple radio button javascript validation broken
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=25421. 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=25421 multiple radio button javascript validation broken [EMAIL PROTECTED] changed: What|Removed |Added Summary|[VALIDATOR] radio button|multiple radio button |validation with javascritp |javascript validation broken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25421] - multiple radio button javascript validation broken
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=25421. 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=25421 multiple radio button javascript validation broken [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-11 00:56 --- When you emailed me personally I asked you to please try a nightly build. This has been fixed if you look in the validator example program there is a demo of multiple radio checkboxes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
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=24202. 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=24202 Javascript validation fails for single radio and single checkbox --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 15:09 --- Yes, checkbox makes more sense in this case. For a single radio button, it's just more a matter of convience. Say, my jsp is supposed to render a group of radio buttons dynamically pulled from a database. But, Sometimes there is just only one record in the database, so there will be only one radio button rendered in the jsp. If the Validator framework can take care of this, I don't have to deal with the required validation specifically in the jsp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
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=24202. 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=24202 Javascript validation fails for single radio and single checkbox --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 15:27 --- You should never be rendering only a single radio button because it's a huge usability issue. The user can never uncheck a single radio button once they've checked it. In this case, you should probably be using a different form control like a select box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
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=24202. 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=24202 Javascript validation fails for single radio and single checkbox --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 15:55 --- Yes, if it can be replaced by a select box. But here is a situation: Template is required to proceed in the application. A template has a title, a description, and a thumnail image. A select box doesn't seem to work well in the case of both a single and multiple records. (0) Template one - Some template description | thumbnail image 1 | - (0) Template two - Some other description | thumbnail image 2 | - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
--- Additional Comments From [EMAIL PROTECTED] 2003-10-31 15:27 --- You should never be rendering only a single radio button because it's a huge usability issue. The user can never uncheck a single radio button once they've checked it. In this case, you should probably be using a different form control like a select box. These are excellent points, and the question becomes is this boundary condition a useability should or a technical must. HTML spec is no help, I looked. It talks about sets, but doesn't define set as two or more. I'm having horrible visions of someone doing a query driven voting application using radio boxes... Those aside, IMHO think the utility of having the trivial case handled in the framework is more useful than having application logic check for it, and is generally worth a useability tradeoff. Ernie Argetsinger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
--- [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 15:27 --- You should never be rendering only a single radio button because it's a huge usability issue. The user can never uncheck a single radio button once they've checked it. In this case, you should probably be using a different form control like a select box. These are excellent points, and the question becomes is this boundary condition a useability should or a technical must. HTML spec is no help, I looked. It talks about sets, but doesn't define set as two or more. It also talks about this specific usability problem. I'm having horrible visions of someone doing a query driven voting application using radio boxes... Those aside, IMHO think the utility of having the trivial case handled in the framework is more useful than having application logic check for it, and is generally worth a useability tradeoff. I'm -0 on adding single radio button support to validator. I won't add it myself but won't stand in the way of someone who wants to spend the time. Good usability is *always* a requirement on my projects and never takes a backseat to laziness. Poor usability is one of my biggest pet peeves on major websites. IMO, the correct thing to do in this case is to not display a form control at all. There's only one choice so just display that choice and tell the user that's what they're getting. David Ernie Argetsinger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
[EMAIL PROTECTED] wrote: I'm having horrible visions of someone doing a query driven voting application using radio boxes... AHA! So *that* is how the old communist regimes always got 99.9% positive votes in their elections ... :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
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=24202. 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=24202 Javascript validation fails for single radio and single checkbox [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 06:10 --- I have fixed the checkbox but not the radio button. For the single checkbox I could see a use such as I have read this license agreement. However, I know of no use case for the radio button. This will be in the Nov 1 Nightly build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox
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=24202. 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=24202 Javascript validation fails for single radio and single checkbox --- Additional Comments From [EMAIL PROTECTED] 2003-10-29 15:06 --- Created an attachment (id=8803) A Patch file for fixing bug24202 - single radio button and checkbox js validation problem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24202] New: - Javascript validation fails for single radio and single checkbox
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=24202. 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=24202 Javascript validation fails for single radio and single checkbox Summary: Javascript validation fails for single radio and single checkbox Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The client side javascript validation works fine for multiple radio buttons and multiples checkboxes, but it doesn't work when there is only a single radio and a single checkbox - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16810] - Javascript Date validation for datePattern not supported
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=16810. 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=16810 Javascript Date validation for datePattern not supported --- Additional Comments From [EMAIL PROTECTED] 2003-09-26 16:31 --- Actually, I can't validate dates whether I put in a date pattern or not. If I don't put in a lt;vargt; section for datePattern then the variable doesn't exist at all. If I do, then the variable init section of the javascript (function DateValidations) still returns null. It defines the var as this.datePattern, so I'm wondering if that's why. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16810] - Javascript Date validation for datePattern not supported
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=16810. 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=16810 Javascript Date validation for datePattern not supported --- Additional Comments From [EMAIL PROTECTED] 2003-09-26 16:41 --- Sorry, didn't mean to put in the dependency on 22384. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18993] - Add required JavaScript validation for multiple selects and checkboxes
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=18993. 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=18993 Add required JavaScript validation for multiple selects and checkboxes This bug depends on bug 11520, which changed state: What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18993] - Add required JavaScript validation for multiple selects and checkboxes
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=18993. 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=18993 Add required JavaScript validation for multiple selects and checkboxes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-24 03:41 --- Fixed in Nightly build, for Sept 24. Based on patches provided by Greg Ludington, Steve Stair, Saul Q Yuan Add ability of required to handle checkboxes, radio,select-one, and select-multiple field types. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18993] - Add required JavaScript validation for multiple selects and checkboxes
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=18993. 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=18993 Add required JavaScript validation for multiple selects and checkboxes [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12776] - validation order is incorrect
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=12776. 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=12776 validation order is incorrect [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 02:33 --- I believe this has been resolved in the current release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16810] - Javascript Date validation for datePattern not supported
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=16810. 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=16810 Javascript Date validation for datePattern not supported [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 02:49 --- Reopening for handling. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18993] - Add required JavaScript validation for multiple selects and checkboxes
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=18993. 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=18993 Add required JavaScript validation for multiple selects and checkboxes --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 03:22 --- I am modifying the struts-validator example app so I can test these out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23179] New: - No javascript required validation for multiples checkboxes and multiple selection dropdown list
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=23179. 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=23179 No javascript required validation for multiples checkboxes and multiple selection dropdown list Summary: No javascript required validation for multiples checkboxes and multiple selection dropdown list Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] No javascript (client side) required validation for multiples checkboxes and multiple selection dropdown list. While the server side required validation works great for both. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18993] - Add required JavaScript validation for multiple selects and checkboxes
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=18993. 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=18993 Add required JavaScript validation for multiple selects and checkboxes [EMAIL PROTECTED] changed: What|Removed |Added Summary|required JavaScript |Add required JavaScript |validation doesn't work with|validation for multiple |multiple selects in Netscape|selects and checkboxes |4.61| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23179] - No javascript required validation for multiples checkboxes and multiple selection dropdown list
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=23179. 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=23179 No javascript required validation for multiples checkboxes and multiple selection dropdown list [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-09-15 16:56 --- *** This bug has been marked as a duplicate of 18993 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18993] - Add required JavaScript validation for multiple selects and checkboxes
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=18993. 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=18993 Add required JavaScript validation for multiple selects and checkboxes [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-09-15 16:56 --- *** Bug 23179 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Integrating data type conversion and page validation.
I'm trying to convert string posts into type specific java objects for pushing straight into my database. I don't want the hastle/bloat of maintaining two suites of objects/fields one with strings, one with type specific objects. I can see how to use ConvertUtils to map strings to objects, and extend the tag libs simply to get the rendering behaviour I want. However, I can't see an elegant way to handle conversion failures. I want something akin to The property you specified is not a valid type in my ActionErrors so I can render this generically. But it seems there's no way of accessing the property name that's being converted from inside my converter. Of course I'd need this information to do the aforementioned. I think there should be no separation of validation and type conversion, I can't see why they shouldn't be done together. Should BeanUtils be extended to cater for this? Regards, Graham Bygrave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integrating data type conversion and page validation.
On Wednesday, August 27, 2003, at 11:28 AM, Bygrave, Graham BGI UK wrote: I'm trying to convert string posts into type specific java objects for pushing straight into my database. I don't want the hastle/bloat of maintaining two suites of objects/fields one with strings, one with type specific objects. I can see how to use ConvertUtils to map strings to objects, and extend the tag libs simply to get the rendering behaviour I want. However, I can't see an elegant way to handle conversion failures. I want something akin to The property you specified is not a valid type in my ActionErrors so I can render this generically. But it seems there' s no way of accessing the property name that's being converted from inside my converter. Of course I'd need this information to do the aforementioned. I think there should be no separation of validation and type conversion, I can't see why they shouldn't be done together. Should BeanUtils be extended to cater for this? i'd say that the answer to this question is: 'yes but' 'yes' it should be possible for a user to plug in an exception handling strategy that'll allow this kind of information to be propergated 'but' something like that needs care taking with the design. beanutils has a very large installed based and we take backwards compatibility very seriously. this means taking some care to make sure that any new abstractions are correct since they will be difficult to change later. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22687] New: - Indexed Property Validation - javascript non-javascript
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=22687. 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=22687 Indexed Property Validation - javascript non-javascript Summary: Indexed Property Validation - javascript non- javascript Product: Struts Version: 1.1RC2 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When an indexed property is validated (which apparently cannot happen at all for javascript validations - I checked the CVS), only one error is identified for each validation type. There should be an error for each bad field. With the current implementation, there is no way for the user to identify the source of the problem since it could be any one (or more) of the repeating items. The comment in the javascript tag that indicates why there is no javascript for this case indicates that the messages can't be identified. The right thing to do seems to be either to give an error parm that is the field string itself. The other choice seems to me to be that you could specify a identification property in the xml that shows which item is failing. For example, suppose an indexed object (using nested tags) has a property called lastName that is being validated. If it is required and missing, there is nothing to put in the message. But if there is a field in the iterator that is generated, account number or indexid (at worst), then that could be specified to be placed in the error message. No matter what, it does not seem fair to make the user fix the same error with additional round-trips when we have obviously already analyzed the error for all of the iterations. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22687] - Indexed Property Validation - javascript non-javascript
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=22687. 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=22687 Indexed Property Validation - javascript non-javascript --- Additional Comments From [EMAIL PROTECTED] 2003-08-25 16:19 --- There seems to have been some work on allowing the validation to continue with an extension to the validation.dtd, but that is not the heart of my problem It is the lack of specificity in the messages (and, of course, that the javascript does not get activated at all for indexed properties - not in the documentation at all). If these should be separate bug requests, I would like some advice. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] - page attribute in the Validation Config file
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=22145. 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=22145 page attribute in the Validation Config file --- Additional Comments From [EMAIL PROTECTED] 2003-08-18 16:47 --- Created an attachment (id=7874) I added a int[] pages field with getter, setter, and containsPage methods. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] - page attribute in the Validation Config file
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=22145. 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=22145 page attribute in the Validation Config file --- Additional Comments From [EMAIL PROTECTED] 2003-08-18 16:48 --- Created an attachment (id=7875) Class uses new containsPage method in Field to check the page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] - page attribute in the Validation Config file
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=22145. 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=22145 page attribute in the Validation Config file --- Additional Comments From [EMAIL PROTECTED] 2003-08-18 16:50 --- Created an attachment (id=7876) Added pages attribute to the field element - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] - page attribute in the Validation Config file
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=22145. 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=22145 page attribute in the Validation Config file --- Additional Comments From [EMAIL PROTECTED] 2003-08-18 16:55 --- Created an attachment (id=7878) Added call to Field.containsPage() to check if the page exists in the fields. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] - page attribute in the Validation Config file
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=22145. 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=22145 page attribute in the Validation Config file --- Additional Comments From [EMAIL PROTECTED] 2003-08-18 17:12 --- The above attachments are my proposal for adding this new functionality of pages instead of page on fields: 7874: Field.java I added an int[] pages field with getPages(), setPages(String pages), and containsPage(int page) methods. It is backwards compatible with getPage() and setPage(int page) using index 0 of the int[]. The containsPage(int page) method checks through the int[] to see if page is there. The pages field still defaults to one page of 0 like the old page field did. This means that you can still use the page attribute in your validation config file for a field with one page, but you can use the pages attribute with comma-seperated pages to be used by more than one page. 7875: Validator.java The Validator uses the new containsPage(int page) method in Field to check if the forms page is found in the Fields pages int[]. Before, it checked if the form page was = the Field's page, but now it the form page must be in the Field's pages. 7876: validator_1_1.dtd Added pages attribute to the field element. 7878: Added call to Field.containsPage(int page) to check if the form's page exists in the field's pages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15912] - Client-side validation fails if not all form-fields are specified on page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15912. 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=15912 Client-side validation fails if not all form-fields are specified on page [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 15:42 --- Reopening... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22476] New: - Javascript validation fails with two forms on one page.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22476. 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=22476 Javascript validation fails with two forms on one page. Summary: Javascript validation fails with two forms on one page. Product: Struts Version: 1.1 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm not to sure if this is a bug, probably more a limitation. I currently have a page (made up of several tiles) that contains two forms. Both of these forms require validation (both forms contain fields that are required). Form FOO is contained within tile A, at the end of tile A I call html:javascript formName=FOO staticJavascript=false /. Form BAR is containted within tile B, at the end of tile B I call html:javascript formName=BAR staticJavascript=false /. This results in two functions called required rendering to the page and the javascript validation breaks. Extra details: - The static javascript is rendered into the layout tile. - Happens in both Mozilla (Firebird) and IE 6. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22476] - Javascript validation fails with two forms on one page.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22476. 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=22476 Javascript validation fails with two forms on one page. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-08-15 23:55 --- *** This bug has been marked as a duplicate of 22462 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20432] - Validator returns nulls in JavaScript 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=20432. 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=20432 Validator returns nulls in JavaScript validation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-08-06 15:17 --- I'm using struts1.1 and I have the same error. When in an jsp I have : html:javascript formName=registrationForm dynamicJavascript=true staticJavascript=false/ script language=Javascript1.1 src=html:rewrite page='/staticJavascript.jsp'//script everytime I get : java.lang.NullPointerException at org.apache.struts.taglib.html.JavascriptValidatorTag.doStartTag (JavascriptValidatorTag.java:319) Any ideea ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22431] New: - Add time 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=22431. 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=22431 Add time validation Summary: Add time validation Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The date validator doesn't handle times on the client. Need a new validator to handle times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22431] - Add time 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=22431. 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=22431 Add time validation --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:22 --- Created an attachment (id=7825) Time JavaScript validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22431] - Add time 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=22431. 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=22431 Add time validation --- Additional Comments From [EMAIL PROTECTED] 2003-08-14 16:24 --- Created an attachment (id=7826) Time Java validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] New: - page attribute in the Validation Config file
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=22145.
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=22145
page attribute in the Validation Config file
Summary: page attribute in the Validation Config file
Product: Struts
Version: 1.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This is more of an enhancement:
We should be allowed to set the page attribute with comma-seperated pages so
that we do not have to define the same field validation more than once in a
form. Something like the following:
field property=description depends=maxlength page=1,2
arg0 key=resource.description/
arg1 name=maxlength key=${var:maxlength} resource=false/
var
var-namemaxlength/var-name
var-value255/var-value
/var
/field
The following could be done to do this:
CHANGE TO JavascriptValidatorTag.java
// Skip indexed fields for now until there is a good way to handle
// error messages (and the length of the list (could retrieve from scope?))
StringTokenizer st = new StringTokenizer(field.getPage(), ,);
boolean include = false;
while(st.hasMoreTokens()) {
if(page.equals(st.nextToken())) {
include = true;
}
}
if(field.isIndexed() || field.getPage() != page
|| !field.isDependency(va.getName())) {
continue;
}
Of course, page would have to be changed to a String in both Field and
JavascriptValidatorTag for this to work.
An even better idea would be to add the following functionality to Field:
int[] pages = new int[] {0};
public void setPages(String pages) throws NumberFormatException {
if(pages != null !pages.equal() !pages.equals(0)) {
StringTokenizer st = new StringTokenizer(pages, ,);
pages = new int[st.countTokens()];
for(int i = 0; i pages.length; i++) {
pages[i] = Integer.parseInt(st.nextToken());
}
}
}
public int[] getPages() {
return pages;
}
public boolean containsPage(int page) {
for(int i = 0; i pages.length; i++) {
if(page == pages[i]) {
return true;
}
}
return false;
}
Then, change JavascriptValidatorTag.java to:
// Skip indexed fields for now until there is a good way to handle
// error messages (and the length of the list (could retrieve from scope?))
if(field.isIndexed() || field.getPage() != page || !field.containsPage(page)
|| !field.isDependency(va.getName())) {
continue;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22145] - page attribute in the Validation Config file
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=22145. 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=22145 page attribute in the Validation Config file [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21760] New: - Add support for non-default resource bundles in 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=21760. 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=21760 Add support for non-default resource bundles in validation Summary: Add support for non-default resource bundles in validation Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is dependent on Bug #17543 be implemented in commons validator. The patches in that bug report basically add bundle attributes to the msg and arg tags. The following patches will use these new features to add the ability to draw from alternate resource bundles in the arg tags used in the validator framework. The validator example webapp is also modified to illustrate its use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21760] - Add support for non-default resource bundles in 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=21760. 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=21760 Add support for non-default resource bundles in validation --- Additional Comments From [EMAIL PROTECTED] 2003-07-21 08:16 --- Created an attachment (id=7414) validator framework files to add alternate bundle support - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21760] - Add support for non-default resource bundles in 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=21760. 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=21760 Add support for non-default resource bundles in validation --- Additional Comments From [EMAIL PROTECTED] 2003-07-21 08:18 --- Created an attachment (id=7416) extra bundles for validator example webapp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21599] - validation problem
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=21599. 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=21599 validation problem [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-15 13:39 --- There is no bundle attribute on the field element. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validation Indexed properties
I'm trying to validate a collection of objects such
that one of the properties generated html inputs looks
like:
input type=text name=assignmentForm[1].startDate
size=13 value=
I've defined the form-validation doc with the
following field block:
field property=startDate depends=date
msg key=errors.invalid.date name=date/
arg0 name=date
key=package.Assignment.startDate.label/
arg1 name=date key=${var:datePattern}
resource=false/
var
var-namedatePattern/var-name
var-valueMM/dd//var-value
/var
/field
unfortunately, the form doesn't seem to get validated.
I don't have this issue with non-indexed properties.
On a related note, the html:errors tag doesn't seem to
have an indexed boolean attribute. Will I be able to
access the error message specific to that index?
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21599] New: - validation problem
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=21599. 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=21599 validation problem Summary: validation problem Product: Struts Version: 1.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Example AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] at validaton.xml field property=password depends=required, minlength,maxlength bundle=alternate It seemed password will use the alternate resource file at AlternateApplicationResources.properties prompt.password=Enter your Password here == so it shoud show Enter your Password here == is required not Password is required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21509] New: - password fields are not subject to the Javascript minLength, maxLength mask validation rules
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=21509. 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=21509 password fields are not subject to the Javascript minLength, maxLength mask validation rules Summary: password fields are not subject to the Javascript minLength, maxLength mask validation rules Product: Struts Version: 1.1 Final Platform: PC OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Validator Framework AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The standard 'validator-rules.xml' file omits password fields in the Javascript sections of minLength, maxLength mask rules. It may be easily resolved by changing the present condition statement: if (field.type == 'text' || field.type == 'textarea') for the following one: if (field.type == 'text' || field.type == 'textarea' || field.type == 'password') - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21509] - password fields are not subject to the Javascript minLength, maxLength mask validation rules
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=21509. 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=21509 password fields are not subject to the Javascript minLength, maxLength mask validation rules [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |Medium - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21509] - password fields are not subject to the Javascript minLength, maxLength mask validation rules
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=21509. 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=21509 password fields are not subject to the Javascript minLength, maxLength mask validation rules [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 13:52 --- *** This bug has been marked as a duplicate of 12473 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A Custom tag using bean:message / and validation ...
I have made some more modifications to the LabelTag to make it more extensible. The way the tag works now is: doStartTag() - starts the span (if styles are applied) doAfterBody() - Determines which label to use (from the resource bundle or from the body content.) doEndTag() - ends the span (if styles are applied) Styles are still applied based on whether there is an error associated with the property. If anyone wants to use an '*' or any other symbol to the right or left of the label, just override the start or end tag. Erik: If you want, you can use just one attribute by overriding the setKey method and passing the key to the super's setProperty method; Thanks for helping refine this, Jonathan -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 2:56 PM To: Struts Developers List Subject: Re: A Custom tag using bean:message / and validation ... On Wednesday, June 25, 2003, at 02:01 PM, David Graham wrote: Struts doesn't have the luxury of living in one development shop. I understand your need for customizations for your particular conventions but we can't force them on others. So, we'll be ok as long as the Struts version provides some basic useful functionality and allows easy subclassing. Agreed! And +1 The main point I wanted to make here, just to clarify, is for us to always consider avoiding duplication and to clearly denote where we are doing so and why which you have done nicely. LabelTag is something Struts needs in some form or another... keep up the good work folks! Erik - 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: A Custom tag using bean:message / and validation ...
David - thanks for adding your thoughts to the issue. Now some more of
my thoughts to Jonathan's message...
On Wednesday, June 25, 2003, at 12:36 AM, DeRose Jonathan wrote:
1) Putting an '*' into a label for required fields assumes people want
an
'*', maybe they want a '(R)' or maybe they want something else entirely
(perhaps an image...).
Certainly a valid enhancement. Perhaps something with MessageFormat
would do the trick here, allowing the field value to be plugged into
another resource string ({0}*: or {0} (R)).
I'm not really going to be on board with all the generalizations being
made discussed here though. By generalizing it as much as David has
suggested, along with ideas being discussed here it would require more
than just this in our JSP's:
custom:label key=FormName.fieldName/
If the generalizations make more required in my JSP's then I'll stick
with my custom tag. In fact, even the form name is not needed, as I
discussed previously, in the key.
My tag also has another interesting feature. We store our message
resources in the database. When the user is logged in with a special
role (dev in our case) then the label tag outputs they key names
rather than their value (making it instantly apparent which text is
hard-coded into the JSP and which is put into the resources). That key
is also a hyperlink to a pop-up form allowing the user to enter a new
value for that resource key.
Another feature of my tag is that if the value of a key ends with '?'
then the colon is omitted. The label values do not contain colons, it
is automatically appended to all labels except questions, where a colon
separator looks a bit ugly.
2) Putting an '*' after a label for required fields assumes people
want an
'*' after the label. Perhaps they want the '*' before the label or
after
the actual input field. Consider the label 'Name:' with three text
boxes
for first, last, and middle. First and last might be required but
middle is
not. There is no clear way to mark first and last but not middle with
this
enhancement.
Yet another reason I'll stick with my custom version :)) You guys come
up with far too complex scenarios and its easier to just deal with this
our own way. If a built-in tag requires more work for JSP developers,
then no thanks - it'd be overkill for our purposes.
3) Forcing people to use the ResourceBundle to display labels requires
a lot
more effort for applications that have no internationalization
requirements.
For many web applications, html text is enough and does not require a
heavy
resource bundle to maintain or keep in memory.
No one would be forcing anyone to use such a tag. So I don't quite
understand your issue here. Simply hard-code the labels in the JSP's
if you like, which is what most folks, or use bean:message.
But we have applications that require user customization, and by
providing a means for them to edit the resources (again, they reside in
a database table) it takes us developers out of the loop and they can
edit them basically in-place on the screen using our dev role feature.
If there is a strong desire for an asterisk tag, why not just have a
tag
that takes a property and prints out an asterisk if it is required?
Certainly a simple tag that just does that would be useful for some
folks, sure. For us, its nice to roll the error checking, required
check, ?/: handling, and more all into a single tag.
Or even better, set up whatever symbol you want to show for required
fields
in the resource bundle, and then use that. html:required
property='form.element' /
EX: ApplicationResources.properties
html.required=*
-or-
html.required=(R)
-or-
html.required=IMG SRC=./required.gif
*ugh* - HTML in the properties file is something I'm definitely against.
I have proposed an enhancement that I think offers more flexibility
from the
error handling perspective:
* It allows for error styles, error classes, and error ids for labels
AND
for all of the input elements. (You could make the label 'Name:' red
and
bold, or you could make the name text box highlighted in red, or both)
It
allows developers to set up these styles once in the ResourceBundle
and be
used over the entire application
html.text.styleClass=text_input
html.text.errorStyleClass=red_text_input
* It allows you to group errors (a single error for 'SSN' can make the
'SSN:' label bold and highlight all three text inputs).
* The label tag wraps whatever specific label you want to use, whether
it is
a message from the ResourceBundle or just plain HTML.
It sounds like you've done a great job writing tag(s) for your
particular uses. I think, ultimately, we'll find that a generalized
tag will be fine for some folks, but just not enough for many of us.
Given what our tag does, I don't think we'd consider using a
lesser-featured built-in one (except maybe to subclass it if you guys
build it nicely enough! :).
I feel this offers the kind of flexibility and
RE: A Custom tag using bean:message / and validation ...
1) Putting an '*' into a label for required fields assumes people want an '*', maybe they want a '(R)' or maybe they want something else entirely (perhaps an image...). 2) Putting an '*' after a label for required fields assumes people want an '*' after the label. Perhaps they want the '*' before the label or after the actual input field. Consider the label 'Name:' with three text boxes for first, last, and middle. First and last might be required but middle is not. There is no clear way to mark first and last but not middle with this enhancement. The required field marking should be a tag attribute. 3) Forcing people to use the ResourceBundle to display labels requires a lot more effort for applications that have no internationalization requirements. For many web applications, html text is enough and does not require a heavy resource bundle to maintain or keep in memory. It does not require a lot more effort to use a resource bundle. One main reason Struts was created in the first place was to i18n applications easily. Many existing Struts tags require resource bundle keys and we should not allow new tags to just print out non-internationalized text. I've cross referenced each bug ticket so the final solution can merge the best ideas from each. David --- If there is a strong desire for an asterisk tag, why not just have a tag that takes a property and prints out an asterisk if it is required? Or even better, set up whatever symbol you want to show for required fields in the resource bundle, and then use that. html:required property='form.element' / EX: ApplicationResources.properties html.required=* -or- html.required=(R) -or- html.required=IMG SRC=./required.gif --- I have proposed an enhancement that I think offers more flexibility from the error handling perspective: * It allows for error styles, error classes, and error ids for labels AND for all of the input elements. (You could make the label 'Name:' red and bold, or you could make the name text box highlighted in red, or both) It allows developers to set up these styles once in the ResourceBundle and be used over the entire application html.text.styleClass=text_input html.text.errorStyleClass=red_text_input * It allows you to group errors (a single error for 'SSN' can make the 'SSN:' label bold and highlight all three text inputs). * The label tag wraps whatever specific label you want to use, whether it is a message from the ResourceBundle or just plain HTML. It does not handle pre-marking required fields--however I don't think any output should be hard-coded into Struts, where a modification of the tag (see above) to a more general one would do the trick and be a good addition. I feel this offers the kind of flexibility and extensibilty that I think Struts needs. Please check out this enhancement at http://issues.apache.org/bugzilla/show_bug.cgi?id=20784 Thanks, Jonathan -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:41 PM To: Struts Developers List Subject: Re: A Custom tag using bean:message / and validation ... Even if its not added to Struts (and there is a reason not to - it relies on naming conventions FormName.fieldName - which seem reasonable to me, but aren't mandated by Struts), its all yours to use. It makes sense to put it in some kind of sandbox or goodies/contrib area of the Struts codebase though. Erik, I really like the idea of the tag and I've added my suggestions for improvement to the bug report. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18015 Also, just a query, Does your tag extend MessageTag ? Is it a good idea to do that ? No, it doesn't. See here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/struts/ struts-resume/src/web/org/appfuse/webapp/taglib/ LabelTag.java?rev=HEADcontent-type=text/plain I personally do not find it worthwhile to extends Struts tags. They are not designed as I would have designed them (subclassses not exposing some parent class attributes in the TLD is *bad* IMHO) and the attributes on the MessageTag are not needed for my label tag. All I need is key, nothing else. I made some effort recently to refactor the tags into more appropriate chunks. While they're still not great for subclassing, they have improved. David Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
