Feature/#6441 prefix path resolver #6963
Conversation
| * @param ServiceLocatorInterface $serviceLocator | ||
| * @return PrefixPathStackResolver | ||
| */ | ||
| public function createService(ServiceLocatorInterface $serviceLocator) |
There was a problem hiding this comment.
Suppose, I have something like this:
// in module/module.config.php
return [
'view_manager' => [
'default_template_suffix' => 'php',
]
];So, I have defined default template prefix as 'php' but this only works for TemplatePathStack resolver and does not work for PrefixPathStackResolver. IMO this is inconsistency.
There was a problem hiding this comment.
default_template_suffix is not supported anymore: if you need to customize the suffixes, you can pass in a custom resolver instance for a particular prefix. I think it's a decent tradeoff and it reduced coupling between this resolver and the TemplatePathStack
… to the correct location
…untime mutable state changes
…on flags, as safe defaults are sufficient for a default implementation
…on flag from constructor calls
…` constructor arg: relevant only for custom implementations
…defaultSuffix` parameter
… API (`set`, `add`, `setTemplatePathStackResolver`, `getTemplatePathStackResolver`)
…ck` instances in the `PrefixPathStackResolver`
…assed to the `PrefixPathStackResolver` directly with the prefixes
…solverInterface` instances assigned to some prefixes
…the build crash
Ocramius
force-pushed
the
feature/#6441-prefix-path-resolver
branch
from
ab066fa to
d25bc94
Compare
|
@ojhaujjwal any more remarks? Do you agree or disagree with the changes introduced here? I realize it looks quite different from what you had in mind in the first shot... |
|
I am ok with both the implementations. I would love to hear comments from others on these 2 PRs. |
…lver Feature/#6441 prefix path resolver
…ture/zendframework/zendframework#6441-prefix-path-resolver Feature/zendframework/zendframework#6441 prefix path resolver
Ping @ojhaujjwal
This is a rewrite of #6441