On Tue, 29 May 2007 03:23:10 -0600, Andrew Welch
<andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com> wrote:
The sooner you move your transforms server side, the better imho.
Ugg! There is oh so very much the browser can do with client-side XSLT
that takes so much load off of the server. Why would you want to enforce
a "rule" that suggests that this work should be done on the server when
the load can be balanced accross both surfaces quite easily? 'Tis why the
document function is so critical. With it, you can use the power of the
URI to perform REST-based service requests to the server which would, for
example, perform a query+tranformation to then return only the data that
is then transformed via cached XML/XSLT files on the client. If all you
are doing is returning just the data portion of a given page, your
efficiency leaps through the ceiling, and by using client side XSLT to
transform the data you also gain the benefit of not have to use Javascript
to process the data, so the speed at which the page is being rendered on
the client is lightning fast in comparison.
I agree that trying to force client-side XSLT to do more than it is really
capable of is the wrong decision. Of course, that's true about Javascript
as well. One of the things that client-side XSLT does *REALLY* well is
make it super easy and efficient to determine what browser is doing the
transformation, to then use that information to select CSS and Javascript
files that are tuned to the needs of that browser, instead of forcing upon
that same browser the task of parsing trough try/catch or if/else if/else
conditionals to first determine what the browser understands, to then
create a DOM object, to then process the content, to then pass that DOM
object back to the browsers rendering engine for display.
Conplete waste of resources, for no additional benefit if you enforce a
server-side transformations-only policy.
--
/M:D
M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 |
http://dev.aol.com/blog/3155
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--