Andy Dingley <di*****@codesm iths.com> wrote in message news:<jc******* *************** **********@4ax. com>...
On 12 Jul 2003 10:44:14 -0700, cm**@walshgroup .com (Chris) wrote:
Adding "xmlns=somethin g" to the "html" tag, and then using
<something:myt ag> for my custom tags.
Surely xmlns:foo="some thing" and <foo:mytag> ?
Yea, I mistyped.. I have been using: <html xmlns:costrepor t>.
Does anyone know why this worked when normal custom tags didn't work?
I presume that by "worked" you mean "IE ran it at least once without
barfing". I suspect that the presence of namespace non-HTML elements
causes them to be handled differently in the DOM (maybe loaded into a
parallel XML-like DOM). You're way off the standards track here, and
into the Seattle banjo country.
I figured this was probably something weird. I can't really find any
documentation about what is going on. I can locate custom elements in
the HTML DOM just fine, without putting in xmlns:asdf in the HTML tag,
but if I get a reference to a custom element in javascript, and try to
have it return its childNodes, I get nothing.
4MB sucks as HTML. Far too big, and you'll get timeouts.
4MB is probably the most extreme case. A more realistic size would be
1MB.
Will the browser time out, even if it is getting a steady stream of
HTML coming down?
I've done very similar stuff to this in the past, but I went with XML
data islands. Yes, it's IE-dependent, but like most of my work, this
was an intranet. Rather than loading my squiggabyte of data into the
HTML in-line, I loaded it through an XML DOM ActiveX object, created
from JScript on the page (NB - not the <XML> element).
So you instantiated an instance of the MSXML parser from Javascript,
loaded a remote XML document, and then had it write out the HTML you
wanted (document.write or foo.innerHTML = xdoc.something right?)?
I considered doing something like this as well, and if I could start
from scratch this is probably how I would do it. Or, maybe just pass
down an XML document with an associated XSLT that would make the page
look like we want.
BTW, this is an intranet thing too, so we can be IE-Dependent as well.
Eventually I went to a load-on-demand architecture for this, where I
loaded chunks of tree as needed (it drove a hierarchy browser). I had
something like 20MB of potential XML, but rarely needed more than
100K. For initial building while I coded the interface though, I just
loaded the whole XML dataset at startup.
At first I built a totally awsome server side app to do this project.
It would load stuff on demand and display the data in a hierarchical
manner, and would cache the data on the server to ensure a minimal
number of trips to the database. It was truly awsome, and I couldn't
have been more proud of it. However, the powers that be wanted to see
all the data, not just some of it.
Do you know how long would it take to load a 1MB XML document into an
XML Parser running in Javascript (best guess)? 1 second? 5 seconds?
more?
I'm SURE that if we were to send the data as XML to the clients
browser, and cut out all the unnecessary HTML, we could make the size
of the document 1/4 as big, if not even smaller as you could do stuff
like changing <mycustom:proje ct> tags into <m:p>, and stuff like <td
class="NoBorder TD" colspan="3">&nb sp;</td> which are repeated a ton of
times would be programmed into the code or XSLT once.
Man that would kick ass... There is a little more pressure to get
something done here, than to really do something of the upmost
quality/performance. Quick and dirty wins the race I guess.