[TYPO3-mvc] RFC #8344: Default controller should be removed from generated link in UriBuilder

Franz Koch typo3.RemoveForMessage at elements-net.de
Thu Jun 24 22:11:42 CEST 2010


Hey there,

> Of course, I think it makes sense to strip the controller from the URI
> if it is the default controller. So, instead of removing the two lines
> in the patch, one would need an additional condition which checks if the
> resolved controller is the default controller in the current plugin, and
> then removes the "controller" argument.

On my first extbase project I faced the very same problem and used my 
own viewHelper/UriBuilder construct for that. Back then I went that way, 
that if it's a link to the current controller on the current page, the 
default controller can be removed securely from the URL. As soon as it's 
a link to a action on a different page, the controller is added by 
default again, because we can't be sure if it's the default controller 
there too.
This would be the safest solution I think - but then again, if one is 
having the same plugin/controller pair on the other page, he should 
still be able to remove the controller from the URI. In those cases it 
could be achieved by setting it's value to empty in the linkViewhelper 
(this doesn't work currently as expected, because the piVar is still 
added to the URI but with a empty value though).

How about that? But I'm also fine with removing the default controller 
in general.



For even more complex scenarios (which my first extension has been) we 
could go even a step further, by completely removing the controller in 
URLs and bind certain controller names to getVars. Example:

- only a category getVar in the URL -> then it's the categoryController
- category + product in the URL -> productController

This will come handy e.g. for shops etc, where the very same page has to 
deliver content from several controllers in order to get nice looking 
URIs. Currently I achieve this by using hooks in TYPO3/realurl to 
manipulate the URLs and readd the controller piVar in a very early stage 
of page rendering in order to get a valid cHash (was quite hard to 
achieve though).

-- 
kind regards,
Franz Koch


More information about the TYPO3-project-typo3v4mvc mailing list