Work Package #45217: [WIP][Assignee missing] External & internal link support
Media/Scheme aware URL handler
At least as soon as editors should be able to link arbitrary elements via Neos, it comes up that the various target possibilities are currently hard to distinct. In Flow and Neos, there are resources, there are (controller-) actions, there are nodes, and of course there is still the need to link to a typical URL like http:// and mailto:.
Especially the Resource, Action and Node links will result in a different "output" then their meaning representation; a Resource is a hash, resulting in the frontend-published URI; an action consists of package, controller, action, argument.. values, resulting in an URI-builder-built url.
And the node is represented by its path or identifier, resulting also in a web-accessible http url.
So, see the following examples:
node:///sites/exampleorg/home/welcome/some/section/with/stuffCould even result into http://example.org/home/welcome.html#somesectionwithstuff
resource:///348fb109a2098234b23498Would result into the frontend-published resource
media-resource:///348fb109a2098234b23498?width=500&height=800Would provide a scaled image
This is what just came in my mind and of course these are just suggestions and need to be checked
against current requirements...
Basic implementation idea¶
For implementing kind of this, I'm thinking about a service, where various schema implementers can hook in. Neos, for example, would then bring its own NodeSchemaImplementer (?), TYPO3.Media could provide an implementor which allows also scaling an (image) resource (like IMG_RESOURCE).
Flow on it's very own of course brings an MvcActionSchemaImplementer (?) (I'm just throwing around with name suggestions which helps me to understand what I mean ;)
I think these schemas schouldn't have anything to do with the StreamWrapper because that's more an internal PHP thing. "Our" schema here is "just" a naming convention to transpose a stringly given resource locator to its actual representation.
Locate TYPO3CR nodes¶
Since nodes can be moved around, it sounds making sense to use the node identifier. However, as far as I got it, the node identifier can be pretty "volatile" in regards of workspaces, etc.
But still, in order to be able to keep old "links" updated in case their nodes are moved around, their paths would need to be updated. This could only be done by something like a Refindex, and is likely also not very nice... What do you think on the long run?
Updated by Adrian Föder over 8 years ago
What do you think about registering an appropriate scheme at the IANA, a so called "Provisional URI Scheme" (see http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml).
The scheme is the very first part of an URI, for example in mailto:email@example.com or svn://something, the "mailto" and "svn" are the schemes.
With introducing a broader user circle, that scheme name could even be "typo3", with various defined sub namespaces then, just like "typo3:cr:node:/sites/exampleorg/home/welcome".
Just a basic idea, a "sub registration proces" could then be made on Association base.