DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2006-01-05 19:30 ---
See issue raised in Bug 37755 regarding default date pattern if not specified.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2005-10-30 17:39 ---
I ran into problems with the validateMask() calls on both IE and Firefox.  

The problem was fixed by changing calls like this:
if (!validateMask(field, /^\\$?\\d+(,\\d{3})*(\\.\\d{2})?$/)) {

to be like this:
if (!validateMask(field, eval("/^\\$?\\d+(,\\d{3})*(\\.\\d{2})?$/"))) {


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 23:22 ---
> Yes, that must be on my todo list :-)

That's what I thought.  But I was also thinking that asking the question here 
brings attention to this enhancement again, so I did. :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2005-10-21 23:04 ---
(In reply to comment #20)
> The version 1.0.8 TLD lists Multibox among its tags, but the
> o.a.s.t.v.MultiboxTag is not included in the download.

Yes, that must be on my todo list :-)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2005-10-20 05:13 ---
Niall,

This is nice work.
The version 1.0.8 TLD lists Multibox among its tags, but the
o.a.s.t.v.MultiboxTag is not included in the download.

Hubert

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-12-03 09:34 ---
Hi Niall,

> For me you still need to make the use-case for adding the additional 
> complexity. I don't see it as an issue to have to name fields uniquely on the 
> form - in fact it seems like a good thing to me.

I think the use-case is that Struts form handling permits arrays of strings (or
whatever). Before using Struts I found myself quite a few times having fields
named: text1, text2, text3... when what I really wanted was a single text-field
with multiple possible values. This is not a every-day use-case but it does
happen. The truth is that I've only used it with text-fields, but I thought that
it might be nice to have a general solution for all kinds of fields.

Also, if these functions do work properly, I think the complexity of validator
gets reduced as you can see in validateRequired and validateInteger I have
provided. 

> You could raise a bugzilla for this after this enhancement suggestion is 
> accepted - it might anoy some people if you raise one against a feature that 
> isn't yet in Validator ;-)

What I meant is that I am not sure I have placed this in the right place.
Really, what I am proposing fits in validator. The thing is that, since your
extension involves some js rewriting I thought it would be good to start a
debate on this.

> Also I'm still not sure how I'd integrate this into the javascript that this 
> extension is generating, but if it does get into validator you could submit a 
> patch with your bugzilla :-)

I am willing to help if necessary no matter what happens with my proposal. I
think your extension is a very good enhancement for validator.


Nacho

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-12-03 08:37 ---
I thought the extension was working for radio fields, but it was only for field 
validation, not form. I've incorporated part of Nacho's suggestions (thanks) to 
resolve this.

Version 1.0.8. now available.




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-12-03 00:08 ---
I've just uploaded version 1.0.7 here:

http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html

The main changes are re-factoring following the feed back from David Graham, 
including adding JUnit tests. More detailed description of whats changed since 
the last (1.0.5) version are here:

http://www.niallp.pwp.blueyonder.co.uk/validatorjsChanges.html

Niall

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-12-02 23:13 ---
Hi Nacho,

For me you still need to make the use-case for adding the additional 
complexity. I don't see it as an issue to have to name fields uniquely on the 
form - in fact it seems like a good thing to me.

You could raise a bugzilla for this after this enhancement suggestion is 
accepted - it might anoy some people if you raise one against a feature that 
isn't yet in Validator ;-)

Also I'm still not sure how I'd integrate this into the javascript that this 
extension is generating, but if it does get into validator you could submit a 
patch with your bugzilla :-)

Niall

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-12-02 14:40 ---
Hi Niall,

I see what you mean with the focus. There is a little trick we can use for this
and it's javascript's eval function. If we change the method
grabValuesFromField(oField) to validateField(oField, validatorFunction) then we
can apply the validations programatically in each iteration. We have to make
some minor changes for grabValuesFromSingleField which considers the radio or
checkbox fields an array of fields even when there is only one. For this, we
have to make a "virtual field" for the case when there is only one radio button
and convert it to a single element array of radios. Please do take a look at
http://www.visual-ma.com/validator/grab.html as it has the modified page. You
can choose the validation (currently there are only 2 validations: integer and
required) and validate on each field. 

BTW, do you think I should post this on a separate bug as an enhancement?

function validateRequired(values) {
var isValid = values.length > 0;
for (i=0; i= -2147483648 && iValue 
<= 2147483647)) {
isValid = false;
break;  
}
 }
 
}
return isValid;
}

(I am not putting the side functions (eg: isAllDigits, trim) for clarity)

function validateField(oField, validatorFunction) { 
if (!oField.type && oField.length && oField[0]) {
//if it has no type it means there are multiple fields with the 
same name. We
shall put the type
//for the field for easier handling
oField.type = oField[0].type;
oField.name = oField[0].name
}
var bValid = true;
var focusField = oField;
if (oField.type == 'radio' || oField.type == 'checkbox') {
var virtualField = oField;
if (!oField.length) {
virtualField = new Array();
virtualField.type = oField.type;
virtualField.name = oField.name;
virtualField[0] = oField;
}
eval("bValid = " + validatorFunction +
"(grabValuesFromSingleField(virtualField))");
//no need to focus on these
focusField = null;
} else if (oField.length && !oField.options) {
for (n=oField.length - 1; n>=0; n--) {//reverse so we can focus 
on the first
eval("var auxValid = " + validatorFunction +
"(grabValuesFromSingleField(oField[n]))");
if (!auxValid) {
//if it's not valid for a single element it 
won't be valid
bValid = auxValid;
focusField = oField[n];
}
}
} else {
eval("bValid = " + validatorFunction + 
"(grabValuesFromSingleField(oField))");
}
if (!bValid && focusField && focusField.focus && 
focusField.style.visibility !=
'hidden'
&& focusField.disabled == false && focusField.type != 'hidden') 
{
focusField.focus();
}
}

function grabValuesFromSingleField(oSingleField) {
var singleValues = new Array();
if (oSingleField.type == 'select-multiple') {
for (s=0; shttp://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-12-02 06:22 ---
Nacho,

I spent some time looking at your suggestion.

Catering for multiple fields with the same name breaks down the way you're 
suggesting because all the values are put into one array. If for example a 
second "text" field was invalid, focus would still be set to the first field. I 
thought about iterating over the fields and validaing each to overcome this - 
but that won't work for radios.

I came to the conclusion that having a restriction that fields on a form should 
be named differently is reasonable. In the case of radio fields that are named 
the same - the javascript validation seems to work fine (the "Tag Examples" has 
radio button example).

I'm not going to do anything about this, but if this gets into Commons 
Validator - you can always raise a bug ticket for this and maybe yourself or 
someone else will come up with a way/patch that makes this work and worthwhile.

Thanks anyway for your input.

Niall



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-29 03:13 ---
David,

First, thank you for taking the time to look at this and give feed back. I 
appreciate it alot :-)

> - I didn't see any JUnit test cases (not that I expected them during
> prototyping).  Before this is added we would need some good tests.

I don't want to disagree with this as I'm a big fan of tests, but as the 
generated script doesn't run in a java environment they have more limited value 
since any generated script would still need to be tested in a browser. I 
developed the example webapp initially to test it and believe it is the best 
tool to do so. Anyway, if its agreed to include the extension, I will develop 
JUnit tests.

> - Remove @author tags to match Validator conventions

No problem - I'll take them out.

> - As I understand it, validation is now hooked to onchange events which would 
be
> highly irritating as you navigate through a form.  Maybe I misunderstood this
> though?

No this isn't true, it becomes possible but its just an option. The Commons 
Validator part generates a "form validation" method which calls a bunch 
of "field validation" methods - so you can either validate a whole form or 
single field. The "customized" version of the struts tags I created 
generate "onchange" validation automatically - but thats just an example 
implementation. We would need a discussion in Struts about what features Struts 
provides but IMO this sort of thing should at most be available as an option.

> - How does this fit into the Validator 2.0 goal of moving from the javascript
> concept to a more generic script concept where the script might be python for
> non-web apps using validator?  Is there anything we need to do to make this
> proposal generic?  Maybe this is independent of that effort?

Good question and I have no knowledge of how that might work. However if we 
provide a mechanism for configuring a ScriptRenderer maybe someone could use 
that to plug in their own custom renderers that generate other script 
languages? They would have to navigate Validator's resources in the same way. I 
guess one option would be to split the ScriptRender into two with it just doing 
the generic processing and a JavaScriptRenderer implementation with the actual 
javascript generation. I can do this if you think it a good idea?

> ScriptRenderer
> - Why is pretty output a variable?  We should just simplify things and always
> print well formatted javascript.

I renamed this at the end of last week (but haven't fully tested a new version 
yet) and called it "compress" and it can now output the whole javascript on one 
line or in a "pretty" readable format. Appears to save around 10-20% and I 
believe is a useful option to have *full compression*.

> - Why do some methods throw NPE instead of just returning null?  Would the
> caller want null in some cases?

They were all things that needed to be there for it to work. Except for one 
static method, they could all be overriden in custom implementations if 
required.

> - isTrue() and setBooleanConfig() should compare 'true' and 'false' as lower
> case, not any case.  'TrUe' is not a valid Java boolean identifier and always
> checking for the lower cased forms simplifies the usage for the client.

But someone might expect "True" to work - maybe the simplest option is to 
always convert to lowercase when accepting input.

> - Make protected methods private.  This API is brand new and may need tweaking
> so we should make as much private as possible until it's stable.

This is the great thing about review - I'd not even considered that approach, I 
was focused on making everything as easily customized as possible. I'm happy to 
do it this way in an initial version so we could see how it works out.

> - Why have static methods? From past experience we know that people will want 
to
> override this behavior.

I tried to keep them to the bare minimum - in ScriptRenderer, except for the 
getRenderer() method it is only a few methods that do small well defined 
functions (enclosing in quotes, replacing values).

> - Why do we need String manipulation methods like replaceCharacters()?  
Wouldn't
> the replacement methods on the String class work?

Before 1.4 String only had replace(char, char) - the replaceCharacter() method 
I wrote replaces a char with a String - so that particular characters can 
be "escaped" the other replaceCharacters() method does multiple characters with 
Strings. Maybe this could be done with the Java 1.4 RegEx versions, but I'm not 
too good at Regex and don't think we should limit it to Java 1.4.

> -Why SCRIPT_VERSION variables?  The 'langua

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-28 21:12 ---
Here are my initial comments after reviewing some of the code.  I very much
appreciate how much effort was put into making this proposal easy to understand
:-).  We're getting closer to Commons Validator being easily used outside of 
Struts!

- I didn't see any JUnit test cases (not that I expected them during
prototyping).  Before this is added we would need some good tests.

- Remove @author tags to match Validator conventions

- As I understand it, validation is now hooked to onchange events which would be
highly irritating as you navigate through a form.  Maybe I misunderstood this
though?

- How does this fit into the Validator 2.0 goal of moving from the javascript
concept to a more generic script concept where the script might be python for
non-web apps using validator?  Is there anything we need to do to make this
proposal generic?  Maybe this is independent of that effort?

ScriptRenderer
- Why is pretty output a variable?  We should just simplify things and always
print well formatted javascript.

- Why do some methods throw NPE instead of just returning null?  Would the
caller want null in some cases?

- isTrue() and setBooleanConfig() should compare 'true' and 'false' as lower
case, not any case.  'TrUe' is not a valid Java boolean identifier and always
checking for the lower cased forms simplifies the usage for the client.

- Make protected methods private.  This API is brand new and may need tweaking
so we should make as much private as possible until it's stable.

- Why have static methods? From past experience we know that people will want to
override this behavior.

- Why do we need String manipulation methods like replaceCharacters()?  Wouldn't
the replacement methods on the String class work?

-Why SCRIPT_VERSION variables?  The 'language' attribute isn't part of newer
specs so why bother supporting it in this new code?

- Why pass Map context to every method?  This feels a bit procedural especially
in the set*Config() methods.  Could we just pass the context to the renderer
constructor to wrap it?

- Why do renderJavascriptStart() and renderJavascriptEnd() need hideScript and
xhtml parameters?  I think XHTML rendering should be a configuration option set
in the context that affects all js output without needing to pass boolean values
to the methods.  We could do the same for hideScript.

- Are there some constants in ScriptRenderer that can be made private as
implementation details of the class?  Do they all need to be public?

- What alternatives to using a Map context did you consider using?  It seems
like we may be mixing an execution context with configuration parameters.  We
used a bitwise ORing approach for configuration with UrlValidator:
http://jakarta.apache.org/commons/validator/apidocs/org/apache/commons/validator/UrlValidator.html

Would that make sense here too?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-26 18:39 ---
Nacho,

Yes - this would be a good improvement. I'm going away this weekend, so I'm not 
going to get time to think about or incorporate this until sometime next week.

Having said that, part of me would like to get it into commons validator first -
 others could then contributing/apply patches if they wanted and it wouldn't be 
just me doing the work :-)

Anyway, thanks for your input.

Niall

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-26 18:18 ---
I would like to suggest a different way of doing things with the client side
validation. If we make the different validators validate values instead of
fields, we would improve in code reusability and duplication. I'll try to 
explain:

Use a generic javascript function called grabValuesFromField(oField) (or
whatever) which returns an array (most of the times a 1 element array) of
strings with all values of the specified field. Then have the different
validators validate all values from the array making them easier to mantain and
more reusable. 

There is a common misconception when using html that states that the name of a
text field must be unique within a form. This is because IMHO javascript deals
with this issue erroneously: document.forms[0].textField.value should be
document.forms[0].textField[0].value. Most of the time there is one text field
for the same name, but with checkboxes or radio buttons this is not true. If you
use several text fields with the same name (which is absolutely necessary
sometimes) you need to loop through in a document.forms[0].textField[i] fashion
just like radios and checkboxes.

This is the main reason why radio and checkbox validations perform poorly
usually. I propose a first draft for this function:

function grabValuesFromField(oField) {
var values = new Array();
if ((oField.length) && (!oField.type || oField.type.indexOf('select') 
== -1)) {
//we have to push out the selects when they have a type because 
select.length
refers to options
for (n=0; nhttp://www.visual-ma.com/validator/grab.html 
The page is composed of two panels one with single fields and one with double
fields. If you click on grab you will get the number of values it has returned.
This is the number of values that should be passed to the validators. I know the
page is ugly and maybe quite confusing, specially after seeing Niall's... If
requested I'll improve it so we could have pseudo test cases.

Nacho G. Mac Dowell

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Validator] Javascript  |[validator] Javascript
   |Rendering Extension |Rendering Extension




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 16:17 ---
Thanks David, any time you give this is appreciated.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 15:36 ---
I couldn't get to the site you provided yesterday so I'll give this a look this
weekend.  IMO, the validwhen and requiredif validations could be replaced by
adding a javascript validator using Rhino.  That would provide the best
flexibility but is off topic for this bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 04:27 ---
Yah, I was just joking about the validwhen thing. I keep coming up with
different proposals to overhaul validwhen with an eye on making it more simple
and adding javascript validation, and they always wind up falling apart on me
for some reason. (And that is just on paper! I can't imagine what will happen to
me when I get something good enough that I attempt coding it...)

Thanks for adding the other bug fix, I hope what you've come up with does become
part of the base.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 04:19 ---
Ha, ha, validwhen isn't my baby - I just put a couple of fixes in for it. I 
need something along those lines for my day job and I'm thinking it would be 
easier to do both client and server sides if it were a set of validators.

The first in the set I'm thinking of is a "dateCompare" validator where you 
specify a test (equal, before after) and the field is compared either to 
another field's value or the current date (the test date) - with the option to 
add/subtract x number of days/weeks/months/years from the test date. The new 
version I posted earlier had some more re-factoring in the Date Validator - I 
separated the datePattern parsing into a separate method - thinking it could be 
re-used in something like this.

Then maybe a "logic" validator, along the lines of the logic tags, again where 
you sepecify another field to check against with a test (equal, notEqual, 
present, notPresent, greaterThan(?), lessThan(?).

They would be simpler than validwhen and would mean client side validators 
could also be provided.

Thanks for the feedback on the submit/tab issue - I noticed a simlar thing in 
Netscape 7.2 - even though I'm calling setFocus() if you tab off the field it 
goes to the next - whereas IE stays on the field.

I'm not sure the best way to resolve that at this point - I agree it'll anoy 
users - for now I'm going to start an issues list and I'll put that on. If 
other committers are happy with what I'm proposing and it goes into Validator - 
then it opens it up for everyone to submit fixes :-)

I also noted your post on Bug 21043 and have fixed the issue of hidden fields & 
focus in this extension (version 1.0.5 coming soon).

Thanks, Niall



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 03:06 ---
Update on what I reported in comment #4 - this happens in Firefox 1.0, but IE6
doesn't seem to dislay any problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 02:59 ---
Niall - this is really really nice, I especially like the indexed validations.
Didn't try to add javascript validation to validwhen though huh? :P

My only comment right now is that on the field validations, there should be some
sort of catch in there for if somebody hits the submit button instead of
tabbing/clicking between fields. Even with stop on error set, I still had some
major goof-ups on the field validations, and could imagine users having the same
problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 02:42 ---
Joe,

Thanks for the feedback. There is a small example for the other input types 
which I put in for testing - I just didn't add it to the menu. If you key 
in /validatorjs/exampleTags.do you should see it.

I'll post a new version with that on the menu and change the credit card 
validation as you suggest.

Any time you give this will be much appreciated, thanks.

Niall

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 02:16 ---
Niall, this looks awesome.  You've really done a thorough job, and all your
goals are right-on.  The field-by-field validation would be great, and the
general goal of encouraging the use of client-side validation outside of Struts
is also really a good idea.

I wonder if you could add some examples that demonstrate validating other field
types, like radio, checkbox, and select -- I didn't see any in the examples, but
those are where my javascript bugs usually crop up.

Also note that you should remove the "integer" check on credit card numbers,
since  valid credit card numbers are always greater than 2^32.  

I'm going to be travelling for the next few days (US Thanksgiving holiday) but I
want to cheer you on, and after I get back, I'll try to find some time to look
at the JavaScript more closely.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32343] - [Validator] Javascript Rendering Extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32343





--- Additional Comments From [EMAIL PROTECTED]  2004-11-24 00:00 ---
I have just uploaded a new version to the web site:

http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]