Rafeeq on .NET

Sometime when we work with Component presentation, we might come up with the scenario to have customized RenderComponentPresentation, when we deal with Area/View or splitting view into more organized structure. We can fetch and send the area from the Template. Currently DD4T doesn’t allow injecting the ComponentPresentationRenderer, instead it allows us to write our own renderer and call it along with RenderComponentPresentation as below The custom ComponentPresenationRenderer can be created based on the scenario, so when we use the area, we could have the custom ComponentPresentation as below SDL Reference implementation, customized Renderer beautifully and implemented the Renderor to use Area view concept.

There always been a question on What is the best approach for building navigation with DD4T and ASP.NET MVC? Answer is: There is TridionSiteMapProvider as part of the DD4T.Mvc project, which can be used out of the box. The  DD4T.Examples.Templates project also have a example on how Sitemap can be generated from the template ( TBB ) Many organization will have different kinds of navigation structure, It can be from very simple structure or it can be a heavily complex in nature. In this article you can see how the default SitemapProvider can be used and how we could customize to achieve complex Navigations like Megamenu or similar using TridionSiteMapProvider. Setting up the default TridionSiteMapProvider The only configuration you would need to do in web.config is set the your default sitemap provider is as below. <system.web> <siteMap defaultProvider= "TridionSiteMapProvider" enabled= "true" > <providers> <clear/> ...

Well, It's the high time to think about DD4T. What is DD4T? What makes more easier to the developer and Editor to talk about DD4T.!!  DD4T is a framework that developed by Tridion veterans. The framework makes it easier for Tridion developers to develop, deploy and maintain a project. The basic building blocks of Tridion  like, schema, components, template etc. are still remain the same as below. So what changes, if you look at the below diagram, you could see the different between both So, the whole logic goes to the web server, CMS just plays the role of generating the pages and delivering it to the Broker, no Template logic or HTML in CMS any more. DD4T solves the problem by making sure the pages and content are published to the broker as data, without any HTML rendering. If we summarize the diagram. 1) The role of editor and visitor are normal, and that is the main aspect of DD4T architecture. 2) Everything is published to the broker database. ...

DD4T is a great framework which would give you everything in place what you basically needed. Here we will see how we could resolve the publication based on the URL,  when we work with multiple publications accessing same web site, our DD4T would need to query dynamically to different publications. Many times it can be based on URL, based on the domain or language we could resolve the publication. It’s obviously up to us how we implement it. By default the DD4T framework queries the publication that we have mapped in the key: <add key="DD4T.PublicationId" value="7" /> or keep it 0 to query all publications We can make it dynamic simply by implementing the IPublicationResolver class Step 1: To resolve publication dynamically, we can write a class that implement DD4T.ContentModel.Contracts.Resolvers.IPublicationResolver namespace Indivirtual.DD4T.Mvc.Resolver { public class SitePublicationResolver : IPublicationResolver { ...