Now, it would be good if 1) the implementation for these "url expansion mechanisms" were changeable and 2) that you could register own url-generators so, lets say ~/blog(id) or ~/news(id) would be recognized at runtime when pages are being served.
Especially point 2, would be the first step towards being able to let editors insert links via the Content Editor that points to datatypes just as easily as to pages and media. How? Because urls to pages and media is handled through the KeyTemplatedXhtmlRenderer-attribute which decorates the Type Interface. For a page it looks like this [KeyTemplatedXhtmlRenderer(XhtmlRenderingType.Embedable, "{label}")]
So you could have the same attribute on a News Type looking like this [KeyTemplatedXhtmlRenderer(XhtmlRenderingType.Embedable, "{label}")] and voila.
Comments: ** Comment from web user: napernik **
@burningice this one is rather a simple and straightforward request.
One would be able to implement and register the following interface.
The default behavior for "/page(...)" and "/media(..)" can be overwritten as well.
namespace Composite.Core.Routing
{
/// <summary>
/// An interface for internal url transformation.
/// </summary>
public interface IInternalUrlConverter
{
/// <summary>
/// Contains an enumeration of url prefixes for urls current convert is handling
/// </summary>
IEnumerable<string> AcceptedUrlPrefixes { get; }
/// <summary>
/// Converts a url in an internal format (f.e. "~/page(guid)" or "~/media(guid)") to a public serveable url (f.e. "/page/subpage").
/// </summary>
/// <param name="internalUrl">An internal url.</param>
/// <param name="urlSpace">The target url space.</param>
/// <returns></returns>
string Convert(string internalUrl, UrlSpace urlSpace);
}
}
....
InternalUrls.Register(new CustomInternalUrlConverter("test", testDataType));
// CustomInternalUrlConverter - a short example that will be documented.