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.

Before we go into why this might be useful and how exactly it works, heres the code. First, code your controller as follows. TRI separates Controllers and Views using Areas, so you could create a new Area, and add the controller in there, or add it to an existing custom area. However there is nothing to stop you just adding it in to your web app in a Controllers folder

Next you need to add a route for the controller in your TRI web application (typically in Global.asax):

Note that if you are using Areas, you should ensure you specify the area in which your controller lives in the routing:

And thats it – build and run the site and hit any page. Then prepend json to the URL, and see the content come back as JSON. For example to see the dynamic list of news items in the example site use the URL /json/articles/news

This is pretty cool – as it is not only giving me static content on the page, but actually any data that is built into my view model by whatever controllers are defined to render the items on the page, so if I had some funky controller, which merged CMS content with some product data from PIM and ERP systems, I would have this data also in my returned JSON.

So how does it work? Actually its pretty simple. In the controller, we load in the page model (in the same way as if we were rendering the page as HTML. We then loop through all the regions in the page, and pull out all the entities (=Component Presentations) in those regions. Each entity can be executed by a different controller, so we use built in TRI methods to retrieve the Area+Controller+Action to execute and then, using Reflection call this action to get a view result. We don’t actually want the rendered content, but rather just the view model, so we pull this out and return it, to build up a list of populated View Models. ASP.NET MVC does the rest with its simple Controller.Json method, which builds JSON from whatever object you pass it.

This was just a bit of fun, but gave some valuable insights into what we could do better for the next release of TRI. For example, rather than executing the whole controller action to build the view model, it would be better to simply call the BaseController.ProcessModel method, which handles the mapping of the Component Presentation to the View Model, plus any additional logic to populate the model from other systems (eg search index/ERP system etc.). This method is protected however, so we cannot call this directly and have to go through the controller action, using reflection. For the next release we will make it easier to get at the model processing from outside the controller, plus add some native support for data formats, so you can get page content in JSON, XML or RSS…