Hi,
I can only recommend an XSLTv2 server-based solution, for XSLT2,
standards, centralization of processing and know-how, architecture
manageability, public information control. This does not prevent
client-side xslt and/or Javascript but at least it limits and
concentrates browser dependencies.
On the other hand a good server-based solution may typically require an
adequate infrastructure and design (e.g. transform pipelines). The
whole thing can still be a serious piece of work. Well worth the
trouble for us, even when not generating income.
Cheers,
ac
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.
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--