Fog Creek Software
Discussion Board




Is anyone using MSXML on the client?

I'm working on some rich-client browser stuff and have found MSXML 4.0 to be a significant improvement in performance, features and standards compliance.

Anyone doing anything interesting with client-side xml processing?

Dan Sickles
Tuesday, August 13, 2002

Of course! Just have it load the XML and parse and XSL on the client side. You get locked into a browser version, but it's a great technique. Many large companies are using just this as thier metal to their frameworks. Distributed coding/programming and allow the clients to ingest most of the parsing of the presentation.

Thomas
Tuesday, August 13, 2002

I'm doing XSLT for the frequently loaded tabular data. Hww about filtering on the source tree? I haven't used TreeWalker yet.

Dan Sickles
Tuesday, August 13, 2002

My company, on its third attempt to do a web project (before my time) decided to download lots and lots of XML to the client.

It turned the application into a dog - lots of wordy messages to be sent over the wire and then parsed.  The project was so slow it was eventually cancelled.

We're now doing something a lot more rational: serving simple HTML and a little (very little) JavaScript and nothing else.

Patrick Carroll
Tuesday, August 13, 2002

Patrick, at what granularity was the messaging? If I send a simple http request, using XMLHttpRequest,  for enough xml to display a table and use xsl to do the html, is this perceptibly slower than just sending the html? Or skipping the xsl, XMLHttpRequest could get XHTML and that could be added to the display doc as is.  I'm just thinking of doing what we used to do by submiting a doc in a hidden frame etc....

Dan Sickles
Tuesday, August 13, 2002

Clever stuff in a browser -- honestly, don't bother. New version of IE comes out -- nefarious little idiosyncrasies crop up. If you want a clever client - write a windows app.

And yes theoretically you think it shoudl be faster - passing less data over the wire. Inevitably though they're ALWAYS slower and more sluggish!

Dunc
Tuesday, August 13, 2002

Yeah here's a list of changes for IE6 ap1 that will affect existing code:

http://jscript.dk/2002/8/ie6-sp1-highlights.txt

But, for my application I can assume a fairly stable client. I'm just looking for experiences in distributing the processing.

Dan Sickles
Tuesday, August 13, 2002

Dan :- The application used to send between tens of kilobytes and megabytes of XML.  Not good design, I agree.  But, well, as a king of France once said, "apres moi le deluge".

Actually, now that I think of it, there were other issues, like having to check that MSXML3 was installed, etc.  And don't get me started on the people using AOL as their browser.

In the end, it's just turned out to be easier to serve just HTML.

Patrick Carroll
Wednesday, August 14, 2002

hakmanpeachey.com

pb
Wednesday, August 14, 2002

I'm actually using small pieces of xml, serving the UI once and a publish/subscribe model for content.

The most interesting product for the pub/sub is something like www.knownow.com

I've had good ssuccess with DHTML (sticking to standards). But MS offers some very compelling client-side XML stuff, they're ahead of Mozilla here, so I'm exploring that for filtering, sorting etc. instead of doing it all in JS.

Dan Sickles
Thursday, August 15, 2002

We've written a database form engine for in-house use (it'd exclude too much of an outside audience requiring IE 5.5 and MSXML3) using ASP and MSXML4 on the server and JavaScript and MSXML3 on the client.  To use it we define a form and its relationship to the database in XML, register the form with the system (the organization is too big to trust any user with any database, plus we're a hospital so some databases have confidential information), and then access the form through our form engine or through simple wrappers to the engine (for custom functions, etc.). When a user loads the form engine page, it includes 50+kB of JavaScript. The JS passes the path of the form definition we're using to the server which returns an XML document that is either just a template for the form or else a template plus a filled-in template if we're editing a record that already exists.

Sorry for the long background--on to the client-side use of MSXML! On the client, we hold the XML form/template in memory but display it by transforming it into a pleasant-looking (and institution-colored ;-) ) HTML page. Users click plain text to turn the text in to a form field (variety of datatypes supported, so there are text inputs, textareas, selects, radio buttons, checkboxes, etc.). When the user finishes editing a field we validate the data and modify the XML template in memory with the new value. Then we use .transformNode() and the DOM functions to re-render just the relevant part of the document.  At the end we strip out some things that won't matter to the server and send the whole XML document back to the server, which runs some security checks and builds inserts, updates, and deletes from the form data. We go to all this XML/XSL/DOM effort instead of just using standard forms and posts because we need the forms to be able to support adding whole new joined rows as children of the current record. For example, in one of our databases a presentation can have more than one speaker. Each speaker has a name, title, etc. and can also belong to one or more institutions. We use XML/XSL/DOM to add sections to the page as needed. In order to provide a single page for entering a presentation and provide a fluid experience without continual trips back to the server, we had to make the client smart about the structure of the data and have a way to represent fairly elaborate heirarachies in the form data.

We're only using MSXML3 on the client b/c more of our systems already have it installed. Also, there are some substantial bugs with MSXML4 (e.g., all pointers from nodes to other nodes like .lastChild, .prevSibling, etc. "break" instead of returning null when they should be null). We send a fair amount of data over the wire, but it doesn't make a lot of difference for us since the slowest connection here is 100Mb/s. Using MSXML3, loading and transforming the initial form can cause a noticeable lag for very large/complicated forms. There is a very small lag for simpler forms. Both are acceptable for us.

-Joshua <><

Joshua Paine
Monday, August 19, 2002

*  Recent Topics

*  Fog Creek Home