I think my issue with this approach is that it appears to work for simple cases, but not when things get more complex, one of the advantages of a controller is that you can create a view model with a base view model which has fields for use on the layout page. this can be important for adding information such as open graph tags or for when unique fall backs need to be managed for title/meta descriptions, or the header may need to be altered based on the current page for example.
As great as View Components are, they are not really a substitute for these kinds of scenarios.
Using Kentico in MVC5 currently has a different approach, I can still get all the advantages mentioned above (with the exception of all the dotnet core view component goodness) but I also have control of the output via a controller should I need this.
it seems a pity that kentico have followed this approach with dotnet core, whilst its possible you may have a simple enough project with no need for a controller, sometimes there are other complexities that need to be considered, the option to do either would be the perfect solution. Allowing developers to choose how they architecture a system is important, unless there are critical reasons why a particular approach will not work.
This is an excellent article about the advantages of page templates showing when to use fields on the template vs the page (which is super important) but it doesn't argue away the need for the MVC pattern. A combination of both would mean there is no need for any code smell anywhere. doesn't the fact that we have to write an article explaining how to avoid a code smell show there is a big potential problem here?
Keep up the good work Sean, I enjoy your articles.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Hey Chris, thanks for reading and thanks for the thoughtful reply!
I agree that for simply cases, Page Templates + View Components (or Child Actions in MVC5) is a great approach, and for advanced use cases you will want to use MVC Controllers.
you can create a view model with a base view model which has fields for use on the layout page
This can also be accomplished by setting values in a scoped service in the View Component used with a Page Template. The scoped service's value can then be read in the _Layout.cshtml because the Page's "View" is always rendered before the "Layout" is.
but I also have control of the output via a controller should I need this.
We can still use Controllers in ASP.NET Core for Page Templates if we want. In my examples I show how to route directly to the Template, but this is not required.
whilst its possible you may have a simple enough project with no need for a controller, sometimes there are other complexities that need to be considered, the option to do either would be the perfect solution.
Unless I misunderstand, the only thing we can't do with Page Templates, that you would like to see, is create a custom View Model class that is made available to the Page Template Razor View.
This is why I use View Components to do the heavy lifting of creating a custom View Model.
I see Page Templates as a 2 phase process:
Xperience does all the processing to prepare the Page / Properties instances for the ComponentViewModel and route to / render the Page Template View.
We then step in and use that 'context' that Xperience prepared for us, to fully customize what needs to be rendered (using View Components or other tools).
I'm glad that Xperience handles all of step 1 and step 2 still allows me to customize everything I need.
doesn't the fact that we have to write an article explaining how to avoid a code smell show there is a big potential problem here?
Maybe? The code smell isn't using MVC - it's putting design customization in Page Type fields (however a code smell isn't necessarily an indication of a bad design or a problem). I think we should try to avoid combining content with design, but sometimes it's going to be the best choice 🤷♂️.
PTVC is a pattern that has helped me avoid that code smell where possible vs MVC, which only exists in ASP.NET because Ruby on Rails was popular back in the late 2000s. It's a pattern that the framework gives to Xperience to perform presentation logic and render HTML, but it's not the only one, and it wasn't designed to benefit content management in a CMS/DXP.
I recommend developers default to using PTVC, but I never stated that MVC is useless. I explicitly called out that it should be used if custom routing is required. I have not run into a situation using PTVC where I wasn't able to fully customize the rendered page, so I don't think that MVC brings me any additional 'power' here.
If you have use cases where MVC Controllers allow you to do things that PTVC doesn't, then that is a great reason to not use PTVC.
This post absolutely has a click-bait title 😁, but it's also a 12 minute read (according to DEV), so hopefully I've added context to my claims.
In summary, I believe that with ASP.NET Core Kentico Xperience 13+ sites, developers should default to the PTVC pattern over MVC. If MVC brings something they need, then use that instead. All of this is only about presentation logic anyway - there's plenty of room left in an application for other design patterns that let developers build their custom solutions as needed.
Again, thanks for the thoughtful comment - I want the Xperience community to think about all these things, share ideas, and pick the solutions that work best for their projects. This discussion helps everyone!
thanks for the quick reply, you say "We can still use Controllers in ASP.NET Core for Page Templates if we want." as far as I can see this is not the case for core, but you can do that if you build an MVC5 project.
if seems to be the difference to how the RegisterPageTemplate attribute is setup, in MVC5 you can point it to a controller which inherits from PageTemplateController, but this step doesn't appear to have been carried across to core, all you can do is specify a view.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
We can create a Controller that handles rendering Pages of a specific type that also use Page Templates in ASP.NET Core and we can access the Page that is being handled by that Controller action method via the IPageDataContextRetriever service. We can do all kinds of custom logic here, populating scoped services, even preparing a View Model that we can retrieve in the Page Template View (while I don't recommend that approach, the DancingGoatCore app does this with the ArticlesController).
However this Controller is the one that returns the TemplateResult, which in MVC5 is 1 of 2 Controllers that can be defined.
You are correct 👍👍 - in ASP.NET Core we cannot create a custom Controller that prepares the View Model and selects the View to be rendered, like we can in MVC5.
Having worked a lot with Page Templates in MVC5, I always found this 'double Controller' pattern to be confusing and made for a lot of boilerplate, and I've found its removal in ASP.NET Core isn't a limitation - it just moves the process of preparing the View Model from a Controller into a View Component (or multiple View Components).
I'm definitely biased, having worked with ASP.NET Core since the pre-1.0 days, so I'm probably promoting the use of things like View Components and Tag Helpers (and dependency injection) more than developers that are new to ASP.NET Core are used to. I also think these tools can be leveraged to great effect in Kentico Xperience.
A lot of things we do in Kentico 12 MVC sites are not because they are great solutions, but because the Kentico team was working against the constraints of a framework initially designed in 2008-2009.
I feel like in ASP.NET Core, a lot of those constraints are gone and better patterns are available and should be explored or encouraged. Or, if they aren't available yet, the architecture is set up in a way to make them available in the future if the community is vocal about needing them (example: Form Builder Section Properties coming in KX 13 Refresh 2 at the end of the month).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think my issue with this approach is that it appears to work for simple cases, but not when things get more complex, one of the advantages of a controller is that you can create a view model with a base view model which has fields for use on the layout page. this can be important for adding information such as open graph tags or for when unique fall backs need to be managed for title/meta descriptions, or the header may need to be altered based on the current page for example.
As great as View Components are, they are not really a substitute for these kinds of scenarios.
Using Kentico in MVC5 currently has a different approach, I can still get all the advantages mentioned above (with the exception of all the dotnet core view component goodness) but I also have control of the output via a controller should I need this.
it seems a pity that kentico have followed this approach with dotnet core, whilst its possible you may have a simple enough project with no need for a controller, sometimes there are other complexities that need to be considered, the option to do either would be the perfect solution. Allowing developers to choose how they architecture a system is important, unless there are critical reasons why a particular approach will not work.
This is an excellent article about the advantages of page templates showing when to use fields on the template vs the page (which is super important) but it doesn't argue away the need for the MVC pattern. A combination of both would mean there is no need for any code smell anywhere. doesn't the fact that we have to write an article explaining how to avoid a code smell show there is a big potential problem here?
Keep up the good work Sean, I enjoy your articles.
Hey Chris, thanks for reading and thanks for the thoughtful reply!
I agree that for simply cases, Page Templates + View Components (or Child Actions in MVC5) is a great approach, and for advanced use cases you will want to use MVC Controllers.
This can also be accomplished by setting values in a scoped service in the View Component used with a Page Template. The scoped service's value can then be read in the
_Layout.cshtmlbecause the Page's "View" is always rendered before the "Layout" is.We can still use Controllers in ASP.NET Core for Page Templates if we want. In my examples I show how to route directly to the Template, but this is not required.
Unless I misunderstand, the only thing we can't do with Page Templates, that you would like to see, is create a custom View Model class that is made available to the Page Template Razor View.
This is why I use View Components to do the heavy lifting of creating a custom View Model.
I see Page Templates as a 2 phase process:
ComponentViewModeland route to / render the Page Template View.I'm glad that Xperience handles all of step 1 and step 2 still allows me to customize everything I need.
Maybe? The code smell isn't using MVC - it's putting design customization in Page Type fields (however a code smell isn't necessarily an indication of a bad design or a problem). I think we should try to avoid combining content with design, but sometimes it's going to be the best choice 🤷♂️.
PTVC is a pattern that has helped me avoid that code smell where possible vs MVC, which only exists in ASP.NET because Ruby on Rails was popular back in the late 2000s. It's a pattern that the framework gives to Xperience to perform presentation logic and render HTML, but it's not the only one, and it wasn't designed to benefit content management in a CMS/DXP.
I recommend developers default to using PTVC, but I never stated that MVC is useless. I explicitly called out that it should be used if custom routing is required. I have not run into a situation using PTVC where I wasn't able to fully customize the rendered page, so I don't think that MVC brings me any additional 'power' here.
If you have use cases where MVC Controllers allow you to do things that PTVC doesn't, then that is a great reason to not use PTVC.
This post absolutely has a click-bait title 😁, but it's also a 12 minute read (according to DEV), so hopefully I've added context to my claims.
In summary, I believe that with ASP.NET Core Kentico Xperience 13+ sites, developers should default to the PTVC pattern over MVC. If MVC brings something they need, then use that instead. All of this is only about presentation logic anyway - there's plenty of room left in an application for other design patterns that let developers build their custom solutions as needed.
Again, thanks for the thoughtful comment - I want the Xperience community to think about all these things, share ideas, and pick the solutions that work best for their projects. This discussion helps everyone!
Hi Sean,
thanks for the quick reply, you say "We can still use Controllers in ASP.NET Core for Page Templates if we want." as far as I can see this is not the case for core, but you can do that if you build an MVC5 project.
if seems to be the difference to how the RegisterPageTemplate attribute is setup, in MVC5 you can point it to a controller which inherits from PageTemplateController, but this step doesn't appear to have been carried across to core, all you can do is specify a view.
MVC 5
[assembly: RegisterPageTemplate("CompanyName.HomeTemplate", typeof(HomeTemplateController), "Homepage template.")]
CORE
[assembly: RegisterPageTemplate("CompanyName.HomeTemplate", "Homepage template", "~/HomeTemplate/_HomeTemplate.cshtml")]
but i get your point about Scoped service, that could well be a way to approach the problem.
Ahhh, I understand what you're saying now 😁.
We can create a Controller that handles rendering Pages of a specific type that also use Page Templates in ASP.NET Core and we can access the Page that is being handled by that Controller action method via the
IPageDataContextRetrieverservice. We can do all kinds of custom logic here, populating scoped services, even preparing a View Model that we can retrieve in the Page Template View (while I don't recommend that approach, the DancingGoatCore app does this with theArticlesController).However this Controller is the one that returns the
TemplateResult, which in MVC5 is 1 of 2 Controllers that can be defined.You are correct 👍👍 - in ASP.NET Core we cannot create a custom Controller that prepares the View Model and selects the View to be rendered, like we can in MVC5.
Having worked a lot with Page Templates in MVC5, I always found this 'double Controller' pattern to be confusing and made for a lot of boilerplate, and I've found its removal in ASP.NET Core isn't a limitation - it just moves the process of preparing the View Model from a Controller into a View Component (or multiple View Components).
I'm definitely biased, having worked with ASP.NET Core since the pre-1.0 days, so I'm probably promoting the use of things like View Components and Tag Helpers (and dependency injection) more than developers that are new to ASP.NET Core are used to. I also think these tools can be leveraged to great effect in Kentico Xperience.
A lot of things we do in Kentico 12 MVC sites are not because they are great solutions, but because the Kentico team was working against the constraints of a framework initially designed in 2008-2009.
I feel like in ASP.NET Core, a lot of those constraints are gone and better patterns are available and should be explored or encouraged. Or, if they aren't available yet, the architecture is set up in a way to make them available in the future if the community is vocal about needing them (example: Form Builder Section Properties coming in KX 13 Refresh 2 at the end of the month).