>

> > Since it seems like all defined namespaces in the route config must end
> > with \Controller, I'm wondering if deriveControllerSubNamespace should
> just
> > remove the term Controller from the end of $namespace and then just
> remove
> > the first segment of the namespace (i.e the module name)?
>
> That's not a safe assumption.
>


Actually at the time, I was forgetting to update the controllers invokables
config, so yes it is not necessary to Controller at the end or at all.



>
> If I don't have many controllers, or many classes for that matter, I
> will often flatten my directory structure. As such, I might not have a
> "\Controller" subnamespace. And we make no requirements about
> appending the word "Controller" to the class, either. I've also seen
> people group a controller and its dependencies in a subnamespace
> without using a subnamespaced-module. The point is: we don't make many
> assumptions about how the code inside a module is structured -- and
> imposing something like what you're wanting would break code for a lot
> of folks.
>
>

The problem I ran into is because there _are_ assumptions being made as
specified by the code comment:

// Remove the first two elements representing the module and controller
directory.


Two things are happening prior to deriveControllerSubNamespace being called:

$module  = $this->deriveModuleNamespace($controller);
$namespace = $routeMatch->getParam(ModuleRouteListener::MODULE_NAMESPACE)

If the routing config specifies a namespace, then
deriveControllerSubNamespace is called. $module is then prepended to the
subnamespace if the derive method determines that one exists otherwise
$module is set with the entire rout config $namespace value.


Actually just now I changed the Controller namespace to Controllerx and
with the change I made it still fell into what I would of expectated:

Without the change the template path resolves to:

application/controllerx/index/index

With the change it resolves to

application/admin/controllerx/index/index


The reason why I find this desirable, is that there is only one template
stack path for all my sub-namespaces, as well as being PSR-0 compliant.



>
> In the meantime, you could create a controller or module-specific
> listener for injecting the view template name.
>


I realized that yesterday, but in this case its not desirable to overriding
it like that. It means deviating away from the standard documentation, it
would be preferred to pull the listener to use from the service config etc,
and also using a custom override could break it for other modules as you
noted.




-- 
Greg

Reply via email to