This has come up a few times recently in some upgrade projects I've done. Typically the codebase is using Glass Mapper, the ORM that makes linking a Sitecore template to a strong-type class very easy. They also use view renderings in a lot of cases, because you're just getting that model back and using it, so it should be straightforward and not require a lot of the extra "plumbing" you find in a controller rendering.
Except it's not quite that simple. You can do a null check for Model == null all day long, but Glass isn't returning null there. Instead, you get the dreaded YSOD saying that the model expected a type of "your model" and instead got a default Sitecore rendering model instead. Now, you can get around this by going into Sitecore, under Layouts, and using the Models section to create a model entry and attach it to your rendering definition. But that's extra database stuff and you don't absolutely have to do that. Instead, use your good old MVC pattern.
It's pretty straightforward...create a controller rendering entry in Sitecore, create a controller and its related view, reference the controller class and action name in the Sitecore entry. And even if you're just retrieving the model as-is and passing it on, you can do that with simple code. Or, you can process things more, use a view model, and pass in more complex results. But the best thing is, you stay consistent with your other renderings that might return results based on search results, for example, that have to be controllers. And it creates an easy grouping to follow in a Helix pattern, to boot.
What about those null renderings, though? Well, now you can do a check to see if your model class is null after attempting data retrieval and pass null onto the view, then your null check on the view will work as you expect. I've also seen some other ways to do this without the explicit null checks in your code...there's this blog link that describes creating an attribute for your controller action that requires a datasource, and either provides a contextual message to the missing source in experience editor, or returns an empty result in normal mode (and thus handles your null check for you).
I'm not saying you should eliminate all view renderings, of course...if you're doing something that's mostly Javascript based like a Twitter widget, or the Coveo widgets, those are view renderings for the most part. But the ability to better control your data processing and result set in a controller rendering makes them a preferable option, in my opinion. I used to be a big view rendering fan because of the simplicity, but to cover all of the possibilities that could trip up your users, the controller rendering can save your bacon.
Plus you're not adding a lot of processing code to a model...one thing I used to do was use TDS code generation to get the model mapping from Sitecore, then take advantage of the partial class to "weld" on extra fields, some of which did business logic. If I could go back a few years and knock some sense into myself, I'd realize the smarter way was to just have the model, use the controller to do the business logic, and use a view model if I'm adding fields into the mix. Chalk it up to learning Sitecore and MVC at the same time, I came from the Ektron world where it was still web forms!
In every case when testing this last upgrade I did, if I ran into the YSOD "missing datasource" message, I just went in, changed the view rendering to a controller rendering, added an action in an appropriate controller, and voila, rewiring was complete. It's pretty straightforward to do, and even if you're just doing an upgrade, it may be worth your while to go in and rewire those renderings to add some assurance for your client. And save yourself some sanity to get away from those YSODs.
Top comments (0)