I was all set to present an MVC controller/route setup for restoring NodeAliasPath functionality for Kentico, but honestly I just saw http://www.devtrev.com/Trev-Tips-(Blog)/January-2019/Dynamic-Routing-with-Kentico-MVC and I prefer some parts of his implementation over mine - mine used a single Controller based on the base TreeNode type, whereas his dynamically chooses a controller based on the pagetype, and handles the checking for the route differently: he creates a custom RouteHandler (coming at it from the angle of 'is this request a valid controller, if not try for a Kentico page', whereas I created an IRouteConstraint (coming at it from the angle of 'does this request match a Kentico page, if not, try it as a base Controller')
I may still demo mine at some point once I revise it a bit more, but I decided to go onto a different topic that's been on my mind:
There are a few key setup points I missed when setting up my first MVC site, and I think they're worth mentioning. Some of these are documented, some are just not to be found anywhere except in the Dancing Goat demo site.
- The first one was let out of the bag by that first paragraph, and honestly if you've been following Kentico 12 development you're keenly aware, but if you don't, data in the Pages interface in Kentico MVC are not in fact pages in the 'viewable web site' sense, by default. If you want to view them in your browser, you'll have to use your RouteConfig (App_Start/RouteConfig.cs) and map a path so the URL maps to a Controller and View, and retrieve that page to use it as part of your Model. The page really is just a data source - like an advanced custom table, in Kentico 12 MVC.
- This includes things like your custom error URLs, Culture variants, and things like that. The routing is pure MVC aside from Kentico's internal routes, so as far as URLs, if MVC doesn't handle it, it's not there.
- Building off that first one, when you first open your Kentico 12 project, there're going to be no Models, no Views, and no Controllers. There won't even be folders for the Model or Controllers until you make them.
- Unless you built your site off of the Dancing Goat demo project. In which case there will be *lots* of Models, Views, and Controllers. Unless you want to add in some dependency-injection and figure out Repositories, they're barely even worth looking at - it really is just 'Make a controller, route to it via URL, in your Action go get the Kentico pages (and any other data) you want and pass them as part of a Model you'll make, to a View you'll make.
- Kentico, rightly so, has made a lot of ado about their Page Builder interface, that lets you do some visual design on a page and lay it out directly as it will when you run the site. For it being the central 'feature' of Kentico 12, it's a bit surprising that, by default, it's disabled!
- If you want to use it, App_Start/ApplicationConfig.cs is where to go. RegisterFeatures method, and add 'builder.UsePageBuilder()'.
- While we're at it, here's some other features that are disabled unless you specifically call them out here as 'available' in the ApplicationConfig - each of them come from different namespaces, so they're easy to miss if you don't have the Using statements in place:
- Preview Mode: "builder.UsePreview()"
- Model-based data annotations for localization: 'builder.UseDataAnnotationsLocalization()'
- Allow cross-origin conversation with the Admin interface: 'builder.UseResourceSharingWithAdministration()'
- Track UTM codes for campaigns: builder.UseCampaignLogger();
- Track activities: builder.UseActivityTracking();
- Track links and openings of emails: builder.UseEmailTracking();
- If you do end up using the Page Builder, not only do you need that Application Config set up, you also need to add in styles (@Html.Kentico().PageBuilderStyles()) and scripts (@Html.Kentico().PageBuilderScripts()) to your page - probably in your master page.
My hope is that in the future the Config settings will at least be demoed in comments. I've heard the idea of templates for models/views/controllers being set up in Visual Studio - that'd help with all this a lot, or if at the very least Kentico just generated stubs for them for download like they do with the Page Types - just get a zip file when you make a page type for a model, view, and controller based on that page type's fields.
I get some of this - They really tried to make the live site be *just* an MVC site, without Kentico functionality built-in. The problem is, for the grand majority of Kentico MVC projects, you do in fact plan to use some Kentico functionality :) And it'd be nice to not have to reference the demo site just to get things working.