> -- 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!
Could you have:
class Blog_Bootstrap extends Zend_Application_Module_Bootstrap
{
protected $_config = 'blog.ini';
}
Where if $_config is null no loading is done, else we get the options.
This way would we not lose the lookup cost? Also the db table classes
work in a similar way when you define table names so people should be
used to this convention.
Also I assume this would fix the problem of having to treat the
default module differently from the other modules?
Thx
Keith
>
>> 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
>>
>
> --
> Matthew Weier O'Phinney
> Software Architect | matthew@zend.com
> Zend Framework | http://framework.zend.com/
>
>
--
----------------------------------------------------------------------
[MuTe]
----------------------------------------------------------------------
没有评论:
发表评论