enum elements?

Discussion in 'Javascript' started by Simon, Feb 19, 2004.

  1. Simon

    Simon Guest

    Newbie to js - I want to disable all elements on a page whilst a new page is
    loading. Is it possible to enumerate the elements dynamically and disable
    them?

    Thanks IA, Simon
     
    Simon, Feb 19, 2004
    #1
    1. Advertising

  2. Simon wrote:

    > I want to disable all elements on a page whilst a new page is
    > loading. Is it possible to enumerate the elements dynamically and disable
    > them?


    Well, you can call
    var all = document.body.getElementsByTagName('*')
    to find all elements in the body element (with IE6, Netscape 6/7, Opera
    7). I am however not sure what you want to disable for a <span> or <p>
    element for instance.
    And of course you can only find all those elements with script after
    they have been parsed so you would need to run the script at the end of
    the page.
    If you know (for instance on an intranet) that your visitors have script
    enabled then using static HTML to disable form controls e.g.
    <input type="text" disabled ...>
    will do, then in body onload loop through document.forms to enable
    elements again.

    --

    Martin Honnen
    http://JavaScript.FAQTs.com/
     
    Martin Honnen, Feb 19, 2004
    #2
    1. Advertising

  3. Simon

    Simon Guest

    > If you know (for instance on an intranet) that your visitors have script
    > enabled then using static HTML to disable form controls e.g.
    > <input type="text" disabled ...>
    > will do, then in body onload loop through document.forms to enable
    > elements again.
    >


    Thanks Martin - that works fine, I use this:

    function DoEnable()
    {
    var i;
    try
    {
    for ( i=0 ; i<99999 ; i++ )
    {
    document.forms(0).elements(i).disabled = false;
    }
    }
    catch (er) {}
    return true;
    }

    My loop is a bit naff, but I do not know of a property for the number is
    elements.

    I would also like to disable the elements when the document is submitted. Is
    there an event I can somehow hook to do this?

    Thanks, Simon
     
    Simon, Feb 19, 2004
    #3
  4. On Thu, 19 Feb 2004 17:37:31 +0000 (UTC), Simon
    <> wrote:

    [Indented code]

    > function DoEnable()
    > {
    > var i;
    > try
    > {
    > for ( i=0 ; i<99999 ; i++ )
    > {


    // Using the name of the form in place of 0 would be better
    // document.forms[ 'formName' ]
    var form = document.forms[ 0 ];
    var size = form.elements.length;

    for( var i = 0; i < size; ++i ) {

    > document.forms(0).elements(i).disabled = false;


    The forms and elements properties are collections, not methods. Use the
    subscript operators, []. Continuing with my re-write:

    form.elements[ i ].disabled = false;
    }

    > }
    > }
    > catch (er) {}
    > return true;


    Is the return necessary?

    > }
    >
    > My loop is a bit naff, but I do not know of a property for the number is
    > elements.


    All collections have the property, length, which describes the size of the
    collection.

    > I would also like to disable the elements when the document is
    > submitted. Is there an event I can somehow hook to do this?


    FORM elements have the intrinsic event, onsubmit. That will suit your
    needs.

    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 19, 2004
    #4
  5. "Michael Winter" <> wrote in message
    news:eek:...
    <snip>
    >> catch (er) {}
    >> return true;

    >
    >Is the return necessary?


    As the try-catch was only there to handle the point when the original
    loop attempted to access an - elements - member that was not there, with
    your new loop it too can go (and avoid the fatal syntax errors that
    try-catch always generates on pre-javascript 1.4/ECMAScript(ed 3)
    browsers).

    <snip>
    >>I would also like to disable the elements when the document is
    >>submitted. Is there an event I can somehow hook to do this?

    >
    >FORM elements have the intrinsic event, onsubmit. That will
    >suit your needs.


    Onsubmit will provide an opportunity to do what has been asked for:
    disable the from elements when the document is submitted. It cannot make
    sense to actually do that, as disabled elements are not included in
    submissions (they are unsuccessful if disabled). But element disabling
    on submission requests are usually a symptom of server-side scripts that
    cannot cope with multiple submissions of the same form so any
    client-side "fix" would be solving the wrong problem.

    (Incidentally, yesterdays F4D oddities; I concluded developer
    incompetence. The are trying to concede to our bad formatting argument
    by replacing spaces in posts with &nbsp; in the HTML and appear to have
    put the code for attempting that in their live environment before
    testing it. (burks.))

    Richard.
     
    Richard Cornford, Feb 19, 2004
    #5
  6. Simon

    Simon Guest

    > > }
    > > }
    > > catch (er) {}
    > > return true;

    >
    > Is the return necessary?


    Yes, I believe so - it's an Intraweb page and returning true means
    subsequent events fire.
    Thanks for the code suggestions - it's much tidier now (I'm surprised it
    even worked before).

    >
    > FORM elements have the intrinsic event, onsubmit. That will suit your
    > needs.
    >


    I've tried using the form.onsubmit and the elements.onsubmit but it does not
    seem to fire.

    e.g. document.forms[0].elements.onsubmit = "self.disabled = true"; for an
    element
    and document.forms[0].onsubmit = "DoDisable()"; for the form

    The form already has an onsubmit defined - maybe that is the problem?

    Thanks, Simon
     
    Simon, Feb 19, 2004
    #6
  7. Simon

    Simon Guest

    > Onsubmit will provide an opportunity to do what has been asked for:
    > disable the from elements when the document is submitted. It cannot make
    > sense to actually do that, as disabled elements are not included in
    > submissions (they are unsuccessful if disabled). But element disabling
    > on submission requests are usually a symptom of server-side scripts that
    > cannot cope with multiple submissions of the same form so any
    > client-side "fix" would be solving the wrong problem.
    >


    That's interesting - the server side 'scripts' are provided via an Intraweb
    application that indeed cannot cope with multiple submissions (at least that
    is true for v5.1.30 which I use).
    I'll have to find a better strategy than disabling the controls as some of
    them will be needed in the submit.

    > (Incidentally, yesterdays F4D oddities; I concluded developer
    > incompetence. The are trying to concede to our bad formatting argument
    > by replacing spaces in posts with &nbsp; in the HTML and appear to have
    > put the code for attempting that in their live environment before
    > testing it. (burks.))


    You've lost me here.

    Thanks,

    Simon
     
    Simon, Feb 19, 2004
    #7
  8. Simon

    Mick White Guest

    function DoEnable(form){
    for(f=0;f<form.length;f++){
    if(form[f].disabled){
    form[f].disabled= false;
    }
    }
    }
    Mick

    Simon wrote:

    >>If you know (for instance on an intranet) that your visitors have script
    >>enabled then using static HTML to disable form controls e.g.
    >> <input type="text" disabled ...>
    >>will do, then in body onload loop through document.forms to enable
    >>elements again.
    >>

    >
    >
    > Thanks Martin - that works fine, I use this:
    >
    > function DoEnable()
    > {
    > var i;
    > try
    > {
    > for ( i=0 ; i<99999 ; i++ )
    > {
    > document.forms(0).elements(i).disabled = false;
    > }
    > }
    > catch (er) {}
    > return true;
    > }
    >
    > My loop is a bit naff, but I do not know of a property for the number is
    > elements.
    >
    > I would also like to disable the elements when the document is submitted. Is
    > there an event I can somehow hook to do this?
    >
    > Thanks, Simon
    >
    >
     
    Mick White, Feb 19, 2004
    #8
  9. On Thu, 19 Feb 2004 18:34:13 -0000, Richard Cornford
    <> wrote:

    > "Michael Winter" <> wrote in message
    > news:eek:...
    > <snip>
    >>> catch (er) {}
    >>> return true;

    >>
    >> Is the return necessary?

    >
    > As the try-catch was only there to handle the point when the original
    > loop attempted to access an - elements - member that was not there, with
    > your new loop it too can go (and avoid the fatal syntax errors that
    > try-catch always generates on pre-javascript 1.4/ECMAScript(ed 3)
    > browsers).


    I should have made it clear that the code I presented was a replacement,
    in full, of the the original.

    > <snip>
    >>> I would also like to disable the elements when the document is
    >>> submitted. Is there an event I can somehow hook to do this?

    >>
    >> FORM elements have the intrinsic event, onsubmit. That will
    >> suit your needs.

    >
    > Onsubmit will provide an opportunity to do what has been asked for:
    > disable the from elements when the document is submitted. It cannot make
    > sense to actually do that, as disabled elements are not included in
    > submissions (they are unsuccessful if disabled).


    ....I should have also considered what the effect of disabling controls
    would have on submission, especially considering I gave someone else a
    link to the part of the specification concerning "Successful controls"
    earlier in the day. :)

    (I feel like such a fool: I read that section after citing it, too)

    > But element disabling on submission requests are usually a symptom of
    > server-side scripts that cannot cope with multiple submissions of the
    > same form so any client-side "fix" would be solving the wrong problem.


    I'm sure that is was to this thread that I would recommend an update to
    their server-side software that would limit multiple posts from a user by
    tracking what was sent by whom in a certain timescale (or some other
    similar method). To whomever it was, the decision was motivated by the
    cases where controls would remain disabled if a user returned to the page
    using the back button. I still wasn't considering the fact that nothing
    would be submitted as it wouldn't meet the criteria for "successful".

    > (Incidentally, yesterdays F4D oddities; I concluded developer
    > incompetence. The are trying to concede to our bad formatting argument
    > by replacing spaces in posts with &nbsp; in the HTML and appear to have
    > put the code for attempting that in their live environment before
    > testing it. (burks.))


    That still leaves the question: how? Unless there's more to it[1] (I'm not
    seeing it if there is), surely they can't mess up what would be a simple
    search and replace regular expression? Based on previous performance, I
    suppose they can...

    Mike


    [1] Aside from the obvious exclusion of whitespace in HTML tags and
    attribute values.

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 19, 2004
    #9
  10. On Thu, 19 Feb 2004 19:33:28 +0000 (UTC), Simon
    <> wrote:

    [snip]

    >> (Incidentally, yesterdays F4D oddities; I concluded developer
    >> incompetence. The are trying to concede to our bad formatting argument
    >> by replacing spaces in posts with &nbsp; in the HTML and appear to have
    >> put the code for attempting that in their live environment before
    >> testing it. (burks.))

    >
    > You've lost me here.


    That was directed at me, following a previous off-topic discussion
    yesterday. :)

    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 19, 2004
    #10
  11. On Thu, 19 Feb 2004 18:53:43 +0000 (UTC), Simon
    <> wrote:

    >> > }
    >> > }
    >> > catch (er) {}
    >> > return true;

    >>
    >> Is the return necessary?

    >
    > Yes, I believe so - it's an Intraweb page and returning true means
    > subsequent events fire.


    Without a context, I couldn't say. If called from an intrinsic, HTML
    event, it wouldn't be needed. Only returning false affects events:
    returning no value, or true, allows the usual actions. If it's called in
    conjunction with some library that expects a return value (like you seem
    to suggest), then obviously use as necessary.

    However, from what is indicated below, the return isn't necessary:
    returning true in an intrinsic event is superfluous.

    By the way,

    function myFunc() {
    <do something>
    return false;
    }

    <form ... onsubmit="myFunc()">

    won't have any effect, anyway. It would be the same as:

    <form ... onsubmit="<do something>;false">

    What you actually need is:

    function myFunc() {
    <do something>
    return false;
    }

    <form ... onsubmit="return myFunc()">

    > Thanks for the code suggestions - it's much tidier now (I'm surprised it
    > even worked before).


    In some older browsers, it wouldn't have: try/catch wouldn't have been
    supported.

    >> FORM elements have the intrinsic event, onsubmit. That will suit your
    >> needs.

    >
    > I've tried using the form.onsubmit and the elements.onsubmit but it does
    > not seem to fire.
    >
    > e.g. document.forms[0].elements.onsubmit = "self.disabled = true";
    > for an element and document.forms[0].onsubmit = "DoDisable()"; for the
    > form


    Form controls (button, input, and the like) don't have onsubmit events.
    Only FORM elements do. Further, you can only use text when creating an
    event in HTML. When assigning the events as code, you provide a function
    reference. Your solution will either be:

    <form ... onsubmit="<current code>;DoDisable();">

    or

    document.forms[ 0 ].onsubmit = new Function( "DoDisable()" );

    or

    document.forms[ 0 ].onsubmit = function () {
    DoDisable();
    }

    As has been pointed out already, this isn't much of a solution still, as
    none of the form values will be submitted if they are disabled. You could
    disable the submit button by itself, but this could lead to problems if
    the user needs to go back (using the back button) for some legitimate
    reason, such as a failed connection. The user could find that the button
    is still disabled, requiring a refresh of the page that will destroy the
    data entered so far. The best solution would be to determine on the server
    whether multiple submissions have occurred and discount the earlier ones,
    in case something has been changed in the later ones. It's also a more
    robust solution, as users without JavaScript still won't be able to submit
    several times accidentally.

    > The form already has an onsubmit defined - maybe that is the problem?


    No. The original handler will just have been overwritten, which probably
    isn't desirable.

    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 19, 2004
    #11
  12. "Michael Winter" <> wrote in message
    news:eek:...
    <snip>
    >>... I concluded developer incompetence. The are trying to
    >>concede to our bad formatting argument by replacing spaces
    >>in posts with &nbsp; in the HTML and appear to have put the
    >>code for attempting that in their live environment before
    >>testing it. (burks.))

    >
    >That still leaves the question: how? Unless there's more to it[1]
    >(I'm not seeing it if there is), surely they can't mess up what
    >would be a simple search and replace regular expression? Based
    >on previous performance, I suppose they can...

    <snip>

    I am not sure why you ask how. Every day we see examples of what happens
    when people attempt to program complex software systems that they don't
    really understand.

    In terms of the mechanism, it looks like the part of the system that
    builds the pages uses a specialised mark-up that uses square brackets as
    delimiters. It doesn't work that well at replacing its mark-up with
    HTML, hence the "" (and similar) insertions in the output
    text. It is probably one of their tokens that would be used to insert
    &nbsp; into the output but the corresponding [nbsp] (or whatever the
    specialised mark-up would be) would have to be inserted at an earlier
    stage, and would use a simple (probably regular expression based)
    replace function. But if whoever wrote that function had inserted some
    unrecognised form of the specialised mark-up then the opening and
    closing square brackets might be picked up and their contents removed
    but the system would not know what to inset. So it inserted nothing and
    the result was that the generated text was not separated by spaces of
    any type.

    Obviously that is mostly speculation. I had a superficial look at the
    documentation for the Usenet forum software but I was not going to spend
    any time studying it as I don't need to know how it works (in as far as
    anything that broken can be said to work). I would not work for any
    organisation that employed it, and given the quality of the developers
    that forum4designers has managed to employ it doesn't look like they can
    find anyone competent willing to work with it.

    Richard.
     
    Richard Cornford, Feb 19, 2004
    #12
  13. Simon

    Simon Guest

    > As has been pointed out already, this isn't much of a solution still, as
    > none of the form values will be submitted if they are disabled. You could
    > disable the submit button by itself, but this could lead to problems if
    > the user needs to go back (using the back button) for some legitimate
    > reason, such as a failed connection. The user could find that the button
    > is still disabled, requiring a refresh of the page that will destroy the
    > data entered so far. The best solution would be to determine on the server
    > whether multiple submissions have occurred and discount the earlier ones,
    > in case something has been changed in the later ones. It's also a more
    > robust solution, as users without JavaScript still won't be able to submit
    > several times accidentally.
    >


    Thanks Mike, I'll take a look at the server side, but the source code is
    limited so it may not be possible to change the behaviour for multiple
    submits.
    If a control is not included when disabled, how about when it is invisible?
    I was thinking I could blank the screen onsubmit by setting visible to
    false.

    Simon
     
    Simon, Feb 20, 2004
    #13
  14. On Fri, 20 Feb 2004 10:22:02 +0000 (UTC), Simon
    <> wrote:

    [snip]

    > If a control is not included when disabled, how about when it is
    > invisible?


    CSS hidden controls should be submitted...

    > I was thinking I could blank the screen onsubmit by setting visible to
    > false.


    However, this would still suffer from the same possible problems as
    disabling the submit button. Using 'Back' may display the final state of
    the page. In this case, it is even worse than a disabled submit button.
    The user could be confronted by an entirely blank page.

    If a server-side fix is not a possibility, I would estimate that disabling
    the submit button would be the lesser evil of the two alternatives. At
    least that way, the user can see the page. You might even be able to work
    in a way to reactivate the button, if needed. Not pretty, but do-able.

    Mike

    --
    Michael Winter
    d (replace ".invalid" with ".uk" to reply)
     
    Michael Winter, Feb 20, 2004
    #14
  15. Simon

    Simon Guest

    > However, this would still suffer from the same possible problems as
    > disabling the submit button. Using 'Back' may display the final state of
    > the page. In this case, it is even worse than a disabled submit button.
    > The user could be confronted by an entirely blank page.
    >
    > If a server-side fix is not a possibility, I would estimate that disabling
    > the submit button would be the lesser evil of the two alternatives. At
    > least that way, the user can see the page. You might even be able to work
    > in a way to reactivate the button, if needed. Not pretty, but do-able.
    >


    Thanks Mike
     
    Simon, Feb 20, 2004
    #15
  16. "Michael Winter" <> wrote in message
    news:eek:...
    <snip>
    >CSS hidden controls should be submitted...

    <snip>

    Not in the very buggy (and hopefully no longer used) Netscape 6
    releases. Where CSS visibility:hidden and display:none; (including
    inherited) render controls unsuccessful.

    Richard.
     
    Richard Cornford, Feb 20, 2004
    #16
    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. -

    enum within an enum

    -, Jun 12, 2005, in forum: Java
    Replies:
    6
    Views:
    564
  2. Jerminia
    Replies:
    3
    Views:
    638
    Roedy Green
    Oct 7, 2005
  3. Ernst Murnleitner

    How to enum an enum?

    Ernst Murnleitner, Nov 12, 2003, in forum: C++
    Replies:
    5
    Views:
    483
    Rolf Magnus
    Nov 13, 2003
  4. mrhicks
    Replies:
    2
    Views:
    439
    Dave Thompson
    Jun 10, 2004
  5. Randy
    Replies:
    1
    Views:
    523
    David Harmon
    Jan 7, 2006
Loading...

Share This Page