As it is today, there are two built-in methods for handling url-generation based on datatype ids. One is the ~/page(id) and the other is ~/media(id), which will be expanded to human readable and SEO friendly urls at runtime/page generation.
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 **
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 **
Will be supported in the next release.