Validation Toolkit 2.3.4 and 2.3.5 = Fail

[ccooper309155]

Using CS4 and ASP VB

A week or so ago using 2.3.5 , I updated the validation on a page that was originally created using 2.3.2 or 2.3.3.

All it did was completely mess up the validation, wrong forms, wrong everything. Tried and tried again. I'd have it right and save it then when I tried the page it didn't work right. When I opened the Toolkit again, all the code was messed up again.

So I removed 2.3.5 and installed 2.3.4 (which I had never used) -- and same problem.

I wound up fixing it in DW8 using 2.3.2.

Today I created a brand new page for a different site that lives on a different server using 2.3.4 -- and got the same haywire result!!!!

Clearly these patches are a mess!

Looks like I'll have to fire up DW8 and 2.3.2 again.

I've never seen any WA extension behave so weirdly.

[ccooper309155]

Here is one example of what it does:

It changes frmAdd.Box into forms[0].Box

[Jason Byrnes]

The new version of Validation toolkit uses the Javascript forms[] collection instead of referring to the form by name.

this is because the xhtml strict doctype does not require a name for a form, only an id.

Can you post a link to a page that is not working? We can examine the code on the page and most likely determine what is going wrong.

[ccooper309155]

The pages are all ones that require user authentication, but more than that, I fixed them all with 2.3.2 in DW 8, so there are no pages with problems to share.

That said, I don't see what good it would do as the toolkit is messing up the code as it writes it. Looking at bad code as opposed to the writing of same can't help determine why it's doing it, can it?

When I get a chance, maybe I will create a virgin page for you to look at.

BTW, the non-remembering log-in procedure here is a real PAIN IN THE ASS.

I hate having to look up my pwd every time.

Why don't you guys listen to your customers?

[Jason Byrnes]

By looking at the code that does not work I can determine why. once we can determine what is wrong in the code, it may shed some light on why the code is being written incorrectly.

I have tested on forms I created using earlier versions of validation toolkit and then updating the code with version 2.3.5 and did not run into a problem.

Looking at the code that is failing is the first step to determining why the code is not being generated properly.

[brian70185]

Having similar problems here with the latest version of Validation toolkit on ASP/ VB. When I go through the validation wizard, everything seems fine. When I go back in, everything is renamed forms[0].Field1.... all validations apply to the first field, even though they were connected to other fields. Everything is named after the first field.

I am a 6 year WebAssist extension user and I literally use your extensions everyday. The latest release of Validation toolkit for ASP/VB is messed up. If you say you have tested it and don't see a problem, you are not testing it thouroughly. Also, referring to forms without the proper form name is onbviously appropriate...but what will happen if a user adds/removes a form above the one with validation.

[Jason Byrnes]

I have just retested to see if I could reproduce the problems you describe in 4 different forms that where created using validation toolkit 2.3.2 then edited using 2.3.5. Unfortunately, I am not able to reproduce a problems.

in my latest attempt, I created a form in an asp page with 4 text fields. Using the Client Validation wizard, I applied Required / Not Blank Validation to all for of them.

I tested the page and validation worked correctly.

I then uninstalled 2.3.2 and installed 2.3.5.

Using the validation wizard, I applied Alpha Numeric Validation to the first 2 fields.

I tested the page and validation worked as expected.


I am attaching a copy of the page with validation 2.3.2 and 2.3.5.

If there is a problem in Validation toolkit, we very much want to fix the issue, perhaps you could provide the steps you followed to produce the problem?

If a form is added or removed then validation will need to be reapplied. The change to using the forms collection was made to be in line with the XHTML Strict document type. In XHTML Strict, the forms name element is deprecated, forms cannot have a name.

[brian70185]

I may have found the problem. The pages I seem to be having trouble on are the pages that have an include file with a form at the top of the page (a search field and button for instance). When I create/edit a form in the main file (not the include), Validation Toolkit gets messed up. I have tried this on several sites, and this happens every time. When I run Validation toolkit on a plain Jane page with no includes, it is fine.

Thanks,

Brian

[Ray Borduin]

It probably has to do with the way the Validation Toolkit is referring to the form in client side validaitons. It uses the numeric index of the form like document.forms[0]. If you then add an include above it that includes a form it throws off the form reference so that it needs to become forms[1]. You may be able to do a find and replace "forms[0]" for "forms[1]" to update the form references so that it will work with a form above it.

[brian70185]

That could be one issue, but I don't think it is all.... it seems the include form throws of Validation toolkit in some way, because after I run the extension, the field names are all named after field 1... EXAMPLE 1 (before), EXAMPLE 2 (after)

EXAMPLE 1 (Before 2.3.5 was run)

onsubmit="WAValidateRQ(document.InsertForm.Title,'- Title is Required',document.InsertForm.Title,0,true,'text') ;WAValidateDT(document.InsertForm.StartDate,'- Invalid Start Date',true,/\b(1[0-2]|0?[1-9])\/([12]\d|3[0-1]|0?[1-9])\/\d{4}\b/,'','','',false,/.*/,'','','',document.InsertForm.StartDate,0,true);WA ValidateDT(document.InsertForm.EndDate,'- Invalid End Date',true,/\b(1[0-2]|0?[1-9])\/([12]\d|3[0-1]|0?[1-9])\/\d{4}\b/,'','','',false,/.*/,'','','',document.InsertForm.EndDate,0,true);WAVa lidateRQ(document.InsertForm.Location,'- Location is Required',document.InsertForm.Location,0,true,'tex t');WAValidateEL(document.InsertForm.Title,documen t.InsertForm.Description.value,'- Description contains more than 500 characters',0,500,'',document.InsertForm.Title,0,t rue);WAAlertErrors('Please correct the following:','',true,false,false);return document.MM_returnValue">

EXAMPLE 2 (After 2.3.5 was run)

onsubmit="WAValidateRQ(document.forms[1].Title,'- Title is Required',document.forms[1].Title,0,true,'text');WAValidateDT(document.forms[1].Title,'- Invalid Start Date',true,/\b(1[0-2]|0?[1-9])\/([12]\d|3[0-1]|0?[1-9])\/\d{4}\b/,'','','',false,/.*/,'','','',document.forms[1].Title,0,true);WAValidateDT(document.forms[1].Title,'- Invalid End Date',true,/\b(1[0-2]|0?[1-9])\/([12]\d|3[0-1]|0?[1-9])\/\d{4}\b/,'','','',false,/.*/,'','','',document.forms[1].Title,0,true);WAValidateRQ(document.forms[1].Title,'- Location is Required',document.forms[1].Title,0,true,'text');WAValidateEL(document.forms[1].Title,document.forms[1].Title.value,'- Description contains more than 500 characters',0,500,'',document.forms[1].Title,0,true);WAAlertErrors('Please correct the following:','',true,false,false);return document.MM_returnValue"

[Ray Borduin]

Well... maybe there are two forms before it and it should be forms[2]?

Do you have a url? Looking at the page that doesn't work would allow me to be sure instead of guessing.

[brian70185]

I think you missed the point... after running the 2.3.5 extension on a previously working validated form (using 2.3.2), all of the fields in the onsubmit tag have been renamed exactly the same thing(document.forms[1].Title).

If you will set up an ASP/VB site with an include at the top with the form, and apply VTK to a second form on the main page, I think you will see what is going wrong. I have tested this on a number of sites, and those that meet that criteria all fail.

[Ray Borduin]

I did miss the point.

If you do a find and replace of: "document.insertForm" with "document.forms[1]" before running the wizard, it will inspect properly.

The problem is that it isn't inspecting properly, so it is just choosing the first field in your form. It appears this is a bug when updating between those versions. I will log it and make sure it is addressed in the next build.

For now you will have to manipulate the form name manually before running the wizard, or make sure to reset all form elements when running the wizard.