validation has syntax errors [correction] [JavaScript]

Prev: validation has syntax errors
Next: I GOT $2500 FROM PAYPAL....

From: Richard Cornford on 3 Aug 2010 13:00

On Aug 3, 2:44 pm, Denis McMahon wrote:
> On 03/08/10 07:13, jr wrote:
>
>> function checkscript() {
>> if ( search_bu.value && search_error_flag) {
>> if ( zoneid.value && !zonenum.value ) {return 1 }
>> }
>
>> return 0;
>
> I hope you had a "}" after the return 0?
>
> I'm sure you're fully aware, having been told many times, that
> you can't just use the field name or id to identify a field
> in javascript.

One of the main reasons that people are continually told that they
shouldn't use a field's name or ID to identify a filed is that in many
cases you can, and so for some value of 'works' it does 'work'. The
problem with it is that there are some environments/contexts were it
won't work and so is neither reliable nor cross-browser.

> You have to translate that information somewhere into something
> the code understands.
>
> In fact, this is a fundamental concept that you should
> understand by now.
>
> Irrespective of whether the logical flow of your code
> works (and as I don't fully understand what you're trying
> to check, I can't verify whether it will or not) I have no
> idea what the one variable and three objects you're testing
> here are.

No, the javascript code without the mark-up that creates the DOM with
which it interacts has relatively little meaning.

> There are two ways to address objects relating to input
> elements in a form from within javascript.

I can think of at least 6 obvious ways, and that means there will
probably be a dozen more.

> One, which some people now consider outdated, is as a named
> property of the parent form object,
> and the other is using the element id.

That would be a vague distinction as a property of the FORM element
may exist with a name that corresponds with the ID of the element.
Presumably you mean accessing the form control using its ID with -
documentGetElementById -.

The W3C HTML DOM offers the - elements - property of the FORM element
as a collection of contained form control elements, that can be
integer indexed or referenced by name and/or ID. Being both DOM
standard and back-compatible with every scriptable web browser that
has ever known what a form is, this should be the preferred method of
accessing form controls.

> If using the named property of form method, then you also
> need to identify the form,
> either as a member of the document's forms collection, or
> as a named property of the document.

From a FORM element's - onsubmit - listener the form can be
anonymously referenced using the - this - keyword, and from the
intrinsic event listeners of form controls elements the - this.form -
will refer to the containing FROM element. Generally form validation
will involve one of these so there is normally no reason for the form
having a name/ID or there being any interest/reliance on the FORM's
index in the - document.forms - collection.

> I have seen code that combines using the id of the form
> and then referring to an input as a named property of that
> form, which is to me illogical,

I don't see why. Strict HTML 4 does not allow FORM elements to have
NAME attributes, so there they cannot be referenced by name, and from
controls need to have NAME attributes if they are to be
'successful' (their values submitted to the server) so without some
other need (such as cross-referencing LABEL elements) adding ID
attributes to them could be superfluous.

> as in my opinion if you're going to use element id
> attributes you might as well use id at the input element
> level.

An ID should be unique to the document, but a document could contain
multiple forms, and different forms may contain fields that
(logically) should have the same name.

> Once you have identified the object that relates to an
> input element on a form, there is as one and only one
> common way to get the content of that element.

At least if you disregard radio buttons and checkboxes (neither of
which have "content" and their - value - properties are rarely of
primary interest while validating).

Richard.

From: jr on 3 Aug 2010 13:29

On Aug 3, 10:00 am, Richard Cornford <Rich...(a)litotes.demon.co.uk>
wrote:
> On Aug 3, 2:44 pm, Denis McMahon wrote:
>
> > On 03/08/10 07:13, jr wrote:
>
> >> function checkscript() {
> >> if ( search_bu.value && search_error_flag) {
> >> if ( zoneid.value && !zonenum.value ) {return 1 }
> >> }
>
> >> return 0;
>
> > I hope you had a "}" after the return 0?
>
> > I'm sure you're fully aware, having been told many times, that
> > you can't just use the field name or id to identify a field
> > in javascript.
>
> One of the main reasons that people are continually told that they
> shouldn't use a field's name or ID to identify a filed is that in many
> cases you can, and so for some value of 'works' it does 'work'. The
> problem with it is that there are some environments/contexts were it
> won't work and so is neither reliable nor cross-browser.
>
> > You have to translate that information somewhere into something
> > the code understands.
>
> > In fact, this is a fundamental concept that you should
> > understand by now.
>
> > Irrespective of whether the logical flow of your code
> > works (and as I don't fully understand what you're trying
> > to check, I can't verify whether it will or not) I have no
> > idea what the one variable and three objects you're testing
> > here are.
>
> No, the javascript code without the mark-up that creates the DOM with
> which it interacts has relatively little meaning.
>
> > There are two ways to address objects relating to input
> > elements in a form from within javascript.
>
> I can think of at least 6 obvious ways, and that means there will
> probably be a dozen more.
>
> > One, which some people now consider outdated, is as a named
> > property of the parent form object,
> > and the other is using the element id.
>
> That would be a vague distinction as a property of the FORM element
> may exist with a name that corresponds with the ID of the element.
> Presumably you mean accessing the form control using its ID with -
> documentGetElementById -.
>
> The W3C HTML DOM offers the - elements - property of the FORM element
> as a collection of contained form control elements, that can be
> integer indexed or referenced by name and/or ID. Being both DOM
> standard and back-compatible with every scriptable web browser that
> has ever known what a form is, this should be the preferred method of
> accessing form controls.
>
> > If using the named property of form method, then you also
> > need to identify the form,
> > either as a member of the document's forms collection, or
> > as a named property of the document.
>
> From a FORM element's - onsubmit - listener the form can be
> anonymously referenced using the - this - keyword, and from the
> intrinsic event listeners of form controls elements the - this.form -
> will refer to the containing FROM element. Generally form validation
> will involve one of these so there is normally no reason for the form
> having a name/ID or there being any interest/reliance on the FORM's
> index in the - document.forms - collection.
>
> > I have seen code that combines using the id of the form
> > and then referring to an input as a named property of that
> > form, which is to me illogical,
>
> I don't see why. Strict HTML 4 does not allow FORM elements to have
> NAME attributes, so there they cannot be referenced by name, and from
> controls need to have NAME attributes if they are to be
> 'successful' (their values submitted to the server) so without some
> other need (such as cross-referencing LABEL elements) adding ID
> attributes to them could be superfluous.
>
> > as in my opinion if you're going to use element id
> > attributes you might as well use id at the input element
> > level.
>
> An ID should be unique to the document, but a document could contain
> multiple forms, and different forms may contain fields that
> (logically) should have the same name.
>
> > Once you have identified the object that relates to an
> > input element on a form, there is as one and only one
> > common way to get the content of that element.
>
> At least if you disregard radio buttons and checkboxes (neither of
> which have "content" and their - value - properties are rarely of
> primary interest while validating).
>
> Richard.

thanks,

From: Denis McMahon on 3 Aug 2010 13:51

On 03/08/10 16:44, jr wrote:

> I tried it like this and it still doesn't fire. there are 4 fields in
> a search form. The first 2 required. The zonenm is only required if
> there is no zoneid. IT seems like it should work. Rgds, Janis

> function checkscript() {
> // If bu and error_flag have a value return 0,
> // if zoneid has a value without zonenm proceed
> // to next check
> var ele=document.forms[0];
> if (ele.search_bu.value && ele.search_error_flag.value ) {
> // If zoneid has a value and zonenm does
> // not have a value return false
> if (ele.search_zoneid.value && !ele.search_zonenm.value) {
> return 1;
> } else {
> // if zoneid doesn't have a value, or
> // if both zoneid and zonenm have values
> return 0;
> }
> // If either bu or error_flag (or both) don't have a value
> } else {
> return 1;
> }
> }

Ok, the function as presented appears, as far as I can tell, to match
the comments associated with it.

How are you calling the function? I would look at the opening tag of the
form element, and the submit element inside the form.

Are there any other forms on the page? If so, are you referring to the
correct form? It might be better, in the case of multiple forms, to use
a more explicit identification of the form. At present, you are assuming
that the form is form[0]. It may not be safe, if there are multiple
forms, to assume that that the forms array holds them in a predefined order.

If you give the form a name, you can use that name in your definition of
"ele".

Rgds

Denis McMahon

From: jr on 3 Aug 2010 15:06

On Aug 3, 10:51 am, Denis McMahon <denis.m.f.mcma...(a)googlemail.com>
wrote:
> On 03/08/10 16:44, jr wrote:
>
>
>
>
>
> > I tried it like this and it still doesn't fire. there are 4 fields in
> > a search form. The first 2 required. The zonenm is only required if
> > there is no zoneid. IT seems like it should work. Rgds, Janis
> > function checkscript() {
> > // If bu and error_flag have a value return 0,
> > // if zoneid has a value without zonenm proceed
> > // to next check
> > var ele=document.forms[0];
> > if (ele.search_bu.value && ele.search_error_flag.value ) {
> > // If zoneid has a value and zonenm does
> > // not have a value return false
> > if (ele.search_zoneid.value && !ele.search_zonenm.value) {
> > return 1;
> > } else {
> > // if zoneid doesn't have a value, or
> > // if both zoneid and zonenm have values
> > return 0;
> > }
> > // If either bu or error_flag (or both) don't have a value
> > } else {
> > return 1;
> > }
> > }
>
> Ok, the function as presented appears, as far as I can tell, to match
> the comments associated with it.
>
> How are you calling the function? I would look at the opening tag of the
> form element, and the submit element inside the form.
>
> Are there any other forms on the page? If so, are you referring to the
> correct form? It might be better, in the case of multiple forms, to use
> a more explicit identification of the form. At present, you are assuming
> that the form is form[0]. It may not be safe, if there are multiple
> forms, to assume that that the forms array holds them in a predefined order.
>
> If you give the form a name, you can use that name in your definition of
> "ele".
>
> Rgds
>
> Denis McMahon

This is the submit button in the view source:
<td colspan='13' align='center'><input type='submit' name='submit1'
value = ' Search'>

This is the form post in view source:
<form action='/tools/cart_inventory/cart_order_review.php'
onSubmit='return checkscript();' method='post'>

there is only one submit button, a search form. There are two sql's in
an if/else but only one search form and one result set. I called it
submit1 but it doesn't work if I call it just submit. rgds, Janis

From: jr on 3 Aug 2010 15:09

First | Prev | Next | Last
Pages: 1 2 3 4
Prev: validation has syntax errors
Next: I GOT $2500 FROM PAYPAL....