Blog posts by Dave Beattie2021-03-16T09:32:24.0000000Zhttps://world.optimizely.com/blogs/dave-beattie/Optimizely WorldEpiserver Routing Error ‘The routed data is of type..and the binding context data ... is of type ..., neither of which matches the requested type...’<p>Recently while trying to build an Episerver ecommerce solution I ran into an error with a type mismatch where navigating to any type of node or product failed with a type mismatch.</p>
<p><img src="/link/9954ac408fe5443b9d2aa8551c2b24cc.aspx" /></p>
<p>The ‘requested type’ for each product was always the same class. I then noticed whenever a new type of product was added, the requested type was always the first type of model alphabetically.</p>
<p><img src="/link/447777f8cacb4b39bf214443c4f646d8.aspx" /></p>
<p>The controller for each node and product type was inheriting from a base controller.</p>
<p><img src="/link/ecb34914d33d47aebe82724af052799d.aspx" /></p>
<p>This turned out to be where the problem lay. Each controller looked ok and seemed to be configured for the relevant model.</p>
<p><img src="/link/a366c9ee6eae44fa85c865ad74b16f5c.aspx" /></p>
<p>However, there was a typo in the inheritance on the base class here, which led to each controller compiling as ContentController<CatalogContentBase>. Thus when processing the route, episerver was getting confused as to which model it should be resolving the route for, and just took a stab in the dark and grabbed the first model inheriting from CatalogContentBase it could find. </p>
<p><img src="/link/56905263db214b46b3da8583d3dff4bb.aspx" /></p>
<p>Changing this to a type parameter constraint, so any class implementing this controller would have to be routing a model implementing catalogContentBase, fixed the error. </p>
<p><img src="/link/c69bd9be25634162bb618603c3045a6b.aspx" /></p>
<p>Essentially if you run into this error, check that all your controllers are routing the correct content type, and if there is a base class, ensure this is also configured properly.</p>2021-03-16T09:32:24.0000000ZBlog postEpiserver AJAX and standard MVC calls with Localization<p>This post is inspired by Stefan’s solution <a href="https://stefanolsen.com/posts/ensuring-the-right-ajax-content-language-using-a-filter-attribute/">here</a>.</p>
<p>Recently I was involved in a project replacing a custom translation solution on a client’s site with a more standard Episerver solution using Episerver Languages to translate content and DblocalizationProvider for static text.</p>
<p>One issue we ran into was with API calls and AJAX requests. The site is an ecommerce site and there were several places where requests where directed through a standard mvc controller/action route, rather than going through Episerver content routing. This proved problematic when attempting to return translated content such as error messages as we found the current culture was lost and the site was using the default culture. </p>
<p>We settled on using an ActionFilter to retrieve the language code from the url. Initially we had used Stefan’s implementation tailored to AJAX calls. However, we ran into further issues as a payment gateway implementation was using an api method as it’s return url in order to process the payment status and either complete the order or return an error message. This we created something that would retrieve the language code from any request. </p>
<p> </p>
<pre class="language-csharp"><code> public class StandardMvcRequestSetLanguageAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext?.RequestContext?.HttpContext.Request == null)
{
return;
}
HttpRequestBase httpRequest = filterContext.RequestContext.HttpContext.Request;
if (filterContext.RequestContext.RouteData.Values["language"] != null)
{
var lang = filterContext.RequestContext.RouteData.Values["language"].ToString();
Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo(lang);
}
}
}
</code></pre>
<p><img src="/link/f96f9671b4714468aa9a19b31858ce1f.aspx" /></p>
<p>We then discovered that Episerver wasn’t supported localized urls for non content paths (it’s perfectly fine for links to content that goes through Episerver’s routing.) Therefore we also registered a basic path with the language code in. Our ajax calls and the return urls for our payment gateway were now able to return translated error or success messages.</p>
<p> <img src="/link/bbc823a402cf41519dbdd659ac85c1ff.aspx" /></p>
<p> </p>2021-03-16T09:32:18.0000000ZBlog post