Registration and handling of multi-segment wild card routes #50

[pdbreen]

This PR supports routes of /{topic}/{series?}/{post?} and /{page}/{childPage?}/{grandChildPage?}, but routes with no fixed segment to match on requires the route pattern to be "last" so it doesn't steal routes from other controllers. Unfortunately, Nova makes being "last" much more complicated because it internally defers registration of the NovaServiceProvider until the ServeNova middleware detects that the request is actually a Nova request. As a result, this package must:

• defer its own route registration for Nova requests until Nova is booted. This is done using Nova::booted(..) registration
• if the route is not a Nova request, then Nova is never booted, so routes need to be registered without waiting on Nova. To make this happen, a ServeBlog middleware is pushed on the stack that extends ServeNova to register the wildcard route if the request is not for Nova.

As a result of this deferred registration, this blog route will never be cached - it will always be dynamically registered at some appropriate point in the provider boot cycle after request processing has initiated.

Next, the 2 desired routes for this package for page and posts are also identical. This is solved by registering a single generic route - /{slug1}/{slug2?}/{slug3?} - which is handled by a new,BlogController` that does not rely on model binding. Instead, the blog controller detects if the first segment matches a topic - if yes, it parses any remaining segments as series and posts and dispatches to the appropriate Topic, Series or Post controller based on the number of segments. If the first segment is NOT a topic, then the route is treated as a page path, with the remaining segments treated as child and grand child. Failure to resolve to a valid topic or page route for the number of segments provided results in a 404.

NOTE: Only "leaf" pages are considered valid paths. For example, if there is a "parent" page with a "child" page (no grand child), then the only valid route is /page/child - /page by itself will 404. If later the child has a "grand-child", then only /page/child/grand-child is valid - the /page/child route will now 404.

[pdbreen]

@drewroberts Nova forces route registration to be dynamic to ensure its always last. Much more fragile code (things happen differently based on whether the request is nova or not), but - no need to register the route manually in the app after all.

[drewroberts]

Can you also add an exception for /admin along with /nova to pass to those routes?

Is there a way we can add other reserved namespaces in the Page model?

[pdbreen]

I don't understand the request. By being last route registered, Nova routes (and all other routes) will have priority in matching (unit tests for Nova actually require this). If there is a page (or topic) with a slug of "nova" or "admin", the page (or topic) just won't be accessible - the nova route will be rendered instead. Really no need to prevent it -- not being accessible should be incentive enough to get someone to fix it.

[drewroberts]

OK, that makes sense. I looked at your code on how the Nova routes were registered. I like it.