By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,823 Members | 730 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,823 IT Pros & Developers. It's quick & easy.

Performing XSL Translation on Client vs. Server

P: n/a
Our web application currently uses MSXML 4.0 to perform XSL
translation of our XML document into HTML which is then delivered to
the client's browser. By specifying the XSL file used for translation
in the XML file, we can simply send the XML document to the client's
browser and have the browser perform the translation for us. This
reduces the amount of processing that must be performed on the server.

I know certain browser versions install MSXML 3.0 by default and that
should not be a problem since we are not doing anything special that
3.0 can't handle. The organization using this web application has a
requirement that users have IE 5.5 or higher.

Can anyone provide pros and cons of doing this and recommend which
approach we should follow?

Thanks,
Michael Levy
Jul 20 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On 23 Apr 2004 15:52:17 -0700, Mi*****@MichaelLevy.net (Michael)
wrote:
Can anyone provide pros and cons of doing this and recommend which
approach we should follow?


Do it server-side. Look at caching downstream of the server.

I only ever use client-side as a way of doing complex data-browsers on
intranets. These are all data islands (embedded on a static HTML page)
and there's usually client-sde scripting to control sort order,
filters etc. Very powerful, very useful, not much use for the public
web.

I don't use client-side XSL (serving a bare XML document with a
stylsheet boudn to it) at all. I have done in the past, but not now.
It's not friendly or reliable to the public web, and data islands give
a better "user experience" (especially after errors) for user groups
where I know I can guarantee client-side XSL support.

Also look at dynamically serving different content, depending on the
user agents. You can offer a basic page (server-side XSLT) and a more
functional (data island) page if you know the browser can support it.
Typically I've built systems that did this for various filter or sort
orders. The "smart" version did it on the browser quickly, the "dumb"
version round-tripped it to the server for a new page.

--
Smert' spamionam
Jul 20 '05 #2

P: n/a
On Fri, 23 Apr 2004 15:52:17 -0700, Michael wrote:
Our web application currently uses MSXML 4.0 to perform XSL
translation of our XML document into HTML which is then delivered to
the client's browser. By specifying the XSL file used for translation
in the XML file, we can simply send the XML document to the client's
browser and have the browser perform the translation for us. This
reduces the amount of processing that must be performed on the server.

I know certain browser versions install MSXML 3.0 by default and that
should not be a problem since we are not doing anything special that
3.0 can't handle. The organization using this web application has a
requirement that users have IE 5.5 or higher.

Can anyone provide pros and cons of doing this and recommend which
approach we should follow?

Thanks,
Michael Levy


Client side transformations are the work of the devil! The only time it is
acceptable to do the transformation client side (IMO) is for intranet
applications where an organiastion has strict control over client
configurations and can aford the support hassles for the
machines under which the transformations just will not work! (Trust me ,
it happens).

If youre considering the approach for a internet application - expect to
lose eye-balls and customers for those (and there will be many) who the
site does not work for. In addition if youre based in Europe, Aus or the US
also be prepared to put together an accessible version so as to not
contravine the various pieces of accessibility legislation floating about.
If youre in Australia - expect to be successfully sued if you dont :)

The above is also likely to become true for intranet applications also.

Basically server side transformations allow guarenteed successful delivery
of content to many *target* browsers and offer an easy upgrade path (Ive
successfully migrated a site between Xalan, MSXML and LibXSLT). The cost
of this is that a high traffic website will require additional
architechtural considerations (load balancing, possibly dedicated hardware
to offload transformations ). Any high trafic site should be considering
these issues anyway.

Jul 20 '05 #3

P: n/a
My recollection is that IE 5.5 (and IE 6.0) do not support client
side XSL transformations out of the box. You have to add MSXML3.0
(or MSXML 4.0) a download from Microsoft.

That might be a consideration. You might not have a choice.
Jul 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.