Also, would make config files easier to read (less paths to final config, as news.resources...........)
So, we have:
1. Global settings in /application/configs/configs.ini /xml /...........
2. Global (application bootstrap) on /application/Bootstrap.php
3. Module config should be /application/modules/blog/configs/configs.ini / xml /......... So i think would be fairly easy to do it like this instead of putting all configs into global configs folder... And we keep things modularized.... And by keeping the name "configs" instead of blog also i think things are easier....
4. Module Bootstrap in /application/modules/blog/Bootstrap.php
Also, i don't think default module should be involved at all, because really, it doesn't matter which is the default module...
Cristian
-- Cristian Bichis <contact@zftutorials.com> wrote (on Thursday, 09 April 2009, 09:24 PM +0300):I think yes, should be bootstrap at global level, and then each module should add his own bootstrap and settings at module level. This is offering the greatest flexibility too....BTW, this can work now, to a degree. setOptions() merges options at this time. That means you can override your module bootstrap's constructor, and do something like this: class Blog_Bootstrap extends Zend_Application_Module_Bootstrap { public function __construct($application) { parent::__construct(); $configFile = dirname(__FILE__) . '/configs/blog.ini'; if (Zend_Loader::isReadable($configFile)) { $config = new Zend_Config_Ini($configFile, $this->getEnvironment()); $this->setOptions($config->toArray()); } } } The question I have is: should the above be automated? The problematic part of this is that users may select different configuration types (php, xml, ini) -- which can lead to some potentially expensive lookups (especially if there is _no_ config file at all..). That said, I think it would be fairly easy to implement. The rules would be as follows: * config filenames would be named after the module, all lowercase * valid config file extensions would include .ini, .xml, .php, or .inc * config file loading would happen after passing any options from the calling bootstrap (which gives both global with local overrides). If this sounds like a good solution, I'll start working on that immediately. Thanks already for the feedback -- this discussion has been fruitful already!2009/4/9 Matthew Weier O'Phinney <matthew@zend.com>: One idea we have tossed around is that modules would be responsible for loading their own configuration. The question is whether we should automate that, or whether it's the responsibility of the developer when they write their module bootstrap. Thoughts? I dont quite understand what you mean, however I will say that when first using the modules resource, I assumed that it would work like: bootstrap <- Main Bootstrap modules default bootstrap m1 bootstrap So you would have global resources, front controller etc in main bootstrap and then module specific in the others, I think Cristian made the same assumption. Do you mean to have say separate config files for each module? -- Best regards, Cristian Bichis www.zftutorials.com | www.zfforums.com | www.zftalk.com | www.zflinks.com
-- Best regards, Cristian Bichis www.zftutorials.com | www.zfforums.com | www.zftalk.com | www.zflinks.com
没有评论:
发表评论