"Michael Kay" wrote:
Well, a lot depends on your detailed requirements and on where you are
starting from (in both technology and skills), but my preferred target
architecture would probably be: use XSLT server-side to generate
HTML, CSS to render the HTML, and XForms to handle the user
interaction. Using XSLT client-side is viable, but I don't see many
benefits over using it server-side.
I agree with your preferred target architecture; that's what I do,
too. But I take it a step further. I have a basic weblog that uses
Atom for its native data format, everything is either a Feed or an
Entry. Each Atom representation also has an XHTML representation
generated by XSLT. So all the template-y goodness and static menu
links and such, are contained within the same XSLT transformation for
every page on the site.
But, the output of the transformation is mostly larger than the
combined size of the Atom input and the XSLT stylesheet. Add to this
the fact that the XSLT doesn't change, so it's cacheable on the client.
Pushing the XSLT transformation out to the client saves on CPU
utilization and bandwidth at the server -- as CPU and bandwidth are the
basis of my webhosting charges, I see this as a Good Thing.
When following a link to another page on the site, only the Atom for
the new page needs to be transferred over the wire. The client has
already cached the XSLT document (preferably *after* compiling it),
the Atom content is pulled through it, and the result is rendered in
the browser in less time than it would take to transfer the full XHTML
document from the server. The benefit is increased user-perceived
This is particularly true in the case of using Xforms. I love Xforms,
but there's no denying that the resulting code is heavyweight. If I
want an interface which allows me to moderate comments, I have an awful
lot of repetitive code on a long comment thread. For the case of a
weblog with busy comment threads and an Xforms interface, client-side
XSLT can save up to 80% on CPU and bandwidth, while doubling user-
perceived speed (granted, this last score would be better if not
for the poor state of XSLT web-browser implementations).
(Unfortunately, I've not been able to make client-side XSLT generation
of Xforms work in the real world. Generating the document is easy
enough, but the result isn't connected to the model for some reason.
Hopefully, this situation will improve over time.)
I am writing another response to this thread, explaining HTTP Content
Negotiation's use for this task, and addressing the issue of code
maintenance by explaining that the client-side and server-side XSLT
code can be exactly the same.
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>