Yet Another Tridion Blog

If you implemented the steps in the previous post Implementing Experience Manager in DD4T 2.0 .NET , then at this moment you can run your web application and XPM markup will appear in your HTML output. Also XPM functionality is working. However, if there are modifications on the Page or any Components on the Page that are not published, the "Update Preview" button will flash in the XPM GUI. Pressing this button will eventually end up in an error and the Update Preview button will keep flashing. This is due to the fact that we have not configured Session Preview yet. The following sections will guide you through installing and configuring Session Preview and database and services it uses. Experience Manager Database This database, aka Session Preview Database , has the same structure as a Tridion Content Data Store database, only that it is used as temporary storage for items that have been modified in XPM and previewed (i.e. rendered with templates), but not yet publi

This post describes an implementation of Experience Manager (XPM) for DD4T 2 .NET using the CIL (REST) providers in SDL Web 8. The implementation would be basically the same in a more standard architecture where the Tridion Content Delivery stack would be used. XPM Configuration Switch In you web application's web.config , add the following line inside the configuration / appSettings node: <add key= "DD4T.IsPreview" value= "true" /> Only if this switch is present and set to true, the XPM markup will be generated in your HTML sources. Models Ready for XPM In order for XPM utility methods provided by DD4T out of the box to work, the models must: implement interface  DD4T.Core.Contracts.ViewModels.IViewModel ; annotate their Tridion fields with attributes; The code below shows a simple model that is XPM ready: using DD4T.ContentModel ; using DD4T.Core.Contracts.ViewModels ; using DD4T.Mvc.ViewModels.Attributes ; using DD4T.

In the previous post, I described a way to intercept in .NET cache invalidate events generated in Java. This post presents the way to configure, use and write your own code that handles the Java generated invalidate events. The entire code presented here is available on this blog's GIT repository. Link here . Java Stuff Modify your cd_storage_conf.xml (located in your .net website /bin/conf folder), and reference class com.tridion.cache.DD4TDependencyTracker as the Feature inside node ObjectCache : <Configuration Version= "7.1" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "schemas/cd_storage_conf.xsd" > <Global> <ObjectCache Enabled= "true" > <Policy Type= "LRU" Class= "com.tridion.cache.LRUPolicy" > <Param Name= "MemSize" Value= "512mb" /> </Policy>

The problem this post solves is as follows: the Content Delivery API has a mechanism called Cache Decorator, which allows the implementor to define custom code that will be called when things are added/removed/flushed from the internal Tridion Broker Cache. This mechanism allows external actors to interact and synchronize with the Tridion Broker Cache. Namely, a DD4T cache should listen to Tridion Broker Cache messages in order to invalidate its own entries. In Java world, this is simply implemented by extending the CacheDecorator Tridion class. However, in a .NET environment, there is no easy way of intercepting Java method execution back in .NET. This is precisely what this post describes. In a .NET architecture, the Tridion Content Delivery API runs as a Java byte code embedded inside the .NET runtime inside IIS worker process. Communication between .NET and Java happens using a standard called JNI (Java Native Interfaces). Namely the .NET runtime calls Java code that is mapped