Extended area routing search criteria for topics

JeremyCaney · JeremyCaney · commit 74a8a7658cef · 2020-08-17T16:03:37.000-07:00
Previously, the area routing that was built into the `Load(RouteData)` extension method was based on the assumption that the paths would have both an `{area}` and `{controller}` in them. That's sometimes true, and works for those situations.

But we also have scenarios where we implicit controllers, where the controller uses the same name as the area (e.g., `[Area("Forms")]`, `FormsController`). In these cases, we don't include the controller in the route—and thus shouldn't look for it in the topic path, either (i.e., it'll just be e.g., `/Forms/Request` not `/Forms/Forms/Request`).

This update extends those paths to include implicit controllers as a fallback path, to provide more flexibility over how routes are mapped to topics.

It's worth being aware that there is some room for ambiguity, thus yielding false positives in rare scenarios. For instance, if the user is routed to a `{area="", controller="Forms", action="Request"}`, and `/Forms/Request` doesn't exist, it will fallback to `/Request` based on `{area}/{action}/{path}`. If `/Request` exists, it will be returned. We expect that to be an edge case. In that rare situation, we'd expect there to likely be a mismatch between the false positive's content type and the view's content type, which would likely yield a different error. In very rare cases, it might actually render content in a different template. Given how unexpected this scenario is, however, we're keeping this route in for the sake of flexibility.

Finally, the `{area}/{path}` route will likely be redundant with `{rootTopic}/{path}`, as we should expect a `rootTopic` variable to be defined whenever defining a `{**path}` catch-all route for use with OnTopic. This is currently enforced by our `MapTopicRoute()` extension method, and will be added to future extension methods intended to better support areas. That said, having it as a fallback shouldn't hurt anything, and provides some forgiveness for areas that use manually defined routes and may forget to define `rootTopic`.

(This is fine as the only reason we use `rootTopic` is because we don't want a catch-all root for all root folders, as we don't want to misinterpret requests to e.g. `/Images` or `/Shared` as topic paths. But that's not an issue for areas, so an `area` and a `rootTopic` should always be the same.)
diff --git a/OnTopic.AspNetCore.Mvc/TopicRepositoryExtensions.cs b/OnTopic.AspNetCore.Mvc/TopicRepositoryExtensions.cs
@@ -67,6 +67,8 @@ RouteData routeData
         cleanPath($"{rootTopic}/{path}"),
         cleanPath($"{area}/{controller}/{action}/{path}"),
         cleanPath($"{area}/{controller}/{path}"),
+        cleanPath($"{area}/{action}/{path}"),
+        cleanPath($"{area}/{path}")
       };
 
       /*------------------------------------------------------------------------------------------------------------------------
