Is XSLT worth investing time in and are there any actual alternatives?_问答_开发者

I realize there have been a few other questions on this topic, and the general concensus is to use your language of choice to manipulate the XML. However, this solution does not quite fit my circumstances.

Firstly, the scope of the project: We want to develop platform independent e-learning, currently, its a bunch of HTML pages but as they grow and develop they become hard to maintain. We already have about 30 modules, with 10-30 HTML pages each, and this is growing all the time.

The idea: Have an XML file(s) + Schema pre eLearning Module, then produce some XSLT files that process the XML into the eLearning modiles. XML to HTML via XSLT.

Why: We would like the flexibilty to be able to easily reformat the content I realize CSS is a viable alternative here, especially to visually alter the look'n'feel but we may need a little more power than this and go as far as restructuring the pages. If we decide to alter the pages layout or functionality in anyway, im guessing altering the "shared" XSLT files would be easier than updati开发者_运维知识库ng the HTML files.

Depending on some "parameters" we could output drastically different page layouts/structures, above and beyond what CSS can do. Can XSLT take QueryString parameters? Not sure..

Now, all this has to be platform independent, and to be able to run "offline" i.e. without a server powering the HTML so server side technologies are out of the question (C#, PHP)

Negatives I've read so far for XSLT:

Overhead? Not exactly sure why...is it the compute power need to convert to HTML?
Difficult to learn
Better alternatives

Now, what I would like to know exactly is:

Are there actually any viable alternatives for this "offline"?
Am I going about it in the correct manner
Do you guys have any advice or alternatives.

EDIT: With or without XSL, CSS and JQuery will be a very prominent part of the solution we develop. General tidy up (sloppy engrish!)

Using an XSLT scheme for this is legitimate. XSLT's are powerful if you develop the expertise.

Overhead: Yes, for large documents, a transform can take some seconds. Do a transformation on a large document called many times a minute can be a bad strategy. That won't be a big problem for you since you won't be doing these transforms on demand, just when you want to revise.
Difficult to learn. You can be productive with XSLT pretty soon, but beware: just when it seems XSLT's are getting easy, you'll be surprised by it getting tricky all of a sudden! What you think would be difficult can be easy, and vice versa. You'll might have to import or create some templates just to do some simple date formatting, for example. It's all doable though. Don't be afraid to learn how to do "templates".
Better alternatives. Yes, there are better alternatives, but they are platform specific. For example, I'm in .NET land, and I've dropped XSLTs in favor of manipulating our new XElements and such, and VB.NET embedded XML is very powerful and easy. But XSLT is still great when you want to avoid becoming dependent on a particular platform.

You're still going to use CSS as part of your strategy, right? Changing an XSLT to output styling consistently is better than doing it in 30 modules by hand, but a well-planned CSS stylesheet can still help simplify things (increase maintainability and flexibility).

In summary: To organized the layout/revision of static html pages, platform independent, for flexible distribution: yes, you have a good stategy, from what I can see. And expertise you develop in XSLT will be useful in the future, too. And after mastering XSLT, you'll really understand XML, which will be helpful forever.

XSLT is an ideal tool to use for generating HTML from XML documents in the circumstances you've described. The common complaint about XSLT's processing overhead - that it requires the entire source XML document to be loaded into memory - is really not relevant if you're using XSLT to generate static HTML pages, unless maybe you're generating hundreds of thousands of them.

(And in fact that complaint is really only relevant in cases where the source XML document is large. If you've built an architecture around dynamically generating HTML from large XML documents, choosing XSLT as your technology may be a mistake, but it is not the big mistake.)

You should of course also use CSS.

Separate your data from your presentation.

Offload presentation rendering to the browsers, use CSS and CSS "enhancers" like SASS, Less, etc.

Generate strict XHTML - can format with CSS, can parse with XML parsers, etc

Use JQuery like for interactivity

XSLT is quite heavyweight and won't scale well, whereas XHTML+XSS+JQuery is very well understood and lots of tools exist.

If you already know C# or VB.NET consider using LINQ to XML, the code will be longer, but it may be less pain to write and maintain for a none XSLT expert.

It all come down to how many XML transforms you will needed, just 1 or 2 then I would not spend the time learning XSLT.