enum elements?

[Simon]

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

 

[Martin Honnen]

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.

 

[Simon]

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

 

[Michael Winter]

On Thu, 19 Feb 2004 17:37:31 +0000 (UTC), Simon

[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

 

[Richard Cornford]

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).

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.

 

[Simon]

}

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]

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

 

[Mick White]

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

 

[Michael Winter]

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.

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]

On Thu, 19 Feb 2004 19:33:28 +0000 (UTC), Simon

[snip]

You've lost me here.

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

Mike

 

[Michael Winter]

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;
}

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

 

[Richard Cornford]

... 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.

 

[Simon]

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

 

[Michael Winter]

On Fri, 20 Feb 2004 10:22:02 +0000 (UTC), Simon

[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

 

[Simon]

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

 

[Richard Cornford]

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.