[TYPO3-team-core-v5] Multi purpose URL scheme for the Flow world

[Aske Ertmann]

Hello Adrian

There is actually a open work package for this http://forge.typo3.org/issues/45217

I like the approach you have, and one of the things I'm weary of is the usage of node paths for links since we use them to create our url's as well. I think we need to use the node identifier instead because otherwise we will end up with links breaking every time we move pages around. But I think both should be possible, although links inserted using the GUI should use the identifier instead. At least I think it will be very difficult to update all the occurrences of/relations to the node path once it changes. Same problem occurs when using TypoScript.

I agree that it shouldn't become a view helper, but rather a service since it needs to be accessible for multiple purposes and not just Fluid, which is why I also think it would be bad to mix it with TypoScript. I think it could be something like the link handler, which when implemented better could become as flexible as needed especially with the power of AOP. We should provide the most used variant, which would be advanced linking to nodes and plugin list support. And that should support node paths, relative node paths, node identifiers etc.

Would be great to come up with a concept that would work everywhere and also easy to understand. Also if it becomes a Flow feature, then the resource stuff would be implemented by Flow and the node protocol would just be an addition from Neos.

Aske

On Mar 21, 2013, at 9:05 PM, Bastian Waidelich <bastian at typo3.org> wrote:

> Adrian Föder wrote:
> 
> Hi Adrian,
> 
>> well, just see my last comment here, http://forge.typo3.org/issues/45973
>> It's about, if you like, a correctly implemented "typolink"
>> functionality ;)
> 
> 
> Just my 5 cent before closing time:
> I find your approach interesting and we already thought about adding more custom stream wrappers (e.g. for the resource collections Robert is currently working on).
> 
> Anyhow, I fear that we end up with s.th. like typolink (which is very flexible, but also very intransparent and hard to extend).
> 
> Instead of putting all this logic into a ViewHelper (and thus in a string that "configures" the ViewHelper) I'd prefer a more generic approach.
> Frankly I don't know how that could look like precisely but maybe it would be just a "Link" TypoScript Content Element that can be wrapped around arbitrary other CEs..
> 
> -- 
> Bastian Waidelich
> --
> Core Developer Team
> 
> TYPO3 .... inspiring people to share!
> Get involved: typo3.org
> _______________________________________________
> TYPO3-team-core-v5 mailing list
> TYPO3-team-core-v5 at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-team-core-v5