Yet Another Tridion Blog

This post describes the architecture for Tridion's Experience Manager (XPM) when used with an MVC framework such as DD4T in a Service-Oriented Architecture. This architecture implies that the website is completely independent of Tridion Content Delivery APIs. The only place where the CD APIs are used is on the Provider's Services Layer, as described in the following diagram. I am going to focus on this diagram to explain the basics of XPM and Session Preview mechanism in a DD4T with SOA providers setup. Publishing Flow This flow is a standard Content Delivery DB publishing flow: TRIDION CONTENT MANAGER publishes Pages, Components and Binaries to a DEPLOYER that writes everything in the CONTENT DELIVERY DATA STORE . It is very important to emphasize here that all  publishing types go to the CD DB and that nothing is written to a file-system. Content Delivery Flow This flow represents the normal delivery of pages and binaries from the web-application DD4...

This little project has been on my mind for a while now: write a set of DD4T providers for OData (aka the Content Delivery Web Service). The approach is to remove all mentions of the CD API from the DD4T application itself and restrict Tridion interaction to the OData service. The DD4T application would use an OData client to talk with the service. Since communication with OData goes over HTTP, the number of queries to the service must be kept to a minimum, so the DD4T PageFactory will make heavy use of caching. I implemented an EHCache provider for DD4T, but that's not the scope of this blog post. So finally, this weekend I set on to writing these providers. The first challenge quickly showed up; the CD API is used in many DD4T classes and in the cases where the actual functionality is not used directly, DD4T still makes extensive use of CD API classes and interfaces. It took me a couple of hours to remove the mentions to com.tridion.* packages. During this process, t...

This post explains the steps to install RSTL on your Tridion presentation server. For more information about RSTL, check out my post  REL Standard Tag Library . To download RSTL go to my Google Code page . Always use the  latest JAR . Prerequisites Although installation itself is very simple, there are some prerequisites: Install and configure a Content Delivery server. This can be either a Java or .NET. If CD API is used, make sure you call the PageContentAssembler to assemble Pages and ComponentPresentationAssembler to assemble Component Presentations. This ensures the REL tags are executed; If CD Web Service (OData) is used, make sure all content is published to the CD DB; Create and configure a Deployer that publishes the content and/or metadata to the CD DB: For CD API, content does not have to be in the CD DB, but in order to execute REL tags it should be; for OData, all content and metadata should be in the CD DB; Create and configure a Publication ...

The current post is a follow-up of the previous OData Query Extension I had developed for Tridion 2011 and 2013: Extending OData Query Functionality URL Syntax for OData Query Extension Function Support for Queries in OData Extension The code for this version is available in my GitHub project , distributable JAR ( odata-query-extension-1.3.jar ). DynamicContent REL Tag This tag queries for dynamic Component Presentations using the CD API Query and Criterias. It accepts the following attributes: <tridion:dynamiContent  var=" name "  filter=" expr "  orderby=" expr "  top=" int "  skip=" int "      componentTemplate=" tcmuri " /> , where: var - name of the TransformContext variable that would hold the result. If var is specified, the resulting array of ComponentPresentation objects is stored into the TransformContext ; otherwise, the DCPs are output one after the oter; filter - expression specifying...

Since the introduction of Tridion's Content Delivery Web Service (aka OData), we see more and more implementations that choose Service Oriented Architecture (SOA) over the classic hosted CD stack approach. So what does this imply? Well, rather than implementing the Content Delivery stack on each AppServer, we separate the Tridion servers from the other 'middle-tier' servers, such that: the App Servers 1..n contain customer specific logic and only a very thin client to communicate with the Content Delivery Web Servers ( CDWS Server 1..n ), potentially behind a Load Balancer; the CDWS Servers 1..n run the Tridion Content Delivery Web Service ( OData ). These are the only servers in the architecture running SDL Tridion code. These servers connect to either a shared or dedicated Content Delivery Database (CD DB) -- fka the Broker DB; Service Oriented Architecture using light weight clients connecting Tridion OData service This article presents the above-mentioned a...