I recently downloaded the latest version of Sitecore which is 8.2.X. And when i was playing with default vanilla instance, i met few things related to controller rendering new which led me dig into it. So, here i am sharing my experience with controller rendering in Sitecore. I am not sure if that is the case with everyone or i interpreted few things wrong. Intention for writing this is to spread my view as well have opinion of community experts stating what’s true and what’s not.
After installing Sitecore 8.2 vanilla version, i found that there is a folder inside /sitecore/layout/ named Controllers just like we had models.
It was present there since some previous versions. Not exactly sure from which version and why. So, i tried to figured out how to use it.
- As we can see there are only two fields which is Controller Name and Action Name which we generally comes with Controller Rendering. So, first thought comes in mid if there is some separation of these two fields from controller rendering. But that isn’t a case. We can see both fields present in the Controller Rendering.
- For models we creates a model in /sitecore/layout/models folder and link it to view rendering with the help of model field present in view rendering Similar way i tried to check if controller rendering has such field or not (No sense to have it in View rendering at all, neither to have it in controller rendering. But checked if there is some mystery) but couldn’t find.
- I than tried to find such thing in layout (again doesn’t make sense, but checked once) but couldn’t found any link.
- I also tried to add it to presentation details (taught if can be used in similar way of controller rendering) but couldn’t add any item rather than renderings.
So, it’s still doubtful thing for me, as i couldn’t use it anyway. Anyone got any more idea on this? come forward and share the secret.
Another thing which i specifically found in sitecore version 8.2.X is that sitecore helper also have a new method called ControllerRendering similar to ViewRendering which was there along with Rendering method. In prior than 8.2.X versions, we already had Controller method. So, now in 8.2 onward, we have two methods specifically related to controller. I tried to figure out difference between these two and below is my conclusion.
I setup one MVC project for my POC website. than i added two areas into that one called SiteA and another SiteB. Both area were having same structure, having one controller named Home, one action inside controller named Index, and a view called Index.
I also created one MVC layout and two renderings to load the index action from home controllers. one for SiteA area and another for SiteB area.
All set with the configuration and prep work. let’s use each methods one by one and note the findings.
I added below markup in the layout.
Output was expected. With area and controllers with same name exists, it was going to raise an error saying found two controller for the request.
Without area and having unique controller will work fine with this method.
Note that this can be resolved by adding the custom routes to the route table. but we intent to check default behavior here.
Using Controller method and without writing custom pipeline to add custom routes, It won’t be able to resolve Area.
Using Controller method, you are not calling any renderings. It directly instantiate the controller and invokes it. It won’t obey neither mvc.renderRendering nor mvc.getRenderer pipelines. So, you can’t use benefit of caching the html output either.
Now, i replaced layout with below markup.
Using this method, you can render any type of rendering, be it View Rendering or Controller Rendering. You just require to pass the path or id of the rendering item. We are dealing with the rendering items and with having specified Area name in both the controller rendering, expected output is that it should resolve the area. And it does.
It will run the mvc.renderRendering pipeline. Where Area will be resolved by RenderingDefinitionAreaResolveStrategy. Also, as we are directly refering rendering items, we do have specifications for caching and Html caching feature will also work properly.
Only thing is that it will call mvc.getRenderer pipeline but won’t be able to resolve the type of rendering which is RenderingType. And will end up being resolved by GetDefaultRenderer. Unless you are using RenderingType property to determine which type of rendering it is, It is likely to solve the purpose.
Sitecore 8.2+ introduces this additional helper method. In the release note, you will find that this is included for better handling controller rendering. I replaced layout with below markup
with the expectation that both the method should resolve correctly. But i ended up with similar error as Controller method for Controller Rendering.
As Controller Rendering won’t instantiate controller directly, It will resolve the renderer and likely to run mvc.getRenderer and mvc.renderRendering pipelines. I was expecting it to work as Rendering method. But as we are not referring rendering items directly and we aren’t specifying anything related to area so it also make sense that it couldn’t resolve area. I than tried to specify the area in the layout itself.
With the hope that now, it should resolve the area with the help of RenderingLayoutAreaResolveStrategy. But it didn’t. If you dig into this strategy than it checks if RenderingType is Layout than get layout and read value from area field. In our case using Controller Rendering method and mvc.getRenderer pipeline, GetControllerRenderer will resolve it as RenderingType Controller. Adding custom area resolve strategy may solve the issue. So, that’s one possibility to resolve area where it’s even not possible in Controller method.
I was hoping that Html Caching should work but by not referring rendering item directly, we do not have values of renderingargs. So, i really wonder why we would use this method against Rendering method? Anyone have answer, Let’s share.
Basically, i do not have any conclusion at the end of this post. But i wanted to share what i ended up experiencing. And wanted to know the experience of community experts on this topic. so that we could have better understanding of the difference between above methods.
Simple. Not Easy.