This service is intended to abstract permalink usage away and replaces the original
Permalink system integrated into the NAP system.
It is fully decoupled from NAP, so objects, which should be reachable by Permalinks
no longer need NAP entries. To make the transition to this service transparent, the
system still includes a NAP GUID reverse-lookup, for backwards compatibility.
The component interface is used to provide a selective way to resolve content objects
to their URLs, with some heuristics to speed up lookups if they can be mapped to a
The current Permalink implementation limits granularity to a GUID level -- permalinks
map object GUIDs to pages. If you have multiple pages showing the same object, you need
to decide which one you wish to have as permalink and provide that URL for resolution.
For the forward lookup, it is allowed to have multiple pages set the same permalink.
Permalinks are always of the form $midcom_root_page_prefix/midcom-permalink-$guid and will
redirect using a Location HTTP header. Since regular content pages are created, the result
will be cacheable using the content caching system. This obviously means, that if you
modify the permalink lookup rules, you have to invalidate all guids that affected by the
changes. MidCOM will assume that the resolution of Permalinks to real URLs is stable over
time otherwise. You can also set the no_cache flag during the resolver callback execution
if you discover that it is a URL you are responsible for but the result should not be
cached. See there for details.