Yet Another Tridion Blog

In previous post Custom Binary Publisher , I presented the main logic needed to publish our Multimedia Components using custom code in DD4T .net. In this post, I present the Template Building Blocks (TBB) that call the custom binary publisher. If you take a closer look at the code, you will notice it is basically the same code as the existing TBBs PublishBinariesComponent and PublishBinariesPage . I just created a separate PublishBinariesHelper class that uses the CustomBinaryPublisher described earlier. Calling methods PublishMultimediaComponent and PublishBinariesInRichTextField will call the overridden method PublishItem . public class PublishBinariesHelper { private readonly CustomBinaryPublisher binaryPublisher; public PublishBinariesHelper (Package package, Engine engine) { binaryPublisher = new CustomBinaryPublisher(package, engine); } public void PublishAllBinaries (Component component) { if (component.ComponentType =

The default way to publish binaries in DD4T is implemented in class DD4T.Templates.Base.Utils.BinaryPublisher and uses method RenderedItem.AddBinary(Component) . This produces binaries that have their TCM URI as suffix in their filename. In my recent project, we had a requirement that binary file names should be clean (without the TCM URI suffix). Therefore, it was time to modify the way DD4T was publishing binaries. The method in charge with publishing binaries is called PublishItem and is defined in class BinaryPublisher . I therefore extended the BinaryPublisher and overrode method PublishItem. public class CustomBinaryPublisher : BinaryPublisher { private Template currentTemplate; private TcmUri structureGroupUri; In its simplest form, method PublishItem just takes the item and passes it to the AddBinary. In order to accomplish the requirement, we must specify a filename while publishing. This is the file name part of the binary path of Component.BinaryConten

In the previous post Simple Publication Resolver , I presented a simplistic way of putting generic pages into Publication context by identifying the Publication URL by just applying a regular expression to the URL path. In this post, I present a proper Publication Resolver algorithm, for DD4T.net, that dynamically maps Publication IDs to Publication URLs and vice versa. The interface of a Publication Resolver defines 2 methods: GetPublicationUrl and GetPublicationId , which provide retrieval functionality for mapped Publication ID and URL. public interface IPublicationResolver { string GetPublicationUrl ( int publicationId); int GetPublicationId ( string publicationUrl); } The implementing class, PublicationResolver , defines an algorithm that dynamically discovers the mapped ID for a given Publication URL and the other way around. It makes use of the Tridion Content Delivery API PublicationMetaFactory to retrieve the PublicationMeta object containing informat

In previous posts I referred to a utility method GetPublicationUrl . This method simply looks up the current request path and returns the first two levels under the root. In my current implementation it is these two levels that identify the Publication. For example, for URL path /zh/cn/products/abc.html , method GetPublicationUrl returns " /zh/ch/ ". In different implementations, it could be that only the first level of the URL path represents the Publication URL, but that is a matter of choice and URL design. The code below show casts the simple GetPublicationUrl method, which applies a regular expression pattern to the given (current) URL path. The regular expression pattern matches only if the path starts with slash and is followed by two characters, followed by slash, followed by two characters, followed by slash. In this case, it extracts the 2 level nested folders and returns them. public static class UriHelper { private static readonly Regex Publica