Unlock RCL's potential by making view mapping extensible

[troyji]

RCLs bring to the table a long sought-after set of functionality - a simple way to bundle views into sharable libraries. This functionality provides a way to simply implement complex application hierarchies that have been challenging to pull off in MVC in the past. Unfortunately, the current MVC implementation dramatically narrows the potential use cases through its assumptions about the view hierarchy across view assemblies.

Today, MVC assumes that view paths are unique across the main application and all of its referenced RCLs. When searching for a view, view priority is determined by searching the view assemblies in sequence and returns the first view that matches the requested path. The view assembly for the main application is always searched first.

Here are some of the characteristics that are enforced through this assumption:

• The main application will always override views from the RCLs. You cannot choose to override a view in the main application with a view in the RCL.
• The priority order between RCLs is arbitrary. There is no way to control this.
• RCLs must be coordinated with the main application to make sure there are no path conflicts. This limits the share-ability of RCLs. For example, the standard approach is to have RCLs follow the Areas convention such that each RCL falls within its own area: /Areas/<RCL_Area>/Views/. This is an unreasonable assumption for a publicly shared RCL.
• Controllers must be able to generate the unique view path required to find the correct view among all of the RCLs.

These assumptions are too restrictive for many desired applications of RCLs. For example, let's suppose you want to leverage RCLs to for a multi-tenant application with the following characteristics:

• The main application will host the default views to be used by all tenants.
• Tenants may override assets from the default application. Each tenant will have their own RCL with their view overrides.
• When a controller requests a view, the view from the tenant RCL of the active tenant will be returned. If no override exists, the view from the application defaults should be returned.

To achieve this today, you might try to override all of the MVC components that depend on the view hierarchy assumption. One path forward would be:

• For each precompiled view, capture the tenant context associated with it's originating RCL during startup.
• If runtime compilation is enabled, capture the tenant associated with each project file provider during startup.
• When a controller requests a view path, prepend the active tenant name.
• During view selection in the view compiler, filter the set of precompiled views by their tenant context before searching by view path.
• If runtime compilation is enabled, filter the project file system by tenant before searching by view path.
• If the view is not found under the tenant context, search within the default views.

To implement this, you would minimally need to create custom implementations of IViewLocationExpander, IViewCompilerProvider, IViewCompiler, RazorCompiledItem, and IFileProvider. This level of override is complex and not well supported today (because of rampant internal modifiers).

I would like to see view selection logic become extensible. The main application should be allowed to filter which view assemblies are searched during each request based on the application's state. In the same way that MVC provides a robust routing system for URI -> Controller Action mapping, we need a similarly robust routing system for View Path -> Compiled View mappings now.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[troyji]

Here is a quick rundown of routines that need to be manipulated to gain control over view routing.

Default View Compiler

When using the DefaultViewCompiler, all views are sourced from pre-compiled views. In this basic case, you need control of the following mechanisms:

Request View Context
When a view is requested (e.g. from a controller action), some view context needs to be supplied in addition to the view identifier.

• As a workaround today, you can implement an IViewLocationExpander to inject a stringified view context into the view identifier that the engine can later parse back out during routing: /{View Context}/{View Identifier}.
  • Example: Assume standard controller/action view path construction is used. Given a view context of FeatureA, controller Home and action Index, start with a normal view identifier of /Views/Home/Index.cshtml and then inject the view context to create the final view identifier of /FeatureA/Views/Home/Index.cshtml.
  • Note that you can also handle fallback hierarchies here by providing a list of view locations to search in order of priority such that each view location supplies a different combination of view context / view identifier pairs. The expander can be implemented to be triggered for each request if needed, allowing you to create an appropriate fallback sequence for the current application state.

Preserve All Compiled Views
When a view compiler is constructed, it is provided with a list of precompiled views. It assumes the identifier of each compiled view represents a relative path in a file hierarchy that is shared across all compiled views in all view assemblies. Therefore, it only keeps the first compiled item encountered for each identifier. Instead, we need to keep all compiled views no matter the identifier. It should be left up to the view routing logic to figure out which compiled view to use for each request.

• This assumption that the identifier is a relative path begins when the RazorCompiledItemFeatureProvider converts RazorCompiledItems into CompiledViewDescriptors where the RazorCompiledItem.Identifier is assigned to CompiledViewDescriptor.RelativePath.
• Note that it is convenient at this point to go ahead and pre-generate any relevant metadata for each compiled view that can later be used to filter compiled views based on requested view contexts.
  • Example: The user may have attached a custom assembly attribute to each assembly that specifies what feature the compiled views are for, assembly:Feature("FeatureA"). We might go ahead and capture these values now instead of having to do it again on each request.

View Routing
When a view is requested during IViewCompiler.CompileAsync(string relativePath), today the first compiled item whose identifier matches the requested relative path is returned. Instead, the user should request some view identifier for some view context. First, the context would be used to filter down to the subset of compiled views to be searched. Secondly, the first compiled view within the subset that matches the view identifier would be returned.

• Example: Assuming we injected the context information into the relative path as outlined above and have captured metadata for each compiled view as outlined above:
  1. The given relative path of /FeatureA/Views/Home/Index.cshtml would be parsed into a view context of FeatureA and a view identifier of /Views/Home/Index.cshtml.
  2. The compiled views would be filtered to the subset of views that came from assemblies tagged as FeatureA.
  3. The first compiled view in the FeatureA subset whose identifier matches /Views/Home/Index.cshtml will be returned.

Runtime View Compiler

When runtime compilation is configured, activating the RuntimeViewCompiler in place of the DefaultViewCompiler, views on the filesystem are recompiled if an associated pre-compiled view is stale or does not exist. In this scenario, you must also control the following mechanisms:

File Providers
As usual, you must explicitly configure file providers for each assembly in Startup.ConfigureServices using a call to AddRazorRuntimeCompilation. However, these file providers end up getting aggregated inside of a CompositeFileProvider inside of RuntimeCompilationFileProvider.FileProvider. The composite file provider treats the individual file providers as if they all share the same root file hierarchy. Given a relative path to a view, it will return the first view from the first file provider that has a file at the given path. Instead, we need to first filter which file providers should be searched based on the view context requested.

• As a workaround today, you can implement a custom IFileProvider that aggregates the assemblies and performs the desired routing logic. Instead of registering a file provider for each assembly, you register your one aggregate file provider. The custom aggregate file provider will still ultimately get wrapped by a CompositeFileProvider, but it will be the only one in there, giving the custom provider full control.
  • In your implementation of IFileProvider, the methods GetFileInfo, GetDirectoryContents, and Watch each perform the following filtering logic first:
    1. The given subpath of /FeatureA/Views/Home/Index.cshtml would be parsed into a view context of FeatureA and a view identifier of /Views/Home/Index.cshtml.
    2. The assembly file providers would be filtered to the subset of providers that came from assemblies that provide views for FeatureA.
    3. The first provider in the FeatureA subset that contains a view at the path that matches /Views/Home/Index.cshtml will get its file info returned.
  • Note that when registering each assembly file provider, it is convenient at that point to go ahead and pre-generate any relevant metadata for each one that can later be used for filtering them based on requested view contexts. For example: aggregatePrivider.AddAssemblyProvider("FeatureA", new PhysicalFileProvider("...")).

Checksum Watching
With runtime compilation, expiration tokens are generated for each compiled view that will trigger a recompilation if any files used to compile that view are changed. These are created with a call to the file provider's Watch method. The list of relevant files are established by enumerating the compiled item's checksum metadata. The checksum metadata is surfaced through the RazorSourceChecksumAttribute implementation of IRazorSourceChecksumMetadata. The relative paths of the views are taken directly from IRazorSourceChecksumMetadata.Identifier. A problem emerges here because the identifiers in the checksum metadata do not have the view context of the request injected, which our modified Watch method assumes is present. Furthermore, the context would not necessarily lead us to the one correct file provider for the item. Therefore, we must reconcile which file provider is the correct one for each checksum identifier in some way.

• As a workaround today, you can convert each RazorCompiledItem with a custom implementation that overrides RazorCompiledItem.Metadata to return metadata with modified 'Identifier' values that have the appropriate view context injected.

Important observations

• Since compiled views are the default mechanism for sourcing views in the framework now, the assumption that a view is identified by a relative path is faulty. A view's identifier should be treated as an arbitrary identifier within a collection (i.e. assembly). There should be some other means to map view identifiers into relative paths only when runtime compilation is used. It is fair to require the user to participate in this mapping if they are using non-standard identifiers.
• Two compiled views with the same identifier should not be assumed to be equivalent or swappable if they come from different assemblies. Some configurable view router should make those decisions, instead.
• It is clear that an IViewCompiler is really used as a view router. A view compiler may coincidentally need to perform compilation, but not necessarily. In the case of the DefaultViewCompiler where all views have been pre-compiled, there is no compilation at all. Split IViewCompiler out into view selection and view compilation #26901
• Checksum metadata does not sufficiently identify the origin of the view dependency. The only information available about the origin is the relative path (stored in the Identifier) of the view within the origin. IRazorSourceChecksumMetadata and the RuntimeViewCompiler #27139
• Inclusion rules for _ViewStart.cshtml and _ViewImports.cshtml need to be considered. When an RCL has components that are meant to be isolated to their own scope, these files should not necessarily 'bleed' over from other RCLs or from the main application. There probably needs to be some way to configure this behavior for each RCL your application references. Faulty _ViewStart.cshtml loading for RCL views #27188