Tag Info

Hot answers tagged

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 ...


15

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 ...


12

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 ...


6

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.


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

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 ...


5

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 ...


4

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 ...


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 ...


4

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 ...


4

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

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

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

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 ...


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

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

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 ...


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

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, ...


2

XSLT is made for this type of processing. Even if it were slower, it would be ludicrous to try to rewrite it yourself. It would be like saying you don't like how slow regular expressions are, so you want to write a program to do the pattern matching yourself. The problem is not a technical but rather conceptual. Why are you having to feed 8000 products ...


1

There isn't a direct way that I'm aware of off the top of my head. But XSD to form was hawt back in 2001 when .NET was conceived so you can likely use tools like xsd.exe to generate a class from that. Then you should be able to use the EditorFor in ASP.NET to generate a form for that. Or any other form generator that takes classes as input.


1

At the very least, have you considered harnessing the third party API's methods to multiple to retrieve the data from the DB in multiple trips (i.e. one subset at a time)? You could send it to the indexing engine in smaller chunks (if possible) or at least build the returned XML data in memory until retrieval of all data completes. There'd be more round ...


1

Your analogy is flawed. First of all, if you have a completely static website (no dynamic content at all), then I would say that you only have a set of Views. There is no Model and the small Controller part you need is completely taken care of by the webserver. The task of the Controller is to update the Model based on the actions and input of the user and ...


1

I'm not an expert on BizTalk, but I made some unit tests for XSLT. I found several ways to do it. Creating some XML that represent the usual data. Developing a reverse tool (from XSLT output to significant XML data) and then testing XSLT over a big amount of XML (e.g. monthly invoicing, integration messaging, etc.). If you can obtain the significant part ...


1

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 ...


1

In matter of fact, i think is more efficient to use XSL then other language while presenting a data, as exemple you can present an xml as A PDF using xslFO and you can controle every inch, but if you work with RDLC (.NET ) for example ,you will see that is so difficult to present exactly what you want . Even the evolution/correction are so easy as in xsl ...


1

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 ...



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