I tend to build sites now using a widget-based approach. Pretty much every page is built using Archetype widgets. That means there is really only one template that renders those widgets.

We have also used this technique for multiple sites that share that template. We were able to give each site a unique look by having the homepage node set a theme with a drop down property. Based on that theme, we attach some particular CSS classes and that gives us pretty much everything we need to make each site unique.

If you aren't using widgets, you can still get some reusability by using different templates, but have those different templates use shared partial views. For example, you could have Slideshow.cshtml, then you could call Html.Partial from each homepage variant to render the slideshow.

Another thing you could do is have each template use the same layout CSHTML files.

Sure. Take a look at this homepage: https://www.allcarehealth.com/

Currently, that page consists of this content (just a series of Archetype widgets in the "Main Content" property):

The homepage, like every page in the site, is just rendered by looping through the widgets and rendering them:

@using AllCare.App.Pages
@using AllCare.App.Utilities
@inherits Umbraco.Web.Mvc.UmbracoViewPage<TypicalPage>
@{
    Layout = "Wrapped.cshtml";
    var page = Model;
    var widgets = page.Typical.MainContent;
}

@section PageTitle{@page.SEO.Title}

@foreach (var widget in widgets)
{
    var view = WidgetUtility.GetView(widget);
    if (view != null)
    {
        @Html.Partial(view, widget)
    }
}

@Html.Partial("Quad Actions", page)

@Html.Partial("Disclaimer", page)

Here are some answers:

1. I don't usually hardcode anything. Although, I don't know what you mean by "would you recommend that every section be a property". Note that almost all of the content on the page is rendered with a single property (i.e., "Main Content").
2. No, you just use different widgets for each page. Archetype allows you to add any widget in any order (though, Archetype calls them "fieldsets").
3. I probably assigned the Model variable to the page variable for clarity. For example, I find page.SEO.Title to be easier to read than Model.SEO.Title. It has no impact functionally, but it makes the code more readable.
4. The page.Typical.MainContent property is of type IEnumerable<IWidget> (i.e., it is a collection of widgets for the page).
5. The GetView function only operates on one widget, not on a collection of widgets. The outer for loop is what decides the order to render widgets in (it just renders in the order specified in the CMS). So, GetView returns a path to a CSHTML file that can render a widget.
6. I keep quad actions and disclaimer outside of the main content because I do not consider them widgets. They exist on most every page, much like the header/footer. In other words, I don't find any value in making them composable elements.

FYI, it may not be obvious, but there is a controller/action method that maps Umbraco content to a model that is then supplied to the view.

Not sure I follow. If you want one site without a video, simply do not add that widget to the "Main Content" property. All of the widgets are controlled by the content editor.

Here's an example from the above website:

When I click any "+" button, I am presented with the dialog to add a widget (aka, fieldset). That would allow me to add a video widget to one of the homepages.

If I added the video widget to a page I didn't want to add it to, I'd click the "X" button on the widget to delete it. Note that Archetype also allows you to change the order of widgets by dragging them (you do that by clicking the crosshair button an dragging).

1. If you had a drop down on your homepages that allow the user to select a theme, you can do all sorts of things based on that selection. For example, you could include different CSS files based on the chosen theme. You could also accomplish it with a different template or layout, but that might necessitate having different templates set for each page within each site, which could be a pain (though, I can think of one way that would make it a bit easier, and I can explain it if you want to go that route).
2. In the example I gave, each widget has a CSHTML that allows it to render any arbitrary markup. Of course, that CSHTML file only controls that widget and not any sort of interaction between adjacent widgets. I tend to architect sites so that any widget can be next to any other widget, though that may not work very well if you don't start with a widget-based approach in mind. Not really sure what you are talking about with regard to the rich text editor. Perhaps the screenshot below that shows the expanded fieldset for the slideshow will help.
3. Yep, that's pretty much how I do it. We also created this project so when a user creates a page of a particular document type (e.g., Homepage), we can automatically create the widgets they are likely to need for that type of page: https://our.umbraco.org/projects/backoffice-extensions/contenttemplates/ Note that while we use different document types to facilitate that default widget behavior, they all still use the same template.

Yep, each widget has a CSHTML file that renders the widget in whatever way it decides is best. Actually, my newer approach is to just have each widget render itself, and I have most widgets inherit from a common base class that just generates an AngularJS directive that then decides what type of markup to use. However, if you aren't familiar with AngularJS, might be best to avoid that approach for now.

Keep in mind that WidgetUtility.GetView is just a function I wrote, so it really could do anything you want it to do. In my case, it uses a bit of reflection magic to figure out which CSHTML Razor partial to use. However, you could do it by convention if you liked (e.g., you could name each CSHTML partial after the widget). Here's my implementation if you are curious:

// Namespaces.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using Widgets;
using static System.Reflection.BindingFlags;
using static System.Type;


/// <summary>
/// Helps manage widgets.
/// </summary>
public static class WidgetUtility
{

    #region Properties

    /// <summary>
    /// Store the view paths by the widget type.
    /// </summary>
    private static Dictionary<Type, string> Paths { get; set; }


    /// <summary>
    /// A lock object to make the paths thread safe.
    /// </summary>
    private static object PathsLock { get; set; }


    /// <summary>
    /// Indicates whether or not the paths have been populated.
    /// </summary>
    private static bool PathsPopulated { get; set; }

    #endregion


    #region Constructors

    /// <summary>
    /// Static constructor.
    /// </summary>
    static WidgetUtility()
    {
        PathsLock = new object();
        PathsPopulated = false;
        Paths = new Dictionary<Type, string>();
    }

    #endregion


    #region Public Methods

    /// <summary>
    /// Gets the path to the view for the specified widget.
    /// </summary>
    /// <param name="widget">The widget to get the path for.</param>
    /// <returns>The view path, or null.</returns>
    public static string GetView(IWidget widget)
    {
        PopulateViews();
        var viewPath = default(string);
        return Paths.TryGetValue(widget.GetType(), out viewPath) ? viewPath : null;
    }

    #endregion


    #region Private Methods

    /// <summary>
    /// Populates the paths to the views for the widgets.
    /// </summary>
    /// <remarks>
    /// If the views have already been populated, this will return immediately.
    /// </remarks>
    private static void PopulateViews()
    {

        // Already done?
        if (PathsPopulated)
        {
            return;
        }


        // Get the paths.
        lock (PathsLock)
        {

            // Already done?
            if (PathsPopulated)
            {
                return;
            }


            // Create instances of the types that implement WidgetView.
            var emptyParams = new ParameterModifier[] { };
            var target = typeof(WidgetView<>);
            var baseTarget = typeof(WidgetView);
            var instances = AppDomain.CurrentDomain.GetAssemblies().SelectMany(x =>
                {
                    try
                    {
                        return x.GetTypes();
                    }
                    catch (ReflectionTypeLoadException ex)
                    {
                        return ex.Types.Where(y => y != null);
                    }
                });

            var widgetViews = instances
                // that implement WidgetView...
                .Where(x => baseTarget.IsAssignableFrom(x))
                // and have a generic base type...
                .Where(x => x.BaseType != null && x.BaseType.IsGenericType)
                // and are not abstract...
                .Where(x => !x.IsAbstract)
                // and implement WidgetView<> (generic version)...
                .Where(x => target.IsAssignableFrom(x.BaseType.GetGenericTypeDefinition()))
                // and have a public default constructor.
                .Where(x => x.GetConstructor(Instance | Public, null, EmptyTypes, emptyParams) != null)
                // Create instance.
                .Select(x => Activator.CreateInstance(x) as WidgetView)
                .Where(x => x != null).ToArray();


            // Store paths for each widget type.
            foreach (var widgetView in widgetViews)
            {
                var widgetType = widgetView.GetType().BaseType.GetGenericArguments().First();
                Paths[widgetType] = widgetView.ViewPath;
            }


            // Done.
            PathsPopulated = true;

        }

    }

    #endregion

}

For my slideshow, I have a class that indicates the path to be used as the partial view when rendering the slideshow:

/// <summary>
/// Registers the view for the slideshow widget.
/// </summary>
public class SlideshowView : WidgetView<Slideshow>
{
    public override string ViewPath => "~/Views/Partials/Widgets/Slideshow.cshtml";
}

Yes, the Slideshow.cshtml gets to decide how to render each slide. In my case, I'm just rendering it to JSON, then passing it to an AngularJS directive that then handles rendering each slide:

@using AllCare.App.Extensions
@using AllCare.App.Types
@model AllCare.App.Widgets.Slideshow
@{
    var source = Json.Encode(new
    {
        useSocialShare = Model.UseSocialShare,
        slides = Model.Slides.Select(x => x is Slide
            ? new
            {
                type = "slide-image",
                header = x.Header,
                summary = x.Summary,
                link = x.Link.GetAngularLink(),
                image = x.Image.GetAnonObject(),
                mobileImage = x.MobileImage != null ? x.MobileImage.GetAnonObject() : x.Image.GetAnonObject()
            } as object
            : new
            {
                type = "slide-video",
                header = x.Header,
                summary = x.Summary,
                link = x.Link.GetAngularLink(),
                image = x.Image.GetAnonObject(),
                mobileImage = x.MobileImage != null ? x.MobileImage.GetAnonObject() : x.Image.GetAnonObject(),
                youtubeId = (x as VideoSlide).YouTubeID
            } as object
        ).ToArray()
    });
}

<json-source source="@source" html-fields="slides.summary">
    <slideshow slides="::ctrl.slides" use-social-share="::ctrl.useSocialShare"></slideshow>
</json-source>

If you view the source of any page, you'll actually see these AngularJS directives and a bunch of JSON. Not that you need to do that; it's just how I've done it in this case. You could simply loop over each slide using a for loop in razor.

Not sure I follow exactly. However...

If you are thinking of actually adding a ViewPath property to the Archetype in the back office editor for Archetype, I wouldn't recommend that. That's typically used for data entered by content editors, and this isn't a property you'd want them tinkering with.

However, you could certainly create a base class, Widget, that all widgets inherit from. That base class could have a property or function that returns the view path. And widgets that implement it could override it if necessary.

The base implementation of ViewPath could return a path based on the name of the current widget class (e.g., if a class is called Slideshow, it could return a path of ~/Views/Partials/Widgets/Slideshow.cshtml).

I wouldn't recommend those unless you are fine with the convention it imposes. All it's really doing is figuring out a path and then, I suspect, calling Html.Partial for that path with the model. Should be easy enough to do that yourself.

When you say "menu items", is this for a primary navigation (e.g., that you'd normally see at the top of a website)? How different is the primary navigation on each site? Do you actually need to render something different with the markup?

If the markup and structure of the data is very different, you can allow the content editor to choose between multiple fieldsets (e.g., "Menu Type 1" or "Menu Type 2").

If it's just CSS that needs to differ, you can have a drop down to select a theme on each site's homepage, then adjust whatever you need to based on that theme selection.

And if somebody asks you to change a view path, you would likely actually be creating an entirely new view. In that case, of course there'd be some extra files to deploy (perhaps with some DLL's recompiled). Normally, content editors are not even aware of the concept of view paths though.

In that case, you could simply have a drop down for which type of menu to show. And that drop down could be on the homepage. Inside of menu.cshtml, you'd then have a call to one of your two sub-partials based on the value of that drop down.

That's assuming you keep your very much hardcoded menus, however. Ideally, content editors could construct these menus themselves by selecting various Archetype fieldsets for different types of menu items. In that case, you wouldn't need to make special menus for each site.

I would also question why you need specific ID's of "responsive-top-nav" and "responsive-top-nav-br". Is that something that could be handled with a theme class (e.g., the body could have a theme class of "theme-primary" or "theme-secondary" and you could style based on that). If not, I'd wonder what these two different ID's actually do. If one enables some extra behavior, perhaps that behavior could be triggered by the content editor selecting a checkbox (e.g., a checkbox that says "Do That One Special Thing?").

I don't have an IDE in front of me, but I'm thinking you are talking about passing a view data dictionary to a partial view. That could work, though you could equally well just pass a model to that partial view (unless you need to pass something else, like an IPublishedContent).

When to use archetype and when to not? Basically when is it overkill?

That depends on a lot of factors. If you don't need it and you don't think you will need it, don't use it, I suppose.

Could go either way. It is very much something used for the view, so it makes sense to pass it in a view-centric way.

You can create a special property editor that is editable only once. Archetype doesn't have anything built in for this.

I use Ditto and some Ditto Labs processors (not to mention a number of custom processors) to map Archetypes to POCOs: https://github.com/leekelleher/umbraco-ditto-labs/tree/32e797a056f31adc03eab0f2669061700fc2626c/src/Our.Umbraco.Ditto.Archetype/ComponentModel/Processors

is working on a reply...