| re: keep form elements enabled on "back" request
Dani wrote:
[color=blue]
> 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?[/color]
No.
[color=blue]
> I was thinking maybe utilizing some referrer thing,[/color]
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.
[color=blue]
> but I'm not that good with JS yet.[/color]
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:
<http://www.mnot.net/cache_docs/>
[color=blue]
> [...]
> <script language="JavaScript">[/color]
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
<script type="text/javascript">
[color=blue]
> function Disable_All()[/color]
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.
[color=blue]
> {
> document.frmPost.employeename.className="disabled" ;[/color]
^
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.
[color=blue]
> document.frmPost.employeename.disabled = true[/color]
^
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.
[color=blue]
> [...]
> for (var i = 0;i<8;i++){
> document.frmPost.elements.hwreqested[i].disabled = true;
> }[/color]
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"][i].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[i].disabled = true;
}
[color=blue]
> </Script>[/color]
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.
[color=blue]
> <body onLoad="Disable_All();">[/color]
See above for how this event handler attribute value affects usability
of the document.
PointedEars
| 
