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.
Recently I’ve been performing some post-launch improvements to a DD4T site for a client. A number of their requests have been along the lines of improving screen element <x> on page <y>.
The project is reasonably large with the website being comprised from a couple of hundred abstract MVC views. A good amount of nested, view re-use, with nice generic css classes has actually been a detriment when it comes to tracking down exactly which view screen element <x> originates from.
Occasionally you find a view that includes some ‘start’ and ‘end’ comments in the output.
<!-- Start View: Example --> View contents go here... <!-- End View: Example -->
If you hadn’t noticed, SDL Web released a new product recently: Contextual Image Delivery, which in short enables you to resize, crop, trim and convert formats for images. I thought I would see how easy it was to set up in an ASP.NET MVC environment, and it went pretty well, but there are a few subtleties Continue reading
Most implementations I have worked on have sections of the website which consist of some kind of listing, which links through to pages containing detailed content. The details pages themselves contain a single ‘Full Article’ component presentation, and are often auto-created and published using the event system. As such, the pages do not really serve any purpose other than providing a definition of the url for an article.
This article shows an alternative approach to get rid of pages for a certain section of your site and use the features of ASP.NET MVC to show content without losing ‘real’ urls