I have been molding a serve-side framework based predominantly on XSL
1.0 on the browser and have developed some tooling around maintaining
that.
My partner, who is saddled with the bulk of the application
development, having no particular knowledge of XSL outside of a little
xpath, has built a fairly significant application suite, tested across
all leading browsers, down to using javascript to do transform
document fragments in response to ajax responses. . We do leverage
device identification and will apply the XSL on the server-side if
necessary. This lets us support a wide range of devices without
having to modify our applications.
I invite you to visit the Blizzard web site (the home of Worlds of
Warcraft) and look at their extremely rich constructs which are almost
exclusively done via XSL in the browser.
I assert that XSL 1.0 in the browser is not only doable, it has been
done and with success.
- michael dykman
On Sun, Jan 3, 2010 at 11:24 AM, Andrew Welch
<andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com> wrote:
2010/1/2 Rob Belics <rob_belics(_at_)charter(_dot_)net>:
On Sat, 2010-01-02 at 20:06 +0100, Aad Kamsteeg wrote:
Rob,
I've done my company's webside full client side xslt (about 4 years
ago, still functioning). Worked rather well. You can check
www.diderottrack.nl
. As I recall there is a page on "this website" with references to
stylesheets, xslt and css. Possibly some functions (displaying hidden
text) are a bit off, but that's a javascript issue, nothing to do
with xslt.
The build-in language switch relies solely on xslt.
View source to see the xml used.
Key is design, you have to know exactly what display / filtering /
functions you need at what time pr position. But that's not really
specific for using client side xslt, it's key for websites.
Met vriendelijk groet,
Aad Kamsteeg
Thank you and Alain for your links. Perhaps the only thing I have to
fear is fear itself (I just made that up) and quit reading the
complainers and start coding.
I think client side XSLT was dreamt up the same time as XLink and
XPointer... and it's going to follow those into history as
probably-made-sense-at-the-time but in practice and with hindsight we
can see their failings now. (search xsl.markmail.org for many posts)
If you really do want to go down that route, start coding now, then
towards the end of the project you might be one of "the complainers"
too :)
--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/
--~------------------------------------------------------------------
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>
--~--
--
- michael dykman
- mdykman(_at_)gmail(_dot_)com
May the Source be with you.
--~------------------------------------------------------------------
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>
--~--