> Thanks for your reply Leon.
>
> First let me say that I am a novice at XSLT and am really looking at my
> technical options..., so I'm not quite 'in-the-know' as to why I've
> qualified for the double frown. Any explanation [or pointers to a good
> article] would help me very much.
People generally don't like the XSLT syntax. I don't see anything wrong
with the idea as such. It is just a bit cryptic.
> I wanted to take a step back and enlist your help...
>
> My primary requirement is to provide multi-language versions of articles.
I
> am trying to find the best way to serve this out, I intend [although still
> evaluating but is good as sold] to use Turbine.
Cool!
> My idea with XSLT was to store the different language versions of the
> articles in XML. This seems attractive since I can change format very
easily
> using XSL style sheets. Creating the XML document would also be easy to
do.
> I'm am concerned that I'm having to put in a transformation step and am
very
> unsure how this will impact the performance [I see from the original
message
> below that there is caching but I don't currently have a feel for the
> speed].
We use an on most sites we have developed we do an XSL transformation on
every page. It makes the development very easy, but I must admit that you
do get a significant performance hit. If your site is not too high volume
you're ok. Depending on the complexity of the stylesheet you get between
50ms and 500ms (If you use a compiled stylesheet) slower access than for a
normal screen. Compiling a stylesheet can take anywhere from 1 to 10
seconds. Xalan takes longer on it's first compile and thereafter it
compiles quicker.
We have some plans to speed this up. If someday browsers have descent
support for XSL we can offload the transformation to the client. This will
be the ideal situation. Both Mozilla and Explorer already have some form of
transformation, but it is very basic at the moment.
We're also looking at Sun's XSLTC. This is pretty cool for it compiles your
stylesheet to Java bytecode. It is significantly faster than Xalan, but it
is not fully featured and it will require some work to add it to the XSLT
service.
> My second option was to store the articles in a database and implement my
> own caching [or use Turbine, at least I think there is a caching service].
> But I'm still left with the step of having to mark up the document! Maybe
my
> thinking was to store XML in my database [MySQL] and then still transform
> using XSLT. I really do not want to dissect my article up and map it
somehow
> to a database table[s]!
Just a thought. Why don't you do as you have planned with XML articles and
an XSL transformation and cache the transformed document. This way you only
need to do a transform when the document changes and the rest of the time
you'll have the performance of a static page. You can regularly check the
timestamp of the document to see if it requires a new transformation.
This could be somewhat problematic if you expect to have thousands or
millions of documents.
> My last option was to provide my different articles in their final marked
up
> versions [since the content is static], e.g. JSPs. I would then use the
> correct JSP version at runtime. This is obviously the most rigid option
> [since I am tying myself to JSPs] and would not help my second
requirement!
Take a good look at Velocity before you take the JSP route.
> My (very) secondary requirement is to maybe use XSLT for marking up
content
> for different client types [e.g. PDAs, WAP, etc.] - this is very much low
> priority and would be very limited, so this is a nice to have but can be
> dropped.
I feel that is just one more good reason to stay with XML.
~ Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
