keep form elements enabled on "back" request

D

Dani

Hello everybody,

I have some code that disables form elements on body load, but I notice
when I hit the "back" button, I need to re-enable the form elements
(that is done by clicking on a radial button). Is there any way I can
keep the form for disabling every time a user hits the back button and
"remember" what elements should be enabled? I was thinking maybe
utilizing some referrer thing, but I'm not that good with JS yet.

Thanks for your help!

here is a snip-it from the code:

<script language="JavaScript">
function Disable_All()
{
document.frmPost.employeename.className="disabled";
document.frmPost.employeename.disabled = true
document.frmPost.copyfromemployee.className="disabled";
document.frmPost.copyfromemployee.disabled = true
document.frmPost.effdate.className="disabled";
document.frmPost.effdate.disabled = true
document.frmPost.branch.className="disabled";
document.frmPost.branch.disabled = true
document.frmPost.jobtitle.className="disabled";
document.frmPost.jobtitle.disabled = true
document.frmPost.defprinter.className="disabled";
document.frmPost.defprinter.disabled = true
document.frmPost.printerdesc.className="disabled";
document.frmPost.printerdesc.disabled = true
document.frmPost.extraservice.className="disabled";
document.frmPost.extraservice.disabled = true
document.frmPost.assistance.className="disabled";
document.frmPost.assistance.disabled = true
for (var i = 0;i<8;i++){
document.frmPost.elements.hwreqested.disabled = true;
}
for (var i = 0;i<5;i++){
document.frmPost.elements.swrequested.disabled = true;
}
}
</Script>
<body onLoad="Disable_All();">
 
T

Thomas 'PointedEars' Lahn

Dani said:
I have some code that disables form elements on body load, but I notice
when I hit the "back" button, I need to re-enable the form elements
(that is done by clicking on a radial button). Is there any way I can
keep the form for disabling every time a user hits the back button and
"remember" what elements should be enabled?
No.

I was thinking maybe utilizing some referrer thing,
Click to expand...

While the proprietary document.referrer property is seldom of use, it is
certainly not of use here. There is no "back" request as you imply with
the subject. The reknowned Back (button) feature is AFAIS implemented
either accessing the UA's cache or re-sending a GET request to the
previous URI stored in the "window"'s history. This means

1. the document.referrer property, if supported and if it contains a usable
value (which depends on the user agent, of course), will not contain the
"next" URI but the URI of the resource displayed before the form with the
disabled controls, if there was any.

2. because you do not have control over the user agent's cache usage,
you cannot assume any of the described behavior of a Back (button)
feature, if there is any. Especially, onload scripts are not executed
when using that feature and the document is accessed on the local cache.
but I'm not that good with JS yet.
Click to expand...

This is not really a JS issue. Either don't disable the controls on load
(which would be best, considering that there are UAs without client-side
script support) or refer to the form in the previous (or rather, "next")
document using a visible _HTTP_ hyperlink. You then should use HTTP
techniques to have the resource requested from the server again instead
from the local cache with the latter approach:

[...]
<script language="JavaScript">
Click to expand...

From HTML 4 on, the `language' attribute is deprecated for valid reasons
while the `type' attribute is required for the same reasons. As the latter
has proven to be sufficient, the above should read

function Disable_All()
Click to expand...

Using identifiers starting with capital letters for script items that are
not used as constructors is discouraged by several JS code style guidelines
to avoid confusion and unexpected side effects, and to increase legibility
of source code.
{
document.frmPost.employeename.className="disabled";
Click to expand...
^
Blocks of source code should be properly indented using a reasonable number
of spaces, where multiples of 2 and/or 4 are recommended, especially when
it is posted to a public medium like this newsgroup.
document.frmPost.employeename.disabled = true
Click to expand...
^
While the automatic semicolon insertion feature of the language
allows to omit semicolons, it is highly recommended to include
them explicitely and consequently anyway to avoid "odd" script
behavior not easily understandable to beginners.
[...]
for (var i = 0;i<8;i++){
document.frmPost.elements.hwreqested.disabled = true;
}
Click to expand...


1. DOM scripts should make use of standards compliant referencing whenever
possible, and always if that is also backwards compatible. The above
therefore should read

document.forms["frmPost"].elements["employeename"].className="disabled";
....
for (var i = 0;i<8;i++)
{
document.forms["frmPost"].elements["hwreqested"].disabled = true;
}

instead. Note that .disabled=true is not supposed to work in XHTML,
you (also) need .disabled="disabled" there.

2. Repeated lookups of the same object reference should be avoided
as such is inefficient; assign the reference to a local variable
and use that variable instead. If you use references within
a repeated block, assign the reference outside of the repeated
block if possible and feasible:

var
es = document.forms["frmPost"].elements,
hwreq = es["hwreqested"];

es["employeename"].className = "disabled";
...

for (var i = 0; i < 8; i++)
{
hwreq.disabled = true;
}
</Script>
Click to expand...

While the case of an element type identifier case does not matter in SGML
based markup languages like HTML, it does matter in XML based markup
languages like XHTML. Therefore, one should develop the habit of having
element type and attribute identifiers, and attribute values lowercased
where possible; especially, one should avoid mixing case with(in) the
start tag and the end tag of an element.
<body onLoad="Disable_All();">
Click to expand...

See above for how this event handler attribute value affects usability
of the document.


PointedEars
 
R

Richard Cornford

Thomas 'PointedEars' Lahn wrote:
for (var i = 0;i<8;i++)
{
document.forms["frmPost"].elements["hwreqested"].disabled = true;
}

instead. Note that .disabled=true is not supposed to work in
XHTML, you (also) need .disabled="disabled" there.
Click to expand...

<snip>

..disabled = true - most certainly is expected to work in an XHTML DOM.
The HTML DOM specification states that the disabled property of the
HTMLInputElement interface is a boolean property, and includes no
special notes for XHTML DOM implementations.

The - disabled - attribute in XHTML mark-up might differ from HTML but
there is no reason to expect that to carry through to the type, and
value, of the - disabled - property in the DOM, especially as the
attribute has no representation of not-disabled.

Richard.
 
R

RobG

Thomas 'PointedEars' Lahn wrote:
[...]
2. because you do not have control over the user agent's cache usage,
you cannot assume any of the described behavior of a Back (button)
feature, if there is any. Especially, onload scripts are not executed
when using that feature and the document is accessed on the local cache.
Click to expand...

onload scripts are executed[1] in both IE and Firefox when the 'back'
and 'forward' buttons are used.

[1] insert the usual caveat regarding script execution where the
browser can't or won't execute the script.

[...]
 
T

Thomas 'PointedEars' Lahn

Richard said:
Thomas 'PointedEars' Lahn wrote:
for (var i = 0;i<8;i++)
{
document.forms["frmPost"].elements["hwreqested"].disabled = true;
}

instead. Note that .disabled=true is not supposed to work in
XHTML, you (also) need .disabled="disabled" there.
Click to expand...

<snip>

.disabled = true - most certainly is expected to work in an XHTML DOM.
The HTML DOM specification states that the disabled property of the
HTMLInputElement interface is a boolean property, and includes no
special notes for XHTML DOM implementations.
Click to expand...


Right. However, it reproducably does not work in some implementations
I have encountered when reading newsgroups. Yes, such could be considered
borken. No, they are not this seldom. No, I also would have to use Google
to find out what they exactly were. Sorry.


PointedEars
 
R

Richard Cornford

Thomas said:
Richard said:
Thomas 'PointedEars' Lahn wrote:
for (var i = 0;i<8;i++)
{
document.forms["frmPost"].elements["hwreqested"].disabled =
true; }

instead. Note that .disabled=true is not supposed to work in
XHTML, you (also) need .disabled="disabled" there.
Click to expand...

<snip>

.disabled = true - most certainly is expected to work in an XHTML
DOM. The HTML DOM specification states that the disabled property
of the HTMLInputElement interface is a boolean property, and
includes no special notes for XHTML DOM implementations.
Click to expand...


Right. However, it reproducably does not work in some
implementations I have encountered when reading newsgroups.
Yes, such could be considered borken. No, they are not this
seldom. No, I also would have to use Google to find out what
they exactly were. Sorry.
Click to expand...


Not that reproducible without the name of the UA.

Richard.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Button enabling before all inputs are filled and disabling when all inputs are filled 1
Google sheets song request 3
Survey details won't go through using php, ajax, Mysql 0
Unable to add task to todo list 1
Re-enable disabled form elements when user goes 'Back' 27
disabling form elements in IE 4
Filename undefined for Blob ? 1
Backticks and class elemnt comby not working 1

Members online

No members online now.
Total: 94 (members: 1, guests: 93)
Robots: 227

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,817
Latest member
DicWeils

Latest Threads

Top