Tag Info

Hot answers tagged

20

There are some important cases where XSLT can be a good choice: ETL software can use in some cases XSLT. For example, it can be a good choice when both extracted data and data to load are in an XML format, and where transform may be changed without the need to recompile the application. Some applications which store data in XML use XSLT to present this ...


18

I HAVE successfully used XSLT as a web presentation tier... in 1999. In the last 12 years, much better options have come along. Do yourself a big favor, and use Razor. It's a pleasure.


17

Here is a basic syntax comparison Razor @foreach(var item in View.List) { <span>@item.Name</span><br/> } XSLT <xsl:template match="/"> <xsl:apply-templates/> </xsl:template> <xsl:template match="item"> <xsl:for-each select="name"> <xsl:value-of ...


13

It's difficult to assess technologies when you don't have deep experience of them, but of course that's exactly when you have to make your decisions, so there's no simple answer to that dilemma. You cite two concerns: performance and usability. I'll try to address both below. Firstly, performance. Performance of course depends not only on the language but ...


10

XML : XSLT :: JSON : x. What is x ? The most facile answer would be x = JavaScript. Though you could make a case for this, it feels unsatisfying. Even though XSLT is technically Turing complete, there is a poor correspondence between the declarative style of XSLT and the more imperative or functional styles seen in JavaScript. There are a few standalone ...


8

XSLT is pretty much dead because only a few enthusiasts still use it. However, there is no real alternative for it. If you focus only on a single use case, such as for example rendering of HTML pages from semantic documents, you find better tools. If you look for code generation template engines, again there is better tools. The same for document ...


7

I think you are really asking a broader question, "is having a strict definition of a file format a good thing for a rapidly evolving project". To answer your immediate question, though: yes, they are. The XML schema gives you a strict definition of the format, answer a lot of questions about validity, provides great documentation, and allows you to ...


7

Hmm I wonder if the high-level APIs that create HTML from code use any XSLT "under the hood"... XSLT is used extensively where I work to transform XML from one source format to a variety of others. It can also be used to transform XML to non-XML output. I haven't done much of this but I've heard of it being done to target PDF and PostScript, among others.


6

Yes. Let's take a good example: unit test reports in continuous integration. Most unit testing and code coverage programs simply output tons of unreadable XML. But with a few simple XSLTs, you can create a dozen useful reports from the same data. And other people can reuse those reports. Now you could write these in whatever language the CI tool uses for ...


6

If you really want something that works well for you, then I suggest you get used to the idea of "unnecessarily complex"... that's the nature of dealing with Microsoft Office file formats. I (sort of) like your idea of "blocks"... I would make sub-classed block objects, like Table, with Columns and Rows independent of the notion of cells. Then use your ...


5

using XSLT to transform messages is a very common technique that you'll find supported in most ESB frameworks such as Apache Camel, Mule, Spring Integration, Ikasan etc. The trade off is that XSLT can be difficult to maintain and there can be a lack of flexibility in the programming model that it offers. I've found that I'd often have to call out to a ...


5

There will always be choice and variety in programming languages, and the reasons why one gets chosen in preference to another are as much to do with familiarity and fashion as with objective criteria like functionality, productivity, and performance. No one can predict fashion, so no one can predict future trends in programming languages. But there are ...


5

We use XSLT templates to transform XML into HTML for reports all the time. It works well, but like anything else you can take it too far. Keep it simple or you end up with some pretty out of hand XSLT that nobody can understand.


5

Transforming XML into HTML is fairly standard practice. So yes it’s a good idea but no you’re not a genius. :)


4

<tl-dr> Is there a 1:1 relation between HTML pages and XML output? Consider following cases: Strong correlation: each web page has an HTML and a corresponding XML form. Example: you're hosting a website with movies reviews. You have a home page with latest reviews, one page per review and a page with guests comments and ratings. There is no ...


3

Without additional information about the context, it's difficult to answer. Still, I don't understand why you don't want to use XSLT. It's the right tool for the job, and a powerful one. It is done specifically to transform one XML into another. XSLT processors seem to be quite huge / resource hungry Do you have hard data to support that? Have you ...


3

XSLT can get really complicated really fast Having spent a lot of time enduring the pain of poorly applied XSLT solutions I'd strongly counsel against them, unless your mapping transformations are brain-dead simple. I would much rather try to work through a load of fairly simple, repetitive POJOs trying to find a transformation bug than fiddle endlessly ...


3

You don't have to choose, you can use both. In ASP.NET MVC you can use multiple view engines at the same time. In the project I'm currently working on I'm using XSLT for readonly views and Razor for forms. You can also use XSLT with Razor layout or Razor with XSLT layout. I'm using XSLT layout, so I simply use a Razor layout that calls the XSLT layout and ...


3

In this case, I would suggest that you don't really have a controller per se. The XML is the model and the XSL (by way of producing an HTML output) is a view on that data. If you had some mechanism which took some user input and filtered (or caused to be filtered) the raw XML prior to the XSL transformation, then you might consider that mechanism to be your ...


3

Indeed Something will probably supersede XSLT one day since it's a bit cumbersome to learn and use. However, there's currently no template/transformation language available afaik that is as flexible and "pure" in it's implementation. XSL-T can be used for a few different purposes: You can "create" content in say HTML format from a data using a template ...


3

XSLT is not human-readable. The meta-information (the tags) take too much place over the real information (text, xpath requests). A good code should look like a documentation and this is fairly not the case of XSLT. It is rather a good persistence format for mapping tools. A good transformation language should allow to preview the transformation result and ...


2

I work for a Data Integration company and we use XSLT with our proprietary tools as a great solution involving XML to HTML/XML/Ascii.


2

My recommendation is Razor and the main reason is that it's much more easier to work with (than XSLT, and opposite to your enumerated argument in favor of XSLT, though, you're on my side). I have experience of working with both and Razor becomes exceptionally powerful in conditional statements, declarative helpers (functions in principal), branching, ...


2

XSLT's biggest failing is it inability (in any real implementation) to minimize the amount of the document that needs to be kept in memory at a time for efficient processing. Instead the whole document is read into some form of DOM representation and processing is done against that. If the document is very large, then so are the memory requirements. Yet ...


2

You could store whatever data you planned to store in XML in your database, in tables solely for that purpose. This is no more redundant than database+XML. It also allows you the option of having some of your data exactly as it was at the time and some up to date, if you ever decide to do so. It also means generating from transactional data is more ...


2

In your case, XSLT is acting as just another template engine. So, is it a good idea to use a template engine in your case? Completely! You already highlighted several advantages in your question: being able to modify the content without having to deal with HTML and vice versa, or being able to use the same content both for e-mails and on the website (even ...


2

It's a good idea to have an intermediate XML format, but using XSLT to generate HTML files is so 1999.. it might be a better option to use a templating engine such as Velocity, Spark View Engine, Razor, StringTemplate etc depending on what technology you're using. I'm sure you'll find them much easier to work with than the monstrous beast that is XSLT...


2

Having an intermediate XML format will serve you right. Firstly, because with XSLT you will be able to cleanly recreate an HTML email, and secondly, because you will have your clean XML content ready if any other application needs it. Also, XSLT is just great for that job. Just one remark about your "microsite". Remember that just about every email ...


2

Almost, but not quite. If you had a hypothetical webserver that could pass URL query strings as XSL paramaters I'd say you were quite close, that would allow you to respond to user input. eg. http://www.example.com/path/file.xml?param1=foo;param2=bar And your xsl contained: <xsl:param name="param1"/><xsl:param name="param2"/> But even then, ...



Only top voted, non community-wiki answers of a minimum length are eligible