While doing some preparation for a hackathon on client-side templating (ie javascript in the browser) on our upcoming SDL Tridion MVP retreat, I created a simple component JSON serializer TBB. This basically takes the TOM.NET Component object and converts it into a JSON format which is friendly for Javascript templating frameworks like Knockout.
Recently a client requested that we give them the capability of controlling a pages inner content by allowing them to paste markup into a text field (or possibly a RTF), with the following requirements:
An interesting question has been asked on Tridion Stack Exchange regarding whether there are any frameworks or methodologies for using Test Driven Development with the Tridion Event System. Having done test driven development in my early days as a Java and PLSQL developer and having had developed enough functionality with the Tridion Event Systen, I thought I’d provide my two-cents. Continue reading
In my previous article about ECL, I’ve discussed the possibilities of using product information in your CMS. This sort of a setup cries out for Dynamic Component Presentations and Broker queries, which isn’t a problem, unless you want to query the ECL Metadata in the Broker.
I recently set up a new SDL Tridion publishing environment where a single Content Deployer was used to publish a number of different publications to different broker databases, but to the same location within a web hosting environment. Â In doing so I discovered something I wasn’t aware of and though it might be worth sharing with the community.
An SDL Tridion schema is the (.xsd) definition for content. Eventually you may need to re-order, add, or remove fields to accommodate changes to your content model. Changing a schema doesn’t instantly change content based on this schema (trust me, you probably wouldn’t want it to). To make such an update, authors can open and close items in the Content Manager Explorer which will synchronize components to their updated definitions.
This works for a few dozen items, but can quickly get monotonous for several hundred components. Per SDL Live Content (http://sdllivecontent.sdl.com/), SDL Content Porter 2009 and later have the ability to “Synchronize Components against Schema before importing.”
“If you import a Component or a content item that has metadata, without also importing the (Metadata) Schema on which the item depends, the item you import may not match the Schema on the target system. Selecting this option tells Content Porter to attempt to modify the import item to match the Schema found on the target system.”
There’s a very important note that “selecting this option could lead to data loss.”
This synchronization option covers field re-ordering, removing fields no longer in the target schema(s), and adding new fields as long as they’re optional and/or have a default value. Also important is realizing this is a synchronization action which makes some existing fields match an updated schema. It should be clear that things like renaming fields and requiring a field without a default would require more manual (or programmatic) work.
The option is selected by default on an import, all you have to do is update the target schema before doing the import. Again, be careful with this as schema changes can lead to data loss.
“Synchronize content against Schema before importing” is selected for you during imports
On a recent project, we had a couple of interesting requirements with regards to link management on the site, one of which was to rid the site of web page file extensions (no page or link should have a .html or other extension, and index pages should also have the index file name removed (so /news/index.html would be shown as /news/).
The site was driven by the Content Delivery OData web service, so the best place to implement this was using a custom tcdl:Link tag. This article I show you how you can easily do this
On most projects I have worked on, at some point we have needed some Tridion uris in the web application, be it to load keywords from a taxonomy, or executing broker queries for items based on a certain schema ID, and return dynamic component presentations using a given Template uri. This article shows you a simple TBB to publish these config values.
I have often come in on projects where a lot of the component templates are ‘dynamic’. Nothing wrong with that in itself, but when I have asked the question Why? the answers start to give me the feeling that the Dynamic Component Presentation (DCP) is a bit of a misunderstood animal.
In this post I don’t intend to teach you what a DCP is, or talk about any technical details of using them. Rather I explore the reasons that are often given for using DCPs, debunk some myths, and hopefully make you think a bit more carefully when making that decision to select the “Published as a Dynamic Component” option.
On a recent implementation, a large site fully driven by OData, we ran into a scenario where we wanted to retrieve DCPs based on multiple custom metadata values. We quickly realized that there are some limitations around this. For instance: a component with the following custom meta fields, color and shape, having values ‘blue’ and ‘round’ respectively cannot be retrieved in one OData call. This is because each CustomMetas Key/Value is exposed as a separate entry in the CustomMetas collection, and the OData protocol is limited – doesn’t allow querying across properties of multiple entries (not as an AND at least). However, if there is a will there is a way, and in the article I will show an approach to doing so.