Architecture

Overview about the node routing process and URL generation, with extension points

#Incoming direction: URL to NodeAddress

This is usually simply triggered once per request, before the controller starts working.

#Multi-Site and Multiple Content Repository support via SiteDetectionMiddleware

The Dimension Resolving configuration might be site-specific, f.e. one site maps a subdomain to a different language; and another site which wants to use the UriPathSegment.

Additionally, we want to support using different content repositories for different sites, e.g. to have different NodeTypes configured, or differing dimension configuration.

Thus, the frontend routing needs the result of the site detection as input. Site detection is done before the routing; inside the SiteDetectionMiddleware.

Feel free to replace the Site Detection with your own custom Middleware (it's very little code).

The Site Detection is done at every request.

#Custom Dimension Resolving via DimensionResolverInterface

Especially the DimensionSpacePoint matching must be very extensible, because people might want to map domains, subdomains, URL slugs, ... to different dimensions; and maybe even handle every dimension individually.

This is why the EventSourcedFrontendNodeRoutePartHandler calls the DelegatingResolver, which calls potentially multiple DimensionResolverInterfaces.

See Configuring Dimension Resolving and Custom DimensionResolvers in PHP for details on how to customize the Dimension Resolving.

Because the Dimension Resolving runs inside the RoutePartHandler, this is all cached (via the Routing Cache).

#Reading the Uri Path Segment and finding the node

This is implemented in EventSourcedFrontendNodeRoutePartHandler, and is not extensible.

#Routing result

The result of the routing call is a NodeAddress, containing:

the WorkspaceName (which is always live in our case)
the ContentStreamId of the live workspace
The DimensionSpacePoint we want to see the page in (i.e. in language=de), as resolved by DimensionResolverInterface.
The NodeAggregateId of the Document Node we want to show, as resolved by EventSourcedFrontendNodeRoutePartHandler

#Generating links: NodeAddress to URL

First, the URL path is resolved for the Node (by checking the DocumentUriPathFinder projection).

Then, the CrossSiteLinkerInterface is responsible for adjusting the built URL in case it needs to be generated for a different Site. It is a global singleton, but can be replaced globally if needed, as it is a planned extension point.

Last, the DimensionResolverInterface of the target site is called for adjusting the URL to account for dimensions.