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 …
I think it depends on situation…We can prefer a combination of static and dynamic content as per requirement.
Excellent and clear introduction to the main Tridion publishing methods.
I’ve seen heated-debates on which method is “best,” but I agree with Huston that it can depend on situation.
For example navigation and other (XML) config or look-up files could be done via “static” publishing, with a smaller impact for full site template re-publishing.
And though static templates create static physical files, they have dynamic aspects to them. For example, they can include code to dynamically render component links that “smartly” find to published content (remove link but show text if content isn’t published, find content with a different template preferably on a different page, etc).
On the dynamic publishing side, templates need to be linked to specific schema or content definition. If a site has a few schema with many dynamic templates, a component presentation is created for each template per component in the (broker) database, regardless if any of the other component presentations are used.
We’ve found a balance between using dynamic templates for “application-like” content. Newsletters, articles, biographies, job postings, and similar content may fall under this category and are often well-structured, non-generic, and/or a querystring-driven collection of content.
We’ve used static templates for, well “static” content pages that have generic html paragraphs, images, and links.
The 2,500-page example, though, has me thinking about the long-term affects of the static template method.
On the other hand, Tridion-published static template pages and XML config files feel less effects from broker database issues. The broker can go down and the pages still “live” on the server. And on the .NET side, the “dynamic” ascx component presentations are physically published to the file system. Rather cool, but adding another layer of complexity with PROS/CONS to both sides of the issue.
Thanks for sharing your views Alvin.
I agree that some files like .js and .css can/should be published using static publishing. For the navigation xml I prefer the method of generating it from the DB. This type of sitemap is 100% up to date at any given moment and does not take precious resources from the Tridion rendering process.
The argument that static files will be available even when the Broker DB is offline is only partly true. Tridion linking also uses the broker DB and will not function without it.
Another point to be considered is the fact that file stores can get out of sync. Which is a common problem with websites that are served from multiple webservers. A NAS might solve this problem, but is a single point of failure just like the broker DB.
I just finished a project where we replaced the existing static webpages (containing over 8000 articles with generic html paragraphs, images, and links) with dynamic pages. This halved pageload times, among other benefits. I promise to blog about the results shortly.
We’re seeing that exact issue with static page publishing. We testing dynamic linking, and yes, it does NOT work yet on our preview server.
We also recently released a deployment using static publishing with an xml config file that has content and links to binaries. Worse than having our web farms out-of-sync was getting STG files copied (.NET deployment, not Tridion publish) to production. Nothing like seeing STG or DEV content manager ids (tcmid) on production!
Great blog and best wishes for 2010!
I work on a Tridion project where we have to integrate/migrate an existing J2EE application with menus and business processes into Tridion. I have difficulty selecting between the “Dynamic website options” in the Tridion whitepaper. It seems to me that the “Application model” is the option that lets us reuse as much of the existing code as possible. In this case we could move the top menu into Tridion and let the application control the left menu, which is application specific. Do you have any opinions in regard to the “Application model” when porting a financial webapp into a Tridion environment? I also suppose that the app will run in an IFrame or so. Alternatively we could recode the webapp using a framework like CWA but i guess this is a very big task.
Regards,
Ole
If you want to reuse the existing code then the application model is the best/only option. Publish all the content and its structure to the broker DB and adapt your application to retrieve and present the content and structure from the broker.
Thanks for an interesting article. After looking through different websites I finally found something worth reading.
Pingback: SDL Tridion dynamic website performance | Albert te Boekhorst