We have moved to GitHub Issues
Created by Arnold Visser 17 Dec 2012, 13:24:07 Updated by Sebastiaan Janssen 17 Apr 2013, 09:34:26
Add the ability to change the MVC template/view in the umbraco controller using events.
Pull request done for both v4 and v6
That's what she said.. ;-)
Very cool. This would be great for swapping out desktop/mobile masters.
@Randy: That is actually unnecessary in v6. MVC4 provides native, customizable desktop/mobile switching. But this ability could certainly still have its uses, no doubt about that.
I'm currently creating a website with MVC that uses uWebshop 2 and this is used there. Currently running on a custom version of 4.11 that has the code from the fork, but I extended it a bit more. The event to change the template is not enough because if you suddenly return a different view (template) it could also need a new model. So in the attachment is a version which has an extra event. If the template is changed you can also change the model.
Hmm does the attachment work? Getting a 404 when trying to download.
@Jeroen: doesn't work for me. I realize I didn;t update the issue, but we rejected the pull request because it was fixing this in the wrong way. So while your update might work, it's not the way we want to handle this in the core. See the pull request for the full explanation.
Removed it if it's not going to be used anyway :-). I'll keep using my custom version of 4.11 so I can use uWebshop with MVC. Doing it with some custom routing is probably a better solution.
For what it's worth there's work-in-progress on that subject at the moment, which unfortunately can't be published because parts of the request pipeline aren't public yet. Working hard to make it all public soon.
@Jeroen: point taken re. being able to change the template ''and'' the model.
In the meantime guys (@Arnold not sure if you got my email about this) but a workaround that should work and be quite easy is create an MVC global filter. You'd be able to add your global filter to the global filters collection on startup (either in your global.asax or using an IApplicationEventHandler). Then in your filter:
I think that'd work without any mods to the core and should be really easy.
Just FYI. The inbound pipeline prepares a PublishedContentRequest which represents what Umbraco must do: the domain, culture, published content, template, rendering engine... and then transfers that request to the appropriate handler (WebForms, MVC...). In the future there will be a PublishedContentRequest.Prepared event that will trigger once the request is prepared and before anything else takes place. There, you will be able to see which content is to be rendered, and to change the template, and replace it with another WebForms ''or'' Mvc template. Now about changing the "template" much later, ie in the controller, well, it's not so much changing the "template" (because eg you won't be able to pick a WebForms template) but changing the "view". An Shannon knows much more than I do about this?
Will the PublishedContentRequest.Prepared event be part of 6.1? Is it already somewhere in the source code?
Not fully in the source code, still cleaning up stuff. Hope to push this week or the week after. Yes, should be in 6.1.
@Shannon: if I understand correctly that would be for changing the template from within the MVC controller? And changing only to another MVC template? What would be the relationship between this and PublishedContentRequest.Prepared event, which is precisely intended to let ppl change the template for another one, be it WebForms or MVC?
@Stephan I'm aware of the PublishedContentRequest.Prepared which is precisely what is required to complete this task. I just updated it because I know that you were creating this event in hopes that you could close this issue :)
Oh OK. Well, it's getting closer and closer... hopefully next week...
The public pipeline has landed in branch 6.1.0-public for review by HQ, should merge into 6.1.0 eventually.
It's now merged into 6.1.0.
My bad, this has not yet been merged in, sorry! Scheduled for the final 6.1.0 release though.
The PublishedContentRequest.Prepared event sounds like it might solve a particuarly tricky issue I am working on right now. Can you change the content (NodeID) being rendered in this event also?
Technically, yes. Practically, you might want to question whether it makes sense to do it in the .Prepared event, or via a ContentFinder (formerly known as NotFoundHandler). Content finders run before .Prepared, and are meant to find content based upon the url. So if your idea is to use a special url scheme to pick some content, then a ContentFinder would be more appropriate?
I did a quick search for ContentFinder and can't find any info. The url I want to redirect would also be a valid UMBRACO url, so a NotFoundHandler would not fire. Are ContentFinders different to NotFoundHandlers or has the name just changed? Basically I am looking for a NotFoundHandler which would fire for all page requests.
Umbraco.Web.Routing.IContentFinder -- should be public in 6.1 and is not yet because I'm late.
They are different to NotFoundHandler in that NotFoundHandlers ran once everything else had failed (and in theory, were meant to display a 404 page of some sort, although people started to use them for other things), whereas ContentFinders run way before. In fact, Umbraco implements some important ContentFinder, such as ContentFinderByNiceUrl which tries to find a content based upon the request url.
You can remove, insert, reorder the content finders, so yours could run first, last, whatever. In you case if you want to catch a valid Umbraco url before Umbraco finds the corresponding document, you'd insert your content finder before the built-in finders.
Oh and obviously, I also plan to document all this or at least post some sample code on Our.
Excellent news, sounds like just what I need.
@Stephan, can we close this now ?
Type: Feature (request)
Assignee: Shannon Deminick
Backwards Compatible: False
Fix Submitted: Pull request
Affected versions: 4.10.0, 4.11.0, 6.0.0, 4.11.1, 4.11.2, 4.11.3, 4.11.4
Due in version: 6.1.0