So I've been doing razor + mvc5 for almost the last year, and that being the case, I'm starting the process of porting CarrotCakeCMS into MVC5. Here's the brainstorm I've had so far:
Draft of MVC version can be found at http://sourceforge.net/projects/carrotcakecmsmvc/ and at https://github.com/ninianne98/CarrotCakeCMS-MVC. Note: this is a Visual Studio 2013 project/solution.
Templates inherit a special razor web page which has the page data + widget info, it lazy loads the current page data into a named ViewData key so that sub components don't have to retrieve the page all over again.
Some built in components emit both CSS and HTML. these can be set up to load the CSS through one method call and the body content as another, so the information can be placed in the most optimized locations. What used to be server controls in the webforms version, will, for the most part, have HTML Helper extensions to provide similar support.
To support functionality of the CMS, some helper functions are required: a header + footer CMS function for live edit purposes + some meta tag output (to handle blocking from search engines (robot tag) and display of meta keywords/description info. Adv editor also requires jquery + jquery UI to be included in page heading (jquery is located as an embedded resource via a web helper component and the same include brings MS unobtrusive ajax). You are welcome to get your own jquery, jquery ui, and MS unobtrusive, but they must be present for the editor to work.
Templates can specify partial views using just the main file name without extension as though it is in \Shared\ - current directory of the template will be added as a temporary search path at content controller action fire.
Each time a template is to be served, File.Exists will be called, if it does not exist, a fallback plain gray scale template will be served instead.
Templates default to live within \views\templates\<<theme specific folder>> (config can override this path) each template theme set will have a config file listing the names and captions that should be presented to page editors. It is recommended to create a companion folder in \assets\templates\<<theme specific folder>> for any/all CSS/JS needed for the template set as files contained within the \views\ folder cannot be served through IIS (MVC convention and web.config limitation). Recommend lumping all resources for a given theme together under an \assets\ paradigm rather than having to keep track of separate \content\ and \scripts\ paths for a single template.
No bootstrap in the admin area, though rudimentary classes for some layout will be included for those who did simple scaffolding so that the layout doesn't look too awful. Jquery UI and Bootstrap don't get along very well and so much of the framework depends on Jquery UI being a happy camper, so the back-end UI will look much the same as the WebForms version.
4 main widget types
- controller action (using partial views) + assembly+class - model needed to init context settings is specified on action via attribute, optional suffix to specify alternate view from the default
ActionName:ClassNamespacePath, AssemblyFile (note the colon) - cshtml/vbhtml file that does not take a model
<<Full file name>>.cshtml or <<Full file name>>.vbhtml - cshtml/vbhtml file paired with assembly+class - should implement one or more widget interfaces to initialize settings
Full file name|ClassNamespacePath, AssemblyFile (note the pipe) - assembly + class that implements IHtmlString (can implement other widget interfaces for context awareness) whatever text emits when ToHtmlString() is called is what will be displayed in the UI
CLASS:ClassNamespacePath, AssemblyFile (note the prefix will be case sensitive)
Widget admin to use the default layout file (the default one outside of the Admin area). Can operate as a normal MVC form. the form will be wrappered as a sub set of the main admin template. Widget admin URLs will follow the pattern /<<assembly name aka area>>/<<controller>>/<<action>>/
Widgets in the front end can be used to display data stored in the system and can post, provided it is done as a partial postback (ajax form) or json or anything else that won't trip a postback to the content controller - could probably do a post of FormCollection but won't yield a strong model. Comment and Search have special helpers to generate the forms, please use those if utilizing those features.
One constraint on controller names: cannot create any controllers named CmsAdmin or CmsContent - these are reserved for the CMS.
Any widget that is using controllers should hook into the interfaces assembly and base class their public widgets and admin widgets from the base classes found there. Also, should base class the Areas config so as to bring the widget's paths into scope. the admin base class will also let you work within an independent project and not have to have security set up, but will trigger security when integrated with the CMS. Thank you controller factory!
Any views for a controller based widget (public or admin) should be located in \views\<<assembly file name>>\<<controller name>>
Within the \views\<<assembly file name>>\ path, place the admin and public config files so that the items can be added to the relevant editor menus (drag drop toolbox for public and the widget module menu in admin)