I created a small evaluation in order to make a substantiated choice between publishing XML or HTML from Tridion. I already assume that you made the choice between static and dynamic publishing Perhaps it will be of interest to someone:
| XML | HTML | |
|---|---|---|
| Separating content and presentation / Re-usability of data. Since the web application completely determines how or which parts of the XML content is presented, the same content can easily be displayed in different ways. |
+ | – |
| Tridion publishing Performance. When publishing XML content, Tridion only needs to render one Component Presentation which will take less time then rendering multiple Component Presentations. |
+ | – |
| Maintenance and extension of Component Templates. Your templates in Tridion will be simpler and thus easier to maintain. The complexity is transferred to the web application which is much easier to main then Tridion templates (try debugging or refactoring your code in Tridion). |
+ | – |
| Minimizing CMS development dependencies Changes in the HTML templates will not result into changes of the CMS template code. |
+ | – |
| Presentation performance. Rendering the XML into HTML on the presentation server will use more resources then displaying plain HTML. |
– | + |
| Complexity of the web application The web application will be partially responsible for rendering the content. |
– | + |
| Grand total | + | – |
Nice summary.
Thanks Julian.
We found out the hard way that there are more benefits to publishing to XML and processing it on the webserver:
– testability: unittesting in tridion is not impossible, but difficult to do. Having a ‘normal’ web application opens up the possibilities to decent unittesting and achieving a higher quality and better quality-assurance in the long run.
– maintainability: (in addition to the 3rd item in the table above) no need to mix up development languages anymore!
– speed and ease of development: development can be done in proper IDE with code completion, syntax highlighting, etc; and no need to copy-paste into slow-slow-slow tridion GUI
– debugging: yes, proper debugging becomes possible! No more relying on cryptic error messages and no more need to spend an hour first trying to find out which PT, TBB or CT causes the problem
Hi Jeroen,
Good points thanks for sharing them. On the speed and ease of development I would like to note that the .NET templating allows you to use Visual Studio to write templating code. My colleagues are just wrapping up our first Tridion project using .NET templating. I will ask them to share their experiences in using this.
Thanks for this nice summary of the pros/cons of publishing XML vs HTML. We’ve been kicking around the idea of just publishing XML and letting a web application do the rendering and this helps to reinforce those ideas.
Jeroen mentioned that unit testing in Tridion is not impossible, but hard to do. I have not thought of a decent way to do unit testing in Tridion, but it sounds like there is a way — I would love to know what that is (at least for now until we can move to the XML approach).
Also, Albert, have you had any feedback from your colleagues on the .NET templating pros/cons?
Hi Eric,
I can highly recommend the xml publishing strategy. We have used it for the new portal of a big cable giant in the Netherlands. It proved to be a big success. In this particular project we took the idea one step further and delivered a Webservice only which feeds content to a certain portal product.
In addition I am rebuilding kvk.nl using the xml publishing strategy. For this implementation I am reusing an almost finished implementation for an internal website. In my experience it is much easier to implement a .NET template then it is to implement a Tridion template.
My colleagues Chris and Jeroen are the .NET experts who created both solutions. I will ask them (again) to write a post about their experiences. It would almost certainly help if you could post your question on their blogs too 😉
Excellent chart!
We have 4 development teams and started Tridion development by training a dev per team and getting the others on board.
And while we do use XML-published files (for content, config files, etc), it’s disconcerting to find “non-Tridion-trained” devs editing some of these files directly! Ugh.
The other challenges are getting the teams to recognize the XML files need to be excluded from site (presentation server) publishing. And for sites that are adding CMS slowly, recognizing which files come from Tridion.
Thanks Alvin! Your problems sound familiar.
We’ve found additional XML-as-data benefits. We use some component presentations (CP) as XML stored in the broker database, but mainly it’s to hold content in files the .NET Web site use.
1) .NET 3.5 sites can use LINQ for friendlier navigation of XML files
2) XML is CMS vendor-independent. We like Tridion, but if we ever change vendors, the content is available. Additionally, XML files don’t rely on the Tridion broker.
3) For teams that like XSLT, it could be used either on the Tridion or .NET side.
We even have a news page where the original solution was XML-driven and used XSLT to create the html markup. We just swapped out the existing XML from Tridion. Because the component template is also XSLT, it’s: Component to CP (via XSLT) to XML page to HTML (via XSLT). Not the best way to make it from scratch, but the change was nearly seamless.
We have run into a challenge, though, on how to handle XML files that contain a large set of content through a component that links to other components (index). When an item is updated, the entire set of content is published.
We’re looking at a few options:
* single xml config file (current)
* dynamic broker calls
* individual .xml files (or maybe pages)
* .NET .ascx dynamic component presentations