Posted December 21st, 2009 by Gerbrand
Due to the fact that I don’t have a personal blog, I’ll (ab)use the one Albert has… Thank you Albert.
A short introduction; my name is Gerbrand Smit, I’m a colleague of Albert (also a consultant at Deloitte Consulting) and have been working with Tridion for more than six years now. In those past years I’ve done a great deal of Tridion implementations and have grown really fund of projects where Tridion is involved.
My latest project was with Tridion R5.3 SP1, allowing me to ‘play’ with the new SDL Tridion .NET Templating, I’m going to share some of my views on the subject in the next post.
Posted February 24th, 2009 by Albert
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 |
+ |
- |
Posted January 5th, 2009 by Albert
Tridion has two main methods for publishing information to websites:
- Publishing chunks of content to the Tridion broker
- Publishing whole pages to the file system.
Both publishing strategies have already been explained in previous posts. However the fundamental differences between both strategies deserves some additional attention.
Publishing chunks of content (dynamic)
In tridion chunks of content are called component presentations. For this publishing strategy the Tridion rendering tree is traversed until step 4. The result of the rendering is a chunk of XHTML/XML/plain text/ etc. which is subsequently published to the broker DB on the presentation server.
On the presentation server the broker DB will be queried by a website based on ASP, ASP .NET or Java which will use the pre rendered content to create a fully rendered page for the visitors.
Publishing whole pages (static)
In this publishing strategy the full Tridion rendering tree is executed. The result of which can be a file of any type, but usually has one of the following extensions: ASP, JSP, HTML, CSS, XML etc. To get the required results you will need to implement both Component Templates and Page Templates.
Which one to choose?
I recommend the dynamic approach. The static model is quickly becoming obsolete in an era of monthly website updates and personalization at the top of everybody’s wish list.
A good illustration of why the static model is useless is an update we recently made to the navigation and layout of a website based on the static model (and NO it was not created by me or one of my colleagues). When you make changes to the templating in the static model in Tridion you will need to re-render all of the pages which make use of these templates. In this particular case there were over 2500 pages in the top publication which was blueprinted over 10 times and each blueprint contained an average of 500 local pages.
I needed to explain to the client on several occasions that the go-live was a ‘process’ which would take the better part of 3 days and three nights. The re-rendering of 30K pages would take approximately 60 hours. During this period the website would slowly go from the old look and feel to the new.
Feel free to share your views on this subject in the comments …
Powered by FireStats