Developer forum

Thank you for the reply.
The middelware approach has also been my solution, I just wanted to confirm that I wasn't overcomplicating something that had a simpler solution seeing as the one available was intentionally marked as obsolete, but great to know it won't be going away in DW 10, then for simplicity sake I might just revert to using that, even if it likely is a worse solution.

You mention the asp.net core redirect, but I don't really see how I would do that from a template. We don't have access to the httpresponse right? and I don't believe I can inject a HttpContextAccessor - so what would that implementation look like?

Hi Claus

It is not like the good old .net 4 days - for lots of reasons. You can get hold of all kind of things - see below. But it can easily become a slippery slope in your templates. Templates are rendering - all other logic should be somewhere else...

@using Microsoft.Extensions.DependencyInjection
@using Microsoft.AspNetCore.Http

@{
 var HttpContextAccessor = Dynamicweb.Extensibility.Dependencies.DependencyResolver.Current.GetRequiredService<IHttpContextAccessor>();
 <div>@HttpContextAccessor.HttpContext?.Request.Path</div>
}

One thing to be aware of in terms of redirect - in .net 4, doing a redirect also throws a ThreadAborted exception that causes the remaining code to not execute. This behavior has lots of issues why it works different in asp.net core.

So - if you do a redirect in a template in asp.net core, the code continues to execute and the result is returned to the middleware pipeline that will either send it out or continue with the next middleware. The redirect merely adds the location header to the http response header, and the browser will redirect to that location when it receives the output. But all the code after the redirect will probably still execute - and the resulting html might also be send to the browser despite your redirect. 

So if you use this redirect pattern in templates, which is architectual late, you might also get some unwanted side affects of sending data that should not be sent etc. So if you use it for things where the user should not see some data, be sure to check.

Ye I get the last part about the contiuned rendering, and I expected that was part of the reason it was marked as 'do not use'.

But super, I got the answer I was looking for, and for once it seems I hadn't overcomplicated something simple :)