getting element IDs from nested standard forms in JavaScript

G

Guest

Okay, after much research, I have discovered a few interesting things in
ASP.NET.

I have a MasterPage that has a WebForm on it and it looks like this:

<body>
<form id="controls" runat="server">
<div id="bodyColumn">
<asp:ContentPlaceHolder id="bodyContentPlaceHolder" runat="server">
</asp:ContentPlaceHolder>
</div>
</form>
</body>

In a page the dervies from the MasterPage, I use another form but a standard
HTML Form that does not have the "runat=server" attribute.

<form name="MyForm">
<input type="text" name="zipcode" />
</form>

In JavaScript, I cannot do any of the following with success:

document.MyForm.zipcode.value;
document.forms["MyForm"].zipcode.value;

But these work:

document.forms[0].item("zipcode", 0).value;
document.forms[0].zipcode.value;

My question is really why do these behave in that way?

I did some further investigation and found that this snippet:

document.forms[0].name;

....returns a string: "aspnetForm"

However, if I add another standard form to my child page:

<form name="MyForm2">
<input type="text" name="phone">
</form>

then, doing this:

document.MyForm2.phone.value;
document.forms["MyForm2"].phone.value;

....does work. And, this:

document.forms[1].name;

....returns "MyForm2".

Why is all this happening?

Gurus on deck!

Thanks in advance,

Amrit
 
L

Laurent Bugnion [MVP]

Hi,

Amrit said:
Okay, after much research, I have discovered a few interesting things in
ASP.NET.

I have a MasterPage that has a WebForm on it and it looks like this:

<body>
<form id="controls" runat="server">
<div id="bodyColumn">
<asp:ContentPlaceHolder id="bodyContentPlaceHolder" runat="server">
</asp:ContentPlaceHolder>
</div>
</form>
</body>

In a page the dervies from the MasterPage, I use another form but a standard
HTML Form that does not have the "runat=server" attribute.

<form name="MyForm">
<input type="text" name="zipcode" />
</form>

In JavaScript, I cannot do any of the following with success:

document.MyForm.zipcode.value;
document.forms["MyForm"].zipcode.value;

But these work:

document.forms[0].item("zipcode", 0).value;
document.forms[0].zipcode.value;

My question is really why do these behave in that way?

I did some further investigation and found that this snippet:

document.forms[0].name;

...returns a string: "aspnetForm"

However, if I add another standard form to my child page:

<form name="MyForm2">
<input type="text" name="phone">
</form>

then, doing this:

document.MyForm2.phone.value;
document.forms["MyForm2"].phone.value;

...does work. And, this:

document.forms[1].name;

...returns "MyForm2".

Why is all this happening?

Gurus on deck!

Thanks in advance,

Amrit

I am confused by your confusion. What did you think would happen?

Note that all these specialized collections (like forms, images...) are
DOM Level 1, and shouldn't be used anymore. Now we have DOM level 2 in
all modern browsers, and document.getElementById is the way to go.

(of course it means that your elements must have a unique ID, which is
recommended anyway).

HTH,
Laurent
 
G

Gaurav Vaish \(MasterGaurav\)

Not sure where the problem is... but having an 'id' of the form and then
searching is by rather inefficient methdo of document.getElementById(...)
should work.
 
M

Masudur

Hi...
try the alternative method...
that is
$get('controlID').property
example
$get('txtName').value = 'Masudur';

Thanks
Masudur
www.kaz.com.bd

Not sure where the problem is... but having an 'id' of the form and then
searching is by rather inefficient methdo of document.getElementById(...)
should work.

--
Happy Hacking,
Gaurav Vaish |www.mastergaurav.comwww.edujini-labs.comhttp://eduzine.edujinionline.com
-----------------------------------------



Okay, after much research, I have discovered a few interesting things in
ASP.NET.
I have a MasterPage that has a WebForm on it and it looks like this:
<body>
<form id="controls" runat="server">
<div id="bodyColumn">
<asp:ContentPlaceHolder id="bodyContentPlaceHolder" runat="server">
</asp:ContentPlaceHolder>
</div>
</form>
</body>
In a page the dervies from the MasterPage, I use another form but a
standard
HTML Form that does not have the "runat=server" attribute.
<form name="MyForm">
<input type="text" name="zipcode" />
</form>
In JavaScript, I cannot do any of the following with success:
document.MyForm.zipcode.value;
document.forms["MyForm"].zipcode.value;

But these work:
document.forms[0].item("zipcode", 0).value;
document.forms[0].zipcode.value;
My question is really why do these behave in that way?
I did some further investigation and found that this snippet:
document.forms[0].name;

...returns a string: "aspnetForm"
However, if I add another standard form to my child page:
<form name="MyForm2">
<input type="text" name="phone">
</form>
then, doing this:
document.MyForm2.phone.value;
document.forms["MyForm2"].phone.value;

...does work. And, this:
document.forms[1].name;

...returns "MyForm2".
Why is all this happening?
Gurus on deck!
Thanks in advance,
Amrit- Hide quoted text -- Show quoted text -
 
L

Laurent Bugnion [MVP]

Hi,
Hi...
try the alternative method...
that is
$get('controlID').property
example
$get('txtName').value = 'Masudur';

There is not $get method in client side JavaScript, at least not in all
the browsers I know. Some 3rd party frameworks declare new methods with
shorter name to avoid typing document.getElementById every time, but in
the end, it's still that method that is called. I personally find this
practice very bad.

HTH,
Laurent
 
L

Laurent Bugnion [MVP]

Hi,
Not sure where the problem is... but having an 'id' of the form and then
searching is by rather inefficient methdo of document.getElementById(...)
should work.

Could you change the settings of your newsreader so that your signature
appears after the quoted material? (alternatively, you could follow good
practice and bottom post... :)

document.getElementById is not very performant, that's true. It has
however huge advantages over DOM Level 1 collections. Cross
compatibility has a cost, I guess...

For methods accessing the DOM in an intensive way, one could always save
the reference to the Node after it has been gotten using
document.getElementById once. Also, once you get hold of a node using
that method, you can navigate to DOM using firstChild, lastChild, etc...
which are *extremely* faster.

HTH,
Laurent
 
B

bruce barker

nested forms are not supported by html, so erratic results are expected.

now as what is happening. master pages create a form named aspnetForm
which will be form[0]. as people are used to putting form tags on asp
pages, this would cause trouble with a master page (as nested forms are
not allowed, nor do aspnet control support nesting), so if found the
first form is thrown away. any additional forms (which is still an html
error) are left alone.


-- bruce (sqlwork.com)
 
G

Gaurav Vaish \(MasterGaurav\)

Could you change the settings of your newsreader so that your signature
appears after the quoted material? (alternatively, you could follow good
practice and bottom post... :)

I generally follow the 'bottom post'... I think I missed that here :D
the reference to the Node after it has been gotten using
document.getElementById once. Also, once you get hold of a node using that
method, you can navigate to DOM using firstChild, lastChild, etc... which
are *extremely* faster.

One question here... I was just wondering about the 'Node-Caching'.
If I know that I will need to use 10-15 nodes whose references are not known
during page loading, I can probably use a global-variable (may be
packaged/moduled), say, importantReferences (= new Object()) and then
whenever I get the IDs and references, I can probably do a:

importantReferences[id] = document.getElementById(id)

So that next time, I first do a lookup in importantReferences

if(!importantReferences[id]) { document... }

Do you see any issues with this in terms of memory hogging or leakage?
Yes... one thing that I need to take care is that when the node is removed
from the HTML-tree, I must not forget to remove it from my 'cache'.

Anything else?


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujini-labs.com
http://eduzine.edujinionline.com
-----------------------------------------
 
L

Laurent Bugnion [MVP]

Hi,
Could you change the settings of your newsreader so that your signature
appears after the quoted material? (alternatively, you could follow good
practice and bottom post... :)

I generally follow the 'bottom post'... I think I missed that here :D
the reference to the Node after it has been gotten using
document.getElementById once. Also, once you get hold of a node using that
method, you can navigate to DOM using firstChild, lastChild, etc... which
are *extremely* faster.

One question here... I was just wondering about the 'Node-Caching'.
If I know that I will need to use 10-15 nodes whose references are not known
during page loading, I can probably use a global-variable (may be
packaged/moduled), say, importantReferences (= new Object()) and then
whenever I get the IDs and references, I can probably do a:

importantReferences[id] = document.getElementById(id)

So that next time, I first do a lookup in importantReferences

if(!importantReferences[id]) { document... }

Do you see any issues with this in terms of memory hogging or leakage?
Yes... one thing that I need to take care is that when the node is removed
from the HTML-tree, I must not forget to remove it from my 'cache'.

Anything else?

Generally speaking, memory leaks on the web are rare, because all the
JavaScript variables are recycled when the page is refreshed, and
garbage collected. However, with the appearance of AJAX-enabled pages,
we have scenarios where a page can remain active for days without being
refreshed. In this case, memory leaks can appear on the client. They are
not catastrophic for the machine, because it doesn't crash, but it can
slow things down extremely, and finally force the user to restart IE.

Memory leaks are actually quite easy to cause, because the JavaScript
engine, the HTML engine (DOM) and the CSS engine do not share
references. It's quite easy to create circular references, which will
then prevent the object to be garbage collected, even when the variable
is not used anymore. This is where you have to be extra careful.

Also, due probably to IE's implementation, and though we talked often
and quite long with Microsoft's IE team, we still notice that the number
of handles grows continuously when leaving a webpage open and usng AJAX
to refresh parts of it regularly. Not really a memory leak, but bottom
line is: IE was not made for such scenarios. After 2 weeks or so, we
restart the client to solve these problems.

Other than that, for example in "normal" scenarios where the client is
refreshed regularly, and where sessions usually don't last more than a
few minutes or a few hours, I don't see any problems with storing nodes
the way you propose.

I want to underline again the possibility to store one node and to then
navigate to the others using firstChild, lastChild and other such
properties. It avoids saving too many nodes, and it's very fast.

HTH,
Laurent
 

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

Members online

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,813
Latest member
lawrwtwinkle111

Latest Threads

Top