The SDL Tridion Reference Implementation (TRI) comes with out of the box controllers for loading and rendering pure content-based models. However, most web applications need to blend content with data from other sources before rendering. TRI is designed with this in mind, this post introduces the pattern for creating custom controllers which merge CMS managed content with external data.
The MVPs got to grips with the SDL Tridion Reference implementation (TRI ) while on the yearly retreat in Portugal a couple of weeks back. In between getting people up and running with this new SDL Tridion product, I knocked up a Controller implementation to pull content/data as JSON from the web application.
Today I had to write a small piece of code to generate a local file system based on the structure of a given Tridion folder. It’s a throwaway bit of code but I thought it might be useful to someone out there at some point in their lives (or myself in the future), so i figured why not share it here?
One of the goals of the SDL Tridion Reference Implementation (TRI) is to provide an example web application for which ASP.NET MVC application developers can develop functionality without deep understanding of the underlying CMS. A key difference between a ‘classic’ MVC app and a CMS managed one is how URLs are managed and the impact this has on routing requests to controllers. In this article I dig into the mechanism used in the TRI to explain how it fits together.
Released last week – the first step on a path to lower the barriers (time, cost, knowledge, lack of standardization) of implementing SDL Tridion. In this post I aim to give a short introduction, by highlighting what you should and should not expect from the Reference Implementation.
I love Tridion. There’s a strange elegance to the way she operates, and when I resolve an issue or learn something new there’s no sweeter feeling. But oftentimes sometimes our Tridion can be a cruel mistress – or mister, as you fancy. We configure, install, develop, and implement on her all day long, and just when it seems we understand each other she delivers a sharp slap to remind us that she’s in charge. Saucy. Continue reading
I’ve always really loved on the SDL Tridion interface works when showing and filtering content based on Taxonomy information. I’d assumed that generating a list of classified items would be quite a tricky thing to achieve, so I thought i’d take a look to see how difficult it is using the Core Service API.
Its just over a year since Raimond and I launched SI4T – an open source search integration framework for Tridion published content. In that time the uptake has been good – I heard many stories of it being put into action after my TDS talk in May, and a trickle of questions has started appearing on stack exchange. As such, we feel its time to plan a new release, so this post is a call to arms to give anyone who has benefited from the framework the opportunity to give something back and create an even better solution.
Many have asked me, “Does ECL support BluePrinting”? My reply is always a solid yes, but (yes there is a but), I should really reply with a question: “Does your external system support BluePrinting”?
Since it is nice that ECL supports BluePrinting, but ECL just exposes items from your external system in SDL Tridion. So for them to be BluePrinted, you should have your ECL Provider make the connection between an SDL Tridion Publication and the specific items you want to show in that context. An ECL item URI contains a Publication URI, so to implement BluePrinting correctly in your provider, you will need to give the child item, the same ECL Item ID as its parent item. The only thing that is tricky there is localization, an ECL item doesn’t really have a localized state, the ECL stub Component can have that state though.
I have been busy for the last few months working on a new SDL Web ‘product’ – the Tridion Standard Implementation, which is an out-of-the box Tridion CMS and web application framework to learn from/build on top of. One of the things we are focusing on is having a single site to serve all devices with optimizations driven by SDL Mobile. Part of this is ensuring that we are smart about serving images to a device, while still making life easy for editors and (MVC) view developers. There turned out to be quite a lot of factors to consider, but I think we came up with a pretty good solution. Continue reading