Sometimes bad data can sneak into the smallest of things and wreak havoc on a site bringing up a dreaded error page (hopefully captured and prettified). We’re going to cover two examples of sneaky bad data blowing up a component and how we can address the problem.
The scenario here revolves around an invalid datasource and a component making use of Glass - this bad data can come about from a publishing issue (such as publishing the page which references a datasource that hasn’t been published or wasn’t in the final workflow step to allow publishing), or some other kind of issue (an invalid item ID, a deleted item still being referenced etc).
1. Getting the Item
In the code for our rendering, we want to grab that datasource item to help out our model, so we did the following:
This confirms that the Guid is a valid format - but doesn’t confirm that it’s a valid item in the database before we pass it to GetItem to grab and cast to our Item_Type.
It wouldn't be unreasonable to expect GetItem to throw a null, which is exactly where I ran into trouble. Instead of returning a null, it blows up and you’ll never reach the next line.
To avoid this error remove references to GetItem<T>, confirm that your item exists, then use Cast<T> instead.
For example:
2. View Rendering Issue
In our same scenario we can come across another issue with the use of View Renderings - this view rendering has a datasource passed to it (instead of using the context item).
For example:
The usual expectation is that the model would return null if we had some kind of issue with the datasource. However, in this situation the bad datasource will blow the rendering up before ever trying to check that If Statement.
The problem isn’t with the view rendering, but getting the rendering within the pipeline. Sitecore will check to see if there’s a value (Sitecore.Mvc.Pipelines.Response.GetRenderer) and send it back. So, if the datasource is set but wrong, instead of returning null it just sends back the bad data. It attempts to use the default model and promptly blows up - expecting a different model that’s never properly sent.
To fix this, we can override GetViewRenderer with a custom pipeline- modified from this thread:
https://github.com/mikeedwards83/Glass.Mapper/issues/163
This will prevent your view renderings from blowing up from a busted datasource as long as you have the regular null checking on the model set up!
The scenario here revolves around an invalid datasource and a component making use of Glass - this bad data can come about from a publishing issue (such as publishing the page which references a datasource that hasn’t been published or wasn’t in the final workflow step to allow publishing), or some other kind of issue (an invalid item ID, a deleted item still being referenced etc).
1. Getting the Item
In the code for our rendering, we want to grab that datasource item to help out our model, so we did the following:
This confirms that the Guid is a valid format - but doesn’t confirm that it’s a valid item in the database before we pass it to GetItem to grab and cast to our Item_Type.
It wouldn't be unreasonable to expect GetItem to throw a null, which is exactly where I ran into trouble. Instead of returning a null, it blows up and you’ll never reach the next line.
To avoid this error remove references to GetItem<T>, confirm that your item exists, then use Cast<T> instead.
For example:
2. View Rendering Issue
In our same scenario we can come across another issue with the use of View Renderings - this view rendering has a datasource passed to it (instead of using the context item).
For example:
The usual expectation is that the model would return null if we had some kind of issue with the datasource. However, in this situation the bad datasource will blow the rendering up before ever trying to check that If Statement.
The problem isn’t with the view rendering, but getting the rendering within the pipeline. Sitecore will check to see if there’s a value (Sitecore.Mvc.Pipelines.Response.GetRenderer) and send it back. So, if the datasource is set but wrong, instead of returning null it just sends back the bad data. It attempts to use the default model and promptly blows up - expecting a different model that’s never properly sent.
To fix this, we can override GetViewRenderer with a custom pipeline- modified from this thread:
https://github.com/mikeedwards83/Glass.Mapper/issues/163
This will prevent your view renderings from blowing up from a busted datasource as long as you have the regular null checking on the model set up!
This comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete