Setting up an MVC site - the things Kentico 12 doesn't do for you

Posted: 1/30/2019 1:47:46 PM by Chris Bass | with 2 comments

I was all set to present an MVC controller/route setup for restoring NodeAliasPath functionality for Kentico, but honestly I just saw 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.




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!
6/18/2019 5:35:37 AM

Trevor Fayas
Thanks Chris for the plug!

Two things, firstly i have a Kentico Boilerplate project on Git Hub, would love for you to check it out and feel free to fork and do a pull request if you have more features. The boilerplate has a ton of the things set up for you where the blank MVC site doesn't, however i didn't implement the Marketing features. Do you think you could add those in?

Secondly, with the upcoming Service Pack, the Routing is going to become even better for a couple reasons. I'll still need the Dynamic Routing logic, but i plan on leveraging new Page Templates (different from Page Builder Templates) so we can point a user to the proper Controller/Action dynamically, really restoring Portal functionality. Plus they do have Alternative Urls (which despite what my blog article said, CAN be set to not do a 301 but actually render at that url, based on a url setting introduced in the service pack).

I'll update the Boilerplate once the SP comes out.
6/14/2019 9:57:31 AM

 Security code