Wanting to use getElementById()

[Tim Streater]

My app displays a table in a browser window. The user has the option to
display a different table by clicking a button. I effect this by
switching table bodies - I have an array containing pointers to a set of
tbodies.

Now, while this all works OK, if I wish to search for a row in such a
table body by id, I'm only using getElementById() on the tbody that
happens to be in the DOM just now. If I want to look for a row in
another tbody, I'm having to search for that by hand with a JavaScript
loop, which I assume is a lot slower than using getElementById.

To get round this, I'm thinking that if I can create another document, I
could append the tbody I want to search to that and then use
getElementById on the result. Something like:

mydocPtr = document.createElement("document");
mydocPtr.appendChild(tbodyPtr);
rowPtr = mydocPtr.getElementById(someId);

Can I create a document element in this way? Anything I should be wary
of?

 

[Evertjan.]

Tim Streater wrote on 09 dec 2011 in comp.lang.javascript:

My app displays a table in a browser window. The user has the option to
display a different table by clicking a button. I effect this by
switching table bodies - I have an array containing pointers to a set of
tbodies.

Now, while this all works OK, if I wish to search for a row in such a
table body by id, I'm only using getElementById() on the tbody that
happens to be in the DOM just now. If I want to look for a row in
another tbody, I'm having to search for that by hand with a JavaScript
loop, which I assume is a lot slower than using getElementById.

To get round this, I'm thinking that if I can create another document, I
could append the tbody I want to search to that and then use
getElementById on the result. Something like:

mydocPtr = document.createElement("document");
mydocPtr.appendChild(tbodyPtr);
rowPtr = mydocPtr.getElementById(someId);

Can I create a document element in this way? Anything I should be wary
of?

Make up two tables [or tbody-s] one being display:none;-ed by default,
and switch to display the other instead by javascript.

function showTable(x) {
document.getElementById('table1').style.display = 'none';
document.getElementById('table2').style.display = 'none';
document.getElementById(x).style.display = 'block';
};


Both their inividual td-elements stay accessable
through their different getElementById()-s
even when not displayed.

 

[Tim Streater]

Tim Streater wrote on 09 dec 2011 in comp.lang.javascript:

My app displays a table in a browser window. The user has the option to
display a different table by clicking a button. I effect this by
switching table bodies - I have an array containing pointers to a set of
tbodies.

Now, while this all works OK, if I wish to search for a row in such a
table body by id, I'm only using getElementById() on the tbody that
happens to be in the DOM just now. If I want to look for a row in
another tbody, I'm having to search for that by hand with a JavaScript
loop, which I assume is a lot slower than using getElementById.

To get round this, I'm thinking that if I can create another document, I
could append the tbody I want to search to that and then use
getElementById on the result. Something like:

mydocPtr = document.createElement("document");
mydocPtr.appendChild(tbodyPtr);
rowPtr = mydocPtr.getElementById(someId);

Can I create a document element in this way? Anything I should be wary
of?

Make up two tables [or tbody-s] one being display:none;-ed by default,
and switch to display the other instead by javascript.

function showTable(x) {
document.getElementById('table1').style.display = 'none';
document.getElementById('table2').style.display = 'none';
document.getElementById(x).style.display = 'block';
};


Both their inividual td-elements stay accessable
through their different getElementById()-s
even when not displayed.

Mmmm, nice idea. I do have a variable number of these tables, but that
wouldn't create an insurmountable problem. More of a problem is that I
would then have id conflicts - each table has a similar set of row-id's.
I expect I could get around this too at the expense of a certain amount
of recoding.

Is there anything wrong (or dangerous) about what I'm considering, that
you know of?

 

[Swifty]

would then have id conflicts - each table has a similar set of row-id's.
I expect I could get around this too at the expense of a certain amount
of recoding.

Faced with a similar problem, I ensured that the element ID's were
unique by encoding the table number, the row number, and the column
number in the ID, ending up with ID's such as C_5_217_9 (Cell in table
5, row 217, colum 9).

 

[Tim Streater]

Faced with a similar problem, I ensured that the element ID's were
unique by encoding the table number, the row number, and the column
number in the ID, ending up with ID's such as C_5_217_9 (Cell in table
5, row 217, colum 9).

Exactly.

 

[Evertjan.]

Swifty wrote on 10 dec 2011 in comp.lang.javascript:

Faced with a similar problem, I ensured that the element ID's were
unique by encoding the table number, the row number, and the column
number in the ID, ending up with ID's such as C_5_217_9 (Cell in table
5, row 217, colum 9).

That is so if you stick to individual ids [ ideas? ;-) ]
of total gebi() control.

However if the tables are roughly similar but for the content,
why not:

document.getElementById('table1').rows(217).cells(9)
document.getElementById('table5').rows(217).cells(9)

[rows and cells counts start at 0]

=========================================

Better use a function:

function getTableCell(t,r,c) {
return document.getElementById(t).rows(r).cells(c);
};

getTableCell('table1',217,9).style.color = 'green';
getTableCell('table5',217,9).style.color = 'red';

var theCell = getTableCell('table88',2,1);
alert(theCell.innerHTML);
theCell.style.color = 'red';

var otherCell = getTableCell('table15',2,11);
if (theCell.innerHTML != +otherCell.innerHTML+6)
theCell.innerHTML = +otherCell.innerHTML+12;

 

[Tim Streater]

Swifty wrote on 10 dec 2011 in comp.lang.javascript:

Faced with a similar problem, I ensured that the element ID's were
unique by encoding the table number, the row number, and the column
number in the ID, ending up with ID's such as C_5_217_9 (Cell in table
5, row 217, colum 9).

That is so if you stick to individual ids [ ideas? ;-) ]
of total gebi() control.

However if the tables are roughly similar but for the content,
why not:

document.getElementById('table1').rows(217).cells(9)
document.getElementById('table5').rows(217).cells(9)

When I construct the table, I want to later be able to find a given row,
so I can modify it. From the SQLite db I get the data from, I have a db
name (or number) and the rowid. So far I've been making up an id for the
row (as they are added to the tbody) just using the rowid, as in:

id = 'M' + rowid;

Simple enough to extend that to include the db number.

But I'd still like to know whether:

mydocPtr = document.createElement('document');

is allowed.

 

[Evertjan.]

Tim Streater wrote on 10 dec 2011 in comp.lang.javascript:

But I'd still like to know whether:

mydocPtr = document.createElement('document');

is allowed.

What would you want to use that for?

As an equivalent for:

document.open()
document.write('....')

?

 

[Tim Streater]

Tim Streater wrote on 10 dec 2011 in comp.lang.javascript:

What would you want to use that for?

As an equivalent for:

document.open()
document.write('....')

As a document to which I can append a tbody, that I can then search with
getElementById(), as I said in my first post.

 

[Evertjan.]

Tim Streater wrote on 10 dec 2011 in comp.lang.javascript:

As a document to which I can append a tbody, that I can then search with
getElementById(), as I said in my first post.

Why would you want to append a tbody to a document?

A tbody should only be appended to a table element, meseems.

 

[Tim Streater]

Tim Streater wrote on 10 dec 2011 in comp.lang.javascript:


Why would you want to append a tbody to a document?

A tbody should only be appended to a table element, meseems.

I'm well aware of that, Evertjan. Stop being so perverse. I'd make the
document, append a table and then put the tbody on that.

 

[Evertjan.]

Tim Streater wrote on 10 dec 2011 in comp.lang.javascript:

I'm well aware of that, Evertjan. Stop being so perverse. I'd make the
document, append a table and then put the tbody on that.

Doesn't the document exist from the beginning of creation of your page?

 

[Denis McMahon]

But I'd still like to know whether:

mydocPtr = document.createElement('document');

is allowed.

I think that for an html document, document.createElement has to take a
valid html element name.

A simple empirical test suggests that it won't work in all browsers.

Rgds

Denis McMahon

 

[Thomas 'PointedEars' Lahn]

I think that for an html document, document.createElement has to take a
valid html element name.

A simple empirical test suggests that it won't work in all browsers.

Please publish your results so that people who are still doing it are given
something to think about.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <timstreater-095030.23590509122011@news.
individual.net>, Fri, 9 Dec 2011 23:59:05, Tim Streater

Mmmm, nice idea. I do have a variable number of these tables, but that
wouldn't create an insurmountable problem. More of a problem is that I
would then have id conflicts - each table has a similar set of row-
id's. I expect I could get around this too at the expense of a certain
amount of recoding.

Is there anything wrong (or dangerous) about what I'm considering, that
you know of?

My <http://www.merlyn.demon.co.uk/holidays.htm> has a number of tables
constructed by writing their computed HTML. The tables are all
essentially the same, but constructed in accordance with a data object
which gives the number of rows and their content. One column can be re-
computed by altering its heading cell. As I recall, or at least as I
would do it now, all addressing of elements within a table is relative
to that table, not global.

If I were starting again, I'd build the table by DOM methods, as in js-
props.htm or more accurately inc-prop.js.

IMHO, getElementById is something like GO TO (GOTO?) in FORTRAN; one
should use it as little as practical.

 

[Gene Wirchenko]

On Tue, 13 Dec 2011 19:52:26 +0000, Dr J R Stockton

[snip]

IMHO, getElementById is something like GO TO (GOTO?) in FORTRAN; one
should use it as little as practical.

1) In very few cases are spaces significant in Fortran. You can use
either. Note the change in the spelling of "Fortran". It used to be
all caps. It is not now.

2) Thank you for the excuse to not use getElementById.

Sincerely,

Gene Wirchenko

 

[Dr J R Stockton]

In comp.lang.javascript message <hrufe79d6t4i8pgvcukl6rc6rhre8kvj9p@4ax.

On Tue, 13 Dec 2011 19:52:26 +0000, Dr J R Stockton

[snip]

IMHO, getElementById is something like GO TO (GOTO?) in FORTRAN; one
should use it as little as practical.

1) In very few cases are spaces significant in Fortran. You can use
either. Note the change in the spelling of "Fortran". It used to be
all caps. It is not now.

I ceased using FORTRAN long before any such new-fangled ideas.


I recall one case where spacing was significant. This was in some
version of HP FORTRAN, not that it matters. A colleague complained of
an inscrutably failing COMMON statement. I don't recall the variable
names, but the code resembled

COMMON THIS, THAT, ..., ..., ..., THING, TOTHER,
C SOMETHINGELSE

but TOTHER just did not act as a COMMON, although all the others did.
We stared at the screen in disbelief. Eventually I observed that TOTHER
started in a position which might well have been column 73 or 74, and
light dawned. Had he not put spaces after his commas ...

 

[Gene Wirchenko]

On Thu, 15 Dec 2011 21:51:49 +0000, Dr J R Stockton

[snip]

I recall one case where spacing was significant. This was in some
version of HP FORTRAN, not that it matters. A colleague complained of
an inscrutably failing COMMON statement. I don't recall the variable
names, but the code resembled

COMMON THIS, THAT, ..., ..., ..., THING, TOTHER,
C SOMETHINGELSE

but TOTHER just did not act as a COMMON, although all the others did.
We stared at the screen in disbelief. Eventually I observed that TOTHER
started in a position which might well have been column 73 or 74, and
light dawned. Had he not put spaces after his commas ...

Column 73 and on have bitten more than a few people.

When I was taking a COBOL course in my diploma, I was very
careful about column 73. Any other student would have been wondering
what I was about.

Sincerely,

Gene Wirchenko