Javascript Name action problem

Discussion in 'Javascript' started by Meendar, Aug 13, 2008.

  1. Meendar

    Meendar Guest

    Hi,

    Below is my code snippet having only one form,

    <form>
    <input type ="radio" name="action" value="xyz" checked>xyz
    <input type ="radio" name="action" value="zyx">zyx
    <input type ="radio" name="action" value="yxz">yxz
    </form>


    Through Javascript when i change action url

    document.forms[0].action = "some.php";
    document.forms[0].submit();

    The radio button action ( watch the name of radio button) gets
    changed. I have no choice to change the name of the radio button.

    Is there any workaround for this?

    Thanks!
     
    Meendar, Aug 13, 2008
    #1
    1. Advertising

  2. Meendar

    Henry Guest

    On Aug 13, 1:32 pm, Meendar wrote:
    > Hi,
    >
    > Below is my code snippet having only one form,
    >
    > <form>
    > <input type ="radio" name="action" value="xyz" checked>xyz
    > <input type ="radio" name="action" value="zyx">zyx
    > <input type ="radio" name="action" value="yxz">yxz
    > </form>
    >
    > Through Javascript when i change action url
    >
    > document.forms[0].action = "some.php";
    > document.forms[0].submit();
    >
    > The radio button action ( watch the name of radio button)
    > gets changed. I have no choice to change the name of the
    > radio button.
    >
    > Is there any workaround for this?


    Why is the FORM elements ACTION not specified as an attribute in the
    opening FORM tag?

    The - action - property of a FORM element cannot refer to more than
    one object at the same time, so your best option is change the name of
    radio buttons. They should never have been named "action" to start
    with, and any small change, such as "Action" would be sufficient to
    avoid the issue. See:-

    <URL: http://jibbering.com/faq/faq_notes/form_access.html#faComMis >
     
    Henry, Aug 13, 2008
    #2
    1. Advertising

  3. Meendar

    dhtml Guest

    Henry wrote:
    > On Aug 13, 1:32 pm, Meendar wrote:


    >
    > The - action - property of a FORM element cannot refer to more than
    > one object at the same time, so your best option is change the name of
    > radio buttons. They should never have been named "action" to start
    > with, and any small change, such as "Action" would be sufficient to
    > avoid the issue. See:-
    >
    > <URL: http://jibbering.com/faq/faq_notes/form_access.html#faComMis >


    That is a good article, however, it is little outdated.

    | In addition to making named FORM elements
    | available as named properties of the document.forms
    | collection web browsers also make them available as
    | named properties of the document object.

    Fortunately, that is no longer true in most browsers.

    Alas, the same cannot be said for HTML Form Controls' names being added
    as properties to a form. In fact, we can see that this is regressing now
    with Web Forms 2.0:
    http://www.whatwg.org/specs/web-forms/current-work/#additions

    In my research, I have discovered some 240 names that will replace (or
    shadow, depending on the implementation) properties of a FORM element,
    even when the original property was "readonly", "const", or a function.

    <form name='testForm'>
    <input name="length"/>
    <input name="toString"/>
    </form>

    <script>
    alert( document.forms.testForm );
    </script>

    Will result in errors in Firefox 3, Safari 3, and Opera 9.5. The alert
    will attempt to call the form's - toString - property.

    There are 240 such properties that I am aware of. It is likely that that
    number will increase as more names are discovered and new features are
    created.

    Garrett
     
    dhtml, Aug 29, 2008
    #3
  4. dhtml wrote:
    > Henry wrote:

    <snip>
    >> <URL: http://jibbering.com/faq/faq_notes/form_access.html#faComMis >

    >
    > That is a good article, however, it is little outdated.
    >
    > | In addition to making named FORM elements
    > | available as named properties of the document.forms
    > | collection web browsers also make them available as
    > | named properties of the document object.
    >
    > Fortunately, that is no longer true in most browsers.

    <snip>

    In the absence of a rational for "Fortunately", any single cited example
    and any evidence/justification for "most" this is most likely to be
    dismissed as more of your usual BS.

    Richard.
     
    Richard Cornford, Aug 29, 2008
    #4
  5. Meendar

    dhtml Guest

    Richard Cornford wrote:
    > dhtml wrote:
    >> Henry wrote:

    > <snip>
    >>> <URL: http://jibbering.com/faq/faq_notes/form_access.html#faComMis >

    >>
    >> That is a good article, however, it is little outdated.
    >>
    >> | In addition to making named FORM elements
    >> | available as named properties of the document.forms
    >> | collection web browsers also make them available as
    >> | named properties of the document object.
    >>
    >> Fortunately, that is no longer true in most browsers.

    > <snip>
    >
    > In the absence of a rational for "Fortunately", any single cited example
    > and any evidence/justification for "most" this is most likely to be
    > dismissed as more of your usual BS.
    >


    You probably meant 'rationale'.

    Regardless, that is a loaded statement. It implies that I usually post BS.

    <form name="testform"></form>
    <script>
    alert([document.testform, document.testform]);
    </script>

    Will result in:
    Firefox 3, Opera, Safari

    object,object

    So it is true that browsers still exhibit this old behavior. I remember
    testing this previously and getting a different result, but I modified
    that test to do something else.

    The browser adding form names as properties to the document creates a
    bad situation (this is the 'rationale' part). The problem is that can
    easily creates conflict with existing properties of the document. When a
    browser adds a new feature and a new property name to the document
    object, document.setTheme, for example, and a form named 'setTheme'
    exists, there will be a conflict. Especially with an object that has as
    many properties as document, which vary across many browsers.

    It's the same problem with having form control names replace properties
    of the form. Same rationale except the conflict exists between form
    control names and properties on the FORM element.

    You are obviously more interested in attempts to insult or discredit me
    than you are to have any sort of technical discussion.

    Garrett

    > Richard.
    >
     
    dhtml, Aug 29, 2008
    #5
  6. Meendar

    optimistx Guest

    dhtml wrote:
    > Richard Cornford wrote:

    ....
    >> In the absence of a rational for "Fortunately", any single cited
    >> example and any evidence/justification for "most" this is most
    >> likely to be dismissed as more of your usual BS.
    >>

    >
    > You probably meant 'rationale'.
    >
    > Regardless, that is a loaded statement. It implies that I usually
    > post BS.
    >
    > <form name="testform"></form>
    > <script>
    > alert([document.testform, document.testform]);
    > </script>
    >
    > Will result in:
    > Firefox 3, Opera, Safari
    >
    > object,object
    >

    ....
    > You are obviously more interested in attempts to insult or discredit
    > me than you are to have any sort of technical discussion.
    >
    > Garrett


    I have appreciated your postings, no BS.

    You also made me glad now that you did not start mudwrestling with
    Richard. ('After a while the bystanders forget, who started. They see
    only two pigs in the mud').

    I did not quite catch you alert-statement above. Should it be
    alert(['document.testform', document.testform]);
    ?
     
    optimistx, Aug 29, 2008
    #6
  7. Meendar

    dhtml Guest

    optimistx wrote:
    > dhtml wrote:
    >> Richard Cornford wrote:



    >> Garrett

    >
    > I have appreciated your postings, no BS.
    >


    Thank you.

    I do my best not to make mistakes and post misinformation, but sometimes
    I do make mistakes.

    > I did not quite catch you alert-statement above. Should it be
    > alert(['document.testform', document.testform]);
    > ?
    >


    It should be:
    alert([document.testform, document.forms.testform]);

    This would have the result of alert converting the array to a string. It
    will work as long as there is no form control with the name or id
    "toString".

    The same effect as:-

    var s = String([1, 2]);
    alert(s);

    As for a form control with name "toString" This:-
    <form><input name="toString"></form>
    <script>
    alert(document.forms[0]);
    </script>

    Opera 9.5, Safari 3, Firefox 3
    Error

    Safari 2 and Mac IE result in the form being converted to a string, such as:
    "object FORM"


    Garrett

    >
     
    dhtml, Aug 29, 2008
    #7
  8. dhtml wrote:
    > Richard Cornford wrote:
    >> dhtml wrote:
    >>> Henry wrote:

    >> <snip>
    >>>> <URL: http://jibbering.com/faq/faq_notes/form_access.html#faComMis
    >>>> >
    >>>
    >>> That is a good article, however, it is little outdated.
    >>>
    >>> | In addition to making named FORM elements
    >>> | available as named properties of the document.forms
    >>> | collection web browsers also make them available as
    >>> | named properties of the document object.
    >>>
    >>> Fortunately, that is no longer true in most browsers.

    >> <snip>
    >>
    >> In the absence of a rational for "Fortunately", any single cited
    >> example and any evidence/justification for "most" this is most
    >> likely to be dismissed as more of your usual BS.

    >
    > You probably meant 'rationale'.


    I did.

    > Regardless, that is a loaded statement. It implies that
    > I usually post BS.


    Implies it? I thought "more of your usual BS" said it in as many words.

    > <form name="testform"></form>
    > <script>
    > alert([document.testform, document.testform]);
    > </script>
    >
    > Will result in:
    > Firefox 3, Opera, Safari
    >
    > object,object
    >
    > So it is true that browsers still exhibit this old behavior.


    So "that is no longer true in most browsers" was an absolutely false
    statement then? Not only is it not "no longer true" in "most browsers",
    but apparently it is not "no longer true" in any. And presumably as the
    wording of the article describes the current reality "it is a little
    outdated" was also a false assertion.

    > I remember testing this previously and getting a different
    > result, but I modified that test to do something else.


    You don't say?

    > The browser adding form names as properties to the document
    > creates a bad situation (this is the 'rationale' part).


    So this would be the rationale that justified characterising the thing
    that never happened as 'fortunate'?

    > The problem is that can easily creates conflict with existing
    > properties of the document.


    Yes, as mentioned in the document you were erroneously attempting to
    'correct'.

    > When a browser adds a new feature and a new property name
    > to the document object, document.setTheme, for example, and
    > a form named 'setTheme' exists, there will be a conflict.


    But not a problematic conflict so long as the form element reference
    replaces the value of 'new property name' as the document using that
    form name could not also attempt to employ a feature that did not exist
    at the time of its being authored.

    > Especially with an object that has as many properties as
    > document, which vary across many browsers.


    Sensible naming convention, such as choosing pertinent names for form
    object ("setTheame" doesn't make much sense as the name of a form) and
    using non-javascript-like capitalisation (such as initial capital
    letters instead of initial lower case) can largely negate the issues.

    > It's the same problem with having form control names replace
    > properties of the form. Same rationale except the conflict
    > exists between form control names and properties on the
    > FORM element.


    Yes, it sounds like the sort of thing that any document on accessing
    forms and form controls should mention so people don't stumble into it
    unexpectedly.

    > You are obviously more interested in attempts to insult or


    I am not interested in you at all. Stop attempting to waste my time with
    irrelevances and nonsense and I will happily ignore you completely.

    > discredit me


    You discredit yourself when you make factually false or redundant posts.

    > than you are to have any sort of technical discussion.


    What sort of technical discussion do you expect to follow from your
    making an obviously false statement?

    Richard.
     
    Richard Cornford, Aug 30, 2008
    #8
  9. Meendar

    dhtml Guest

    Richard Cornford wrote:
    > dhtml wrote:
    >> Richard Cornford wrote:
    >>> dhtml wrote:
    >>>> Henry wrote:


    [repeats mentioning mistake]

    >
    >> When a browser adds a new feature and a new property name
    >> to the document object, document.setTheme, for example, and
    >> a form named 'setTheme' exists, there will be a conflict.

    >
    > But not a problematic conflict so long as the form element reference
    > replaces the value of 'new property name' as the document using that
    > form name could not also attempt to employ a feature that did not exist
    > at the time of its being authored.
    >


    If the browser were not to replace existing property value the form
    element, it would not create a problem.

    The browser adding form IDs and Names is poor API design. There is no
    question about that. There is no good reason to access a FORM directly
    off the document (non-standard) over the document.forms collection
    (standard). (The potential fraction of a millisecond saved would is
    negligible).

    It is possible that accessing the form element directly off the document
    will result in accessing a property off the document instead. This will
    happen if the document's property value did not get replaced. For exaple:-

    <form name="title">

    <script>
    document.title = 12;
    </script>

    May result in changing the title of the document in some browsers.
    Safari, for one.

    Having a blacklist of element names and form control names is problematic.

    The problem persists into server APIs which must adopt such naming
    conventions as well. For example, a server that were to require a
    parameter named "data" would create a conflict, as - data - is a
    property in an HTML 5 Form.


    >> Especially with an object that has as many properties as
    >> document, which vary across many browsers.

    >
    > Sensible naming convention, such as choosing pertinent names for form
    > object ("setTheame" doesn't make much sense as the name of a form) and
    > using non-javascript-like capitalisation (such as initial capital
    > letters instead of initial lower case) can largely negate the issues.
    >


    So the proposal to adopt such naming scheme must also be used by all web
    services.

    But even that is still not error-proof as there are properties that have
    capital letters (ATTRIBUTE_NODE is one).

    [more insults]

    >
    > Richard.
    >
     
    dhtml, Aug 30, 2008
    #9
  10. dhtml wrote:
    > Richard Cornford wrote:
    >> dhtml wrote:

    <snip>
    >>> When a browser adds a new feature and a new property name
    >>> to the document object, document.setTheme, for example, and
    >>> a form named 'setTheme' exists, there will be a conflict.

    >>
    >> But not a problematic conflict so long as the form element
    >> reference replaces the value of 'new property name' as the
    >> document using that form name could not also attempt to
    >> employ a feature that did not exist at the time of its
    >> being authored.

    >
    > If the browser were not to replace existing property value
    > the form element, it would not create a problem.


    I have no idea what that is supposed to mean.

    > The browser adding form IDs and Names is poor API design.
    > There is no question about that.


    That ship sailed a long time ago.

    > There is no good reason to access a FORM directly off the document
    > (non-standard) over the document.forms
    > collection (standard).


    None, and you will be hard pressed to find anyone on this group
    suggesting anyone does (quite the reverse).

    > (The potential fraction of a millisecond saved would is negligible).
    >
    > It is possible that accessing the form element directly off
    > the document will result in accessing a property off the
    > document instead.


    And the same will go for named images, embeds, applets and anything else
    that can be accessed in that way.

    > This will happen if the document's property value did not
    > get replaced.


    And assuming a perverse/unwise choice of name.

    > For exaple:-
    >
    > <form name="title">


    And that would be a pretty poor name for a form.

    > <script>
    > document.title = 12;
    > </script>
    >
    > May result in changing the title of the document in some
    > browsers. Safari, for one.
    >
    > Having a blacklist of element names and form control names
    > is problematic.
    >
    > The problem persists into server APIs which must adopt
    > such naming conventions as well. For example, a server
    > that were to require a parameter named "data" would
    > create a conflict, as - data - is a property in an HTML
    > 5 Form.


    But no issues with "Data".

    >>> Especially with an object that has as many properties as
    >>> document, which vary across many browsers.

    >>
    >> Sensible naming convention, such as choosing pertinent names
    >> for form object ("setTheame" doesn't make much sense as the
    >> name of a form) and using non-javascript-like capitalisation
    >> (such as initial capital letters instead of initial lower
    >> case) can largely negate the issues.

    >
    > So the proposal to adopt such naming scheme must also be
    > used by all web services.
    >
    > But even that is still not error-proof as there are properties
    > that have capital letters


    Are there any (or indeed likely to be any) with mixed case and initial
    capital letters? Such a property name will go against the grain of all
    previous precedent.

    > (ATTRIBUTE_NODE is one).


    If someone is mad enough to name their forms "ATTRIBUTE_NODE" then they
    have more problems than will be the result of naming conflicts.

    > [more insults]


    Or observations.

    Richard.
     
    Richard Cornford, Aug 31, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joe Bloggs
    Replies:
    1
    Views:
    993
    Sudsy
    Aug 3, 2003
  2. rjweytens
    Replies:
    6
    Views:
    16,357
    rjweytens
    Jun 25, 2004
  3. runescience

    Struts mapping action to action???

    runescience, Feb 6, 2006, in forum: Java
    Replies:
    3
    Views:
    1,955
    runescience
    Feb 7, 2006
  4. vyshu
    Replies:
    1
    Views:
    2,705
    Richard Senior
    Apr 27, 2007
  5. John
    Replies:
    0
    Views:
    1,011
Loading...

Share This Page