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.
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).