Same Url pattern for multiple types

When you add a DataRoute to the routing table, it might appear that you could only have one type of content item returned for urls matching its url pattern.  However you can easily set up routing to potentially return several different types for the same url pattern thus:

routes.MapDataRoute<OwnProductContent>("products/{_0}", new { controller = "OwnProduct", action = "Index" });
routes.MapDataRoute<AffiliateProductContent>("products/{_0}", new { controller = "AffiliateProduct", action = "Index" });

What happens here is that if no content item of type OwnProductContent exists as indexed by the second part of the url, the first DataRoute falls through to the second, which then attempts to find an AffiliateProductContent at that url.

This can cause a problem in that normally the way to add a new content item is when logged in as an editor, to go to an unoccupied url and enter the relevant data.  As soon as it is saved, the new content items is created on that url.  However in this case, default behaviour will result in the new content item always being of AffiliateProductContent type, as this is the last route in the routing table.

This can be worked around easily by use of the special query string parameter $type.  When the value of $type is set to a content type name (it can include or omit the namespace), only routes of that content type will be matched.  So to create a new OwnProductContent at /products/our-special you would use the url

/products/out-special?$type=OwnProductContent.

Efficiency Considerations

When you set up a routing configuration like this, there is a potential significant efficiency penalty, because it requires Lynicon to send a request to the Data API for each of the potential types which may exist on the matched url.  This can be mitigated in the case where there is caching of summaries by setting the static TypeCheckExistenceBySummary property on DataRoute type. This is a Func<Type, bool> which tells the DataRoute infrastructure whether it should check for the existence of a given type by requesting its summary rather than the full record.