 XSL on the client
started 1/15/2001; 8:03:41 AM - last post 1/15/2001; 1:00:56 PM
|
|
Ehud Lamm - XSL on the client 
1/15/2001; 8:03:41 AM (reads: 296, responses: 5)
|
|
|
I was asked to give my views on a software design document. One of the issues was wether to send XML+XSL to the client, or to do the XSL transformation on the server. Based on my experiences, and discussions here in the past, I am inclined to prefer the server side approach. Comments?
|
|
Chris Rathman - Re: XSL on the client
1/15/2001; 8:20:54 AM (reads: 319, responses: 0)
|
|
|
In the long term, I think the client-side is the way to go. Problem is that the client side browsers are quite immature when it comes to XSL. Internet Explorer is the only browser that approaches support, and it has all sorts of quirks and bugs - making it fairly useless as a target.
You could try to use a plug-in, but that's not a very optimal solution. If you require plugins, you tend to limit your audience, and also take on the risks associated with that plugin. In an ideal web application, you never touch the client (thus assume no responsibility for client software).
|
|
andrew cooke - Re: XSL on the client
1/15/2001; 9:15:39 AM (reads: 313, responses: 0)
|
|
|
I know nothing about XSL, but (Re: plugin) I agree that the less that is required to install on the client, the better. Client-side code is horrible stuff - you have to worry not just about installing it, but also supporting it.
If this is a startup my suggestion is server-side for as much as possible until/if the product takes off, with a sketched-out plan for transferring load to clients if it's a success (when, in theory, they will have/be able to raise funding for the manpower to cope).
Sorry, not a technical reply - just from general experience. Personal post; all my own views.
|
|
Ehud Lamm - Re: XSL on the client
1/15/2001; 12:27:02 PM (reads: 286, responses: 0)
|
|
|
I agree with Chris that client side seems like a good goal; but currently a bit problematic (even though I can be assured MSIE will be used throughout, but what version?). Plugins are, I think, a Bad Thing in most cases, like you both say.
I am not sure client side is always a good idea anyhow. I most rederring is static why do it over and over again by clients (and suffer multiple HTTP requests for each page), when cached HTML can be stored on the server?
|
|
Chris Rathman - Re: XSL on the client
1/15/2001; 12:43:24 PM (reads: 313, responses: 0)
|
|
I most rederring is static why do it over and over again by clients (and suffer multiple HTTP requests for each page), when cached HTML can be stored on the server? It really depends on the nature of the XML documents and the cacheing scheme. If the XML document is fairly static, then yes you could cache the translated document to improve performance. However, if the data within the document is fairly dynamic, the cache is gonna result in a miss more often than not.
In most of the applications I do, we're looking at polling the database to construct the XML documents. This means that the data is constantly being queried with different resultsets.
|
|
Ehud Lamm - Re: XSL on the client
1/15/2001; 1:00:56 PM (reads: 322, responses: 0)
|
|
|
I was actually asked about building forms for updating a database. The HTML should simply be based on the structure of the update request (represented by XML, but fairly static) and include simple validity check (numerics, dates) which are also not going to change frequently. That's why I favored the caching approach.
|
|
|
|