On Wed, Sep 11, 2013 at 4:07 AM, Juan Pedro Gonzalez
<unaputacue...@hotmail.com> wrote:
> In a previous post I talked about the development of a theme manager. Talking
> with Demian he posted a link to VuFind theme system where he uses a specific
> folder that holds the views for every module view instead of holding the
> theme files for a specific module inside that module. I'm trying to make the
> system as flexible as possible and was worried about posible collisions and
> have been reading more and more code... now I've gotten to a point I think I
> understand a little better how views work, but I guess I've gone a little
> mad, so I wanted to check with someone.
> Right now I think the view is loaded through a RouteMatch, that is, if I've
> got a static route called 'assets' and I call a controller in that route the
> resulting template will be 'routename/controllername/actionname' for example
> 'assets/css/index.phtml' (Calling the 'assets' route, 'css' controller,
> 'index' action. Is that correct?
No, actually. The template _name_:
{normalized-module-name}/{normalized-controller-name}/{normalized-action-name}
The route name is not considered at all. Additionally, this is only
true if you rely on the framework to inject a template name for you;
if you specify the template name in your view model, that name will be
used.
Also, note that this is a template _name_; how it is resolved is up to
you. By default, we resolve it via an Aggregate resolver that composes
a TemplateMap and TemplatePathStack resolver, with the TemplateMap
taking precedence. The resolver determines the actual view script to
use, including the file suffix.
> If this is the way it works there would be not much of a diference if the
> views are stored outside or inside the module.
This, however, is correct. Because of the way configuration merging
works, you should be able to map the template to a view script however
you want. We encourage the idea of keeping your templates in the
module that consumes them -- which means if one module wants a
different template then the module it is extending, it should keep
that new version itself, and simply override the location.
> This takes me to a second question: can I set a hook to an event when the
> module has loaded the template_path_stack configuration? My goal here would
> be to check if a module has a module-specific theme folder, and, if it does,
> override the template_path_stack with the theme folder. I know I could do
> this creating an abstract class or a new Feature for the module, but if
> possible I would like to make it as seamless as possible... else I'll add a
> getThemeFolder() in a Feature.
I would do this during the (as of 2.2.0 and up)
Zend\ModuleManager\ModuleEvent::EVENT_MERGE_CONFIG event. At that
point, you can grab the merged configuration, analyze it, make changes
if necessary, and then push it back into the configuration listener:
public function onMergeConfig($e)
{
$configListener = $e->getConfigListener();
if (!$configListener instanceof
\Zend\ModuleManager\Listener\ConfigListener) {
return;
}
$config = $configListener->getMergedConfig(false); // can't
recall why the false is necessary, but it is
// Analyze
// Make changes
// And then re-inject:
$configListener->setMergedConfig($config);
}
Attach the listener during via your module's init() method;
onBootstrap() is too late:
public function init($moduleManager)
{
$events = $moduleManager->getEventManager();
$events->attach(\Zend\ModuleManager\ModuleEvent::EVENT_MERGE_CONFIG,
array($this, 'onMergeConfig'));
}
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com
