Most websites use some form of sitemap xml for rendering the navigation blocks. In Tridion implementations this sitemap is usually rendered from the folder structure created by the content editors. The established way of doing this is by creating a component template which calls the Tridion API repeatedly and traverses the folder tree. Unfortunately opening a lot of folders and components through the Tridion API is a time and resource consuming activity.
A traffic jam might occur in the Tridion publishing queue if you use the API for rendering the sitemap.
The method of traversing the tree will work fine if you have just one website in Tridion and not too many folders and components which need processing. Unfortunately most companies purchasing Tridion host more then one small website. Typical Tridion clients will manage the content of up to 50 websites in Tridion with thousands of components and folders per website. Most of these implementations suffer from a performance penalty in publishing content as a result of slow sitemap rendering.
In one implementation we needed to generate 13 sitemaps with a rendering time of 10-12 minutes each. With both a staging and live website (a typical tridion production setup) needing a new sitemap at least once an hour this meant the rendering of 26 sitemaps per hour. Needless to say that this would put a huge strain on rendering resources.
The solution to this problem is in NOT using the Tridion API for rendering the sitemap. In the case mentioned above I created a program which queried the filesystem of the presentation server. The program is capable of rendering the sitemap in well under 5 seconds. Which is roughly 100 times faster then the alternative. On the staging server the program runs every minute to give the content editors a near realtime experience. On the live server it is scheduled to run every 5 minutes.
The drawback of taking resources from the presentation server can be remedied by running the program on the lowest possible priority. When running in low priority the program will only use the idle time of the presentation server for rendering the sitemaps.
- Querying the Tridion broker DB. To do this you need to make sure that every component knows its parent. This option can be used for websites using a dynamic publishing strategy.
- Maintaining the sitemap via the Tridion event system (not recommended, I will go into detail on the event system some other time).
Blueprinting is the name Tridion uses for creating a hierarchy of publications. Every publication in the hierarchy contains a specific website building block (XML schemas,content, templates, layout, applications). Each child publication inherits the building blocks of its parent(s). The publications lowest in the hierarchy are the publications where content, layout and applications come together and form a website. The building blocks inherited from a parent publication are read-only unless you “localize” (i.e create a local copy) them.
Choosing the right blueprint for your organization is critical to the success of a Tridion implementation. If you fail to get the blueprint right then future changes to it will prove to be very hard and the usability of the system very low. Even the initial implementation of a simple, one language and one channel, website will be a daunting undertaking and will remain a challenge during the entire product life cycle. Continue reading
The proposed launch date for the Tridion Building Blocks Exchange website is set for december 2008 (join the SDL Tridion R5 group on linkedin). The goal of the website will be the exchange of the newly introduced compound templates. The compound templates are introduced in Tridion 5.3 and are .NET based. They are a big step forward from the old VB, Java and (my favorite) XSLT Component templates and page templates, because for the first time it will be possible to debug by using an actual debugger. Finally! 🙂
I hope they will also publish some kind of roadmap and get a discussion going on the future of the product. In any case I hope to meet you there and share a few ideas and perhaps, who knows, even some templates.
SDL Tridion is about to launch the BBX community. This Building Blocks Exchange Web site gives experts the stage to share their great work such as reusable tools, Modular Templates, scripts and more. And of course to download and use for your own Web sites. The exchange Web site is scheduled for launch before Christmas.
A structure group is a container for pages and sub structure groups. It is similar to a folder in the file system. On the presentation server a Structure Group corresponds with an actual folder on the file system. It is possible to add metadata to eacht folder.
The difference between a folder and a structure group is that a folder contains components and a structure group contains pages. The fact that a file system folder in the structure of the website corresponds with a Tridion structure group, and not a Tridion folder, is somewhat confusing. Continue reading
A component link is a reference within the content, or meta data of a component (A), to another component(B). The link in component A is a reference based on the unique ID from component B.
On the presentation server this reference will be translated to the URL where the rendered content from component B can be found. If component B is not published you can choose two outcomes:
- The anchor text will be presented as normal text
- The anchor text is not shown.
Goal: To minimize effort in managing internal links. The advantage is that you will never have broken internal links on your website. Continue reading
Tridion folders are used to store components and subfolders and are similar to directories (or folders on windows) on a file system. A folder can also contain metadata which can be used to describe the content of the folder. Permissions for different users or user groups can be set per folder.
It is good practice to use the folder structure for generating the main navigation for the website. Using the folder structure for the navigation gives content editors a solid view of the navigation as opposed to other options. The drawback is that generating the navigation structure from within Tridion is slow. However there are remedies to this (todo: write about advanced navigation structure rendering)
Tridion publications contain the building blocks used in Tridion blue printing. A Tridion Publication contains ONE of the following website parts:
- Nothing. Also known as the “Empty Master” has no parents and can never be given a parent. Placed to ensure that in the future the publications below it can be given new parents.
- Data design in the form of (XML) Schemas
- Components (content) for one language (English, Spanish) and one domain (website.com) or channel.
- A physical website. Usually only inherits from design and content and, optionally, a publication may contain Tridion pages. This type of Publication only combines content and design elements from parent publications. Usually it does not contain any local design parts or content.
It is possible to do all of the above in one publication. However this limits the possibility of re-use and with that the advantages Tridion offers in terms of maintenance.
A Tridion page corresponds with a physical page (HTML/ASP/JSP/XML/CSS etc) on a website. The type and layout of the page are defined by the Page Template that is used on the page.
A page is also a container for Component Presentations. It is possible to add 0 or more Component Presentations (chunks of rendered content) on one page. The Page Template will determine how the Component Presentations are placed on the page. In addition it defines the HTML header tags and which navigation blocks are visible.
The end result will look something like this: