[TYPO3-50-general] Routing and SubPackages

[Robert Lemke]

Hi Bastian,

Am 05.01.2009 um 12:20 schrieb Bastian Waidelich:

> We've (had?) a problem with ambiguity of Routes when generating URIs
> using the uriHelper/linkHelper of FLOW3:
>
> Imagine the following two simple Routes:
>
> Costumers_Route:
>   uriPattern: 'customers/[@action]'
>   controllerObjectNamePattern:
> 'F3\@package\Frontend\Controller\@controllerController'
>   defaults:
>     @package:    MyPackage1
>     @controller: Default
>
> CostumersAdministration_Route:
>   uriPattern: 'customers/admin/[@action]'
>   controllerObjectNamePattern:
> 'F3\@package\Administration\Controller\@controllerController'
>   defaults:
>     @package:    MyPackage1
>     @controller: Default

BTW, what's the deal with the "Costumers_Route"? Is it affiliated with
the Costumers Guild? http://www.costume.org/

> Now, when using FLOW3s URIHelper to generate a proper link:
> $uriHelper->URIFor('list', array(), 'Default');
> FLOW3 can't explicitly resolve the matching Route because both Routes
> would match. In this case, the resulting URI would always be
> 'customers/admin/list' because the last Route has the highest  
> priority*.
>
> Our first idea was to check whether a specific controller and action
> exists.. But that would lead to a lot of dependencies. Furthermore the
> same action could exist in two correspondent Controllers obviously.
>
> Other frameworks solve this by allowing to specify the Route name when
> generating the URIs (namely e.g. Zend Framework does so). But IMO this
> is a smelly solution as it leads to unwanted dependencies too.
>
> We think, this problem occurs only when calling Controllers of
> SubPackages, so the solution Sebastian and me came up with this  
> morning
> was, to include @subpackage to the Route definition. The example from
> above would look like this then:
>
>
> Costumers_Route:
>   uriPattern: 'customers/[@action]'
>   controllerObjectNamePattern:
> 'F3\@package\Frontend\Controller\@controllerController'
>   defaults:
>     @package:    MyPackage1
>     @subpackage: Frontend
>     @controller: Default
>
> CostumersAdministration_Route:
>   uriPattern: 'customers/admin/[@action]'
>   controllerObjectNamePattern:
> 'F3\@package\Administration\Controller\@controllerController'
>   defaults:
>     @package:    MyPackage1
>     @subpackage: Administration
>     @controller: Default
>
> $uriHelper->URIFor('list', array(), 'Default', 'Frontend');
>
> see?
>
> The good news:
> "controllerObjectNamePattern" & "viewObjectNamePattern" wouldn't be
> needed anymore if we'd agree on a standard naming like:
>
> Classes
>   SubPackage1
>     Controller
>     View
>   SubPackage2
>     Controller
>     View
>
> (in the current distributions this is the case already IIRC)
>
>
> Currently \F3\FLOW3\MVC\Request resolves the fully qualified
> controller/view name which isn't really the job of a request object.
> Instead of the methods setControllerObjectNamePattern() and
> setViewObjectNamePattern() we could have
> setFullyQualifiedControllerName() or something like this.
> The full view name does not have to be specified if it is consistent
> with the defaults (otherwise it could be overwritten by the  
> controller,
> right?).
>
> We could still use controllerObjectNamePattern in the Routes to allow
> exceptions (should we?).

No, please not (until we really need it).

> But IMHO the Router should resolve the full
> name, not the request object.

yes.

All in all: +1, go for it!

> * Currently Routes are processed in _descending_ order as I thought  
> you
> would add more specific Routes to the end of Routes.yaml by default..
> But this seems to be confusing to some users and we might change the
> behavior so that the _first_ Route has the highest priority. What do  
> you
> think?

Without thinking, to me it's more intuitive if the last route has higher
priority - that's what I'm used from programming:

$foo = 'bar';
$foo = 'baz';

I'd be surprised if $foo was 'bar'.

On the other hand configuration files like mod_rewrite rules are read  
from
top to bottom.

Plus our configuration is not linear - it is clear that configuration  
files
from different parts are merged at some point and YAML also works taht  
way.
IMO that speaks for rather in favor of the descending order.

Cheers,
robert