Prev: .js file removed from cache before expiry date
Next: Best jQuery Code Reviews?
From: Johannes Baagoe on 4 Jun 2010 22:29
Scott Sauyet :

> If that involves transforming XML data, then there is a strong
> argument for doing so server-side.

Why ? Are there any significant browsers who cannot understand a
`<?xml-stylesheet type="text/xsl"?>` instruction ? E.g., that fail
to render pages like http://baagoe.com/en/RandomMusings/javascript/ ?
(take a look at the source)

Also, many browsers provide a XSLTProcessor object you can invoke in
javascript to process, e.g., documents obtained by XMLHttpRequest. That
is very handy to interact with XML databases using, e.g., XQuery,
which is a *much* nicer language than SQL.

--
Johannes
From: Johannes Baagoe on 4 Jun 2010 22:53
Scott Sauyet :

> replacing the XML-parsing code from the client-side scripts in favor of
> a client-side XSLT use could well be more maintainable.

I have been doing it for years in intranets. One very interesting tool is
E4X, which makes XML manipulations in javascript *much* easier. It is an
ECMA standard, but alas, only Gecko-based browsers seem to understand it.

--
Johannes
From: Scott Sauyet on 5 Jun 2010 00:44
Johannes Baagoe wrote:
> Scott Sauyet :
>> If that involves transforming XML data, then there is a strong
>> argument for doing so server-side.
>
> Why ? Are there any significant browsers who cannot understand a
> `<?xml-stylesheet type="text/xsl"?>` instruction ? E.g., that fail
> to render pages likehttp://baagoe.com/en/RandomMusings/javascript/?
> (take a look at the source)
>
> Also, many browsers provide a XSLTProcessor object you can invoke in
> javascript to process, e.g., documents obtained by XMLHttpRequest. That
> is very handy to interact with XML databases using, e.g., XQuery,
> which is a *much* nicer language than SQL.

These are valid points, although I don't really know how universally
available an XSLTProcessor is. Are they available on commonly used
mobile phones, for instance?

But there are, IMHO, still several reasons for preferring to do this
on the server. First, although we can generally assume that client
resources are cheaper than server ones for our application, if this
processing can be done once and cached, then the overall processing
required is significantly reduced.

Second, in my experience, these transforms most often significantly
reduce the size of the data stream. Doing the transform on the server
can greatly reduce our bandwidth. Of course there are time when the
reverse is true, especially when it involved converting data-centric
XML to display-ready HTML, but in my environments, this is rarely the
case. YMMV.

--
Scott
From: Hans-Georg Michna on 5 Jun 2010 09:24
On Fri, 4 Jun 2010 07:48:48 -0700 (PDT), Kevin wrote:

>I learned about XSLT from Wikipedia and W3C. As I understanad XSLT, it
>transforms an XML file based upon XSLT's rules.
>
>Can't javascript access the XML, and make changes? What's the reason
>for using XSLT over writing up a javascript?

You've already got quite a bit of good advice. Let me just add
another 2 cents.

Assuming a modern browser that can do both Javascript and XSLT
and assuming that you want the work done on the client, there
are indeed many tasks that can be done either with XSLT or with
Javascript. A recent example for me was to add a table of
contents to an HTML document that has header tags.

Initially I had intended to do this with XSLT, which is
perfectly suited to the task. However, I ended up doing it in
Javascript, in this case for the simple reason that I wanted it
to work not only in static web pages, but also inside a Content
Management System where the central page content can be created
by end users.

With XSLT I would have had to modify the CMS. With Javascript I
could simply embed the code inside the user-provided part of any
page. You can see and use the end result here:
http://winhlp.com/node/682

What it boils down to is that Javascript is a lot more flexible.
It can, for example, do changes on the fly, while the page is
already loaded. XSLT on its own cannot do things like that.

Server-side scripting is another matter, but I don't like that
much, because I believe that as much as possible should be done
on the client.

Hans-Georg
First  |  Prev  | 
Pages: 1 2
Prev: .js file removed from cache before expiry date
Next: Best jQuery Code Reviews?