Simon Brooke wrote:
> I've been doing XSL transforms, converting XML to HTML, server side since
> 2000. In those days, clients which could do the transformation client
> side didn't exist,

Well they certainly did exist, because I had production code doing this
throughout '99.

> so whether to transform client-side or server-side wasn't an issue.

It was a horrible issue - very few clients supported it. Even for IE
you had to be careful just which version of MSXML was available. I had
client-side JScript that could tell, but I had to report this back to
the server with an explicit flag, there wasn't anything in the standard
HTTP headers.

I mainly did it by IP address, or by login credentials. I was doing
AJAX-like downloads of huge browse trees into user controls. Although
it was a useful feature, I just couldn't expect it to work outside our
intranet and some carefully installed IEs with the latest MSXML
deployed to them. The extranet users had to lump it with a server-side
version (fortunately they were just read-only query users, not data
entry).

I also disliked doing pure client-side transforms of the whole page.
Users saw a blank screen while  the transform was going on, and if
anything failed they were left with nothing. I much preferred a "data
island" approach where they had a basic no-data page and a "loading..."
message, which then filled out a <div> with ther transform's result.
The "data island" could either by synch (with the <XML> tag) or asynch
(XmlHttpRequest), because it was all IE-only code anyway.


> Recently I've been overhauling the code in order to pass transform to the
> client wherever possible, and I've hit two problems

I now do it by looking at the HTTP headers for some explicit request
that I add from client-side AJAX code. I (still) just don't bother with
client-side XSLT for "traditional" request-serve HTTP processing.  If
you need this transform, then it's for some sophisticated asynchronous
"not quite so thin" client. Basic "do a GET and return HTML" processing
can stick with it server-side.

OK, so I'm not getting the reduced server load and bandwidth shrinkage
of a client-side transform. But servers are fast and pipes are fat
these days. I still get the extra functionality when I want it.

If I do use client-side from a simple GET, it's flagged in the session
state and I've already identified the capability by more sophisticated
means. The flag also goes into the URL, to support re-visiting future
bookmarks. These break if you exchange bookmarks between capable and
non-capable clients, but I have enough basic nav to allow recovery from
this that's only slightly ugly.