Re: Perf prob with IE

IE doesn't use DOM for tables, it uses its proprietary TOM.
The DOM's childhead in this case is just a mimic interface atop of TOM (to
keep 3W happy).

(1) So the first major "perf" improvement you are getting by working
directly with TOM:

if (navigator.appName.indexOf('Microsoft')! =-1) {
/* a sample iteration thru all cells,
presuming you have only one <tbody> tag: */
var oBody = document.getElementById(tableID).tbodies[0];
for (i=0;oBody.rows.length;i++) {
for (j=0;oBody.rows[i].cells.length;i++) {
if (oBody.rows[i].cells[j] == myCriteria) {
/* Or: oBody.rows[i].cells[j].innerHTML == myCriteria */
/* (2) The runtime style class reassignments seems very academically
profound,
but it's VERY resource consuming.
You are saving A LOT by using runtimeStyle object,
and by changing only properties you need to change */
oBody.rows[i].cells[j].runtimeStyle.backgroundColor = highlightColor;
}
}
}
}

(3) If you are getting data updates from the server, then the server knows
what cells have been changed. So instead of making your script behave like a
tiger in the cage, looping every time thru all cells, you could receive
{i,j} indexes of updated cells directly from your server.

(4) Actually all this structure is "screaming" for data binding, this would
give you the "max perf".

VK wrote:

IE doesn't use DOM for tables, it uses its proprietary TOM.
The DOM's childhead in this case is just a mimic interface atop of TOM (to
keep 3W happy).

(1) So the first major "perf" improvement you are getting by working
directly with TOM:

if (navigator.appName.indexOf('Microsoft')! =-1) {

<--snip-->

And you have just introduced a very unreliable method into your script.
Namely, by trying to identify the browser based on the navigator object.
A better solution is to test for the actual object/properties you want
to use. The c.l.j FAQ covers it.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq

if (navigator.appName.indexOf('Microsoft')! =-1) {

--snip--

And you have just introduced a very unreliable method into your script.
Namely, by trying to identify the browser based on the navigator object.
A better solution is to test for the actual object/properties you want
to use. The c.l.j FAQ covers it.

Exceptions are just proof of the rule :-)

In this particular case:
1) There is only one browser using TOM, and it will be only one (unless
Mozilla & Co deside to drop standards and follow Microsoft :-).
2) Methods/properties check gets more and more difficult in IE, because they
are actively covering their non-standard parts with mimic DOM-interfaces,
like one mentioned in my OP.

So in this particular case a simple name check MAY be the most reliable way.

On Tue, 7 Dec 2004 14:48:12 +0100, VK <schools_ring (AT) yahoo (DOT) com> wrote:

[snip]

1) There is only one browser using TOM, and it will be only one (unless
Mozilla & Co deside to drop standards and follow Microsoft :-).

If you're dealing solely with IE, then use conditional comments. However,
I can't recall having any problems using the W3C DOM to manipulate table
structures in IE.

[snip]

So in this particular case a simple name check MAY be the most reliable
way.

No, it won't. The very reason for not sniffing is that browsers do fake
their identity, but more often than not, they do not actually emulate that
browser functionally. Your test would pick up Opera if it were spoofing
IE, but Opera only has limited support for the proprietary nonsense that
IE includes.

If you'd rather use Microsoft's proprietary object model, then test for
that before methods and properties of the W3C DOM.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

I can't recall having any problems using the W3C DOM to manipulate table
structures in IE.

Mmm... Clone rows within the table or to another table? Get/alter rows'
content? Speedy cells manipulation in a Big x Big table (see the OP)?

So in this particular case a simple name check MAY be the most reliable
way.

No, it won't.

<snip>

Conceived and agreed
:-) :-|

On Tue, 7 Dec 2004 15:58:13 +0100, VK <schools_ring (AT) yahoo (DOT) com> wrote:

I can't recall having any problems using the W3C DOM to manipulate
table structures in IE.

Mmm... Clone rows within the table or to another table?

Yes. IE has no problem with HTMLTableRowElement.cloneNode nor
HTMLTableSectionElement.appendChild.

Get/alter rows' content?

Yes, but I'll admit that can get awkward. It depends on the content and
what you're doing with it.

Speedy cells manipulation in a Big x Big table (see the OP)?

Personally, I wouldn't attempt to do that at all in a browser. It's not
suited to the job.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

"VK" <schools_ring (AT) yahoo (DOT) com> wrote:

Speedy cells manipulation in a Big x Big table (see the OP)?

http://www.quirksmode.org/dom/innerhtml.html suggests the OP should
give recreating the table in a string and then assiging using innerHTML
a try.

Bye,
Martin