Performing XSL Translation on Client vs. Server

Discussion in 'XML' started by Michael, Apr 23, 2004.

  1. Michael

    Michael Guest

    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
     
    Michael, Apr 23, 2004
    #1
    1. Advertising

  2. Michael

    Andy Dingley Guest

    On 23 Apr 2004 15:52:17 -0700, (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
     
    Andy Dingley, Apr 24, 2004
    #2
    1. Advertising

  3. Michael

    Lee Jackson Guest

    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.
     
    Lee Jackson, Apr 24, 2004
    #3
  4. Michael

    GIMME Guest

    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.
     
    GIMME, Apr 26, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thuan Seah
    Replies:
    1
    Views:
    796
    Martin Boehm
    Sep 12, 2003
  2. Replies:
    1
    Views:
    3,622
    A. Bolmarcich
    May 27, 2005
  3. jjouett
    Replies:
    7
    Views:
    1,139
    Harrie
    Oct 2, 2005
  4. Nathan Sokalski

    Firefox not performing client-side validation

    Nathan Sokalski, Mar 24, 2010, in forum: ASP .Net
    Replies:
    12
    Views:
    1,434
    Scream For Me
    Jun 7, 2010
  5. Nathan Sokalski

    Firefox not performing client-side validation

    Nathan Sokalski, Mar 24, 2010, in forum: ASP .Net Web Controls
    Replies:
    12
    Views:
    957
    Scream For Me
    Jun 7, 2010
Loading...

Share This Page