[TYPO3-50-general] Routing and SubPackages
Bastian Waidelich
bastian at typo3.org
Mon Jan 5 12:20:16 CET 2009
Hi there,
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
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?). But IMHO the Router should resolve the full
name, not the request object.
Any objections, ideas, excitation, bashing?
Bastian
--
* 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?
More information about the TYPO3-project-5_0-general
mailing list