如何使用 application.ini 和 user.ini 设置 Zend_Application
我正在使用 Zend_Application,但在 application.ini 中混合应用程序和用户配置感觉不太好。
我的意思如下。例如,我的应用程序需要命名空间 MyApp_ 中的一些库类。所以在 application.ini 中我放置了 autoloaderNamespaces[] = "MyApp_"。这是纯粹的应用程序配置,除了程序员之外没有人会更改这些。另一方面,我在那里放置了一个数据库配置,这是系统管理员可以更改的。
我的想法是,我将在 application.ini 和 user.ini 之间拆分选项,其中 user.ini 中的选项优先(因此我可以在 application.ini 中定义标准值)。
这是个好主意吗?我怎样才能最好地实现这一点?我的想法是
- 扩展 Zend_Application 以获取多个配置文件
- 在我的 Bootstrap 中创建一个 init 函数加载 user.ini
- 解析我的 index.php 中的配置文件并将它们传递给 Zend_Application (听起来很难看)
我该怎么办?我希望拥有“最干净”的解决方案,为未来做好准备(较新的 ZF 版本,以及开发同一应用程序的其他开发人员)
I am using Zend_Application and it does not feel right that I am mixing in my application.ini both application and user configuration.
What I mean with this is the following. For example, my application needs some library classes in the namespace MyApp_ . So in application.ini I put autoloaderNamespaces[] = "MyApp_". This is pure application configuration, no-one except a programmer would change these. On the other hand I put there a database configuration, something that a SysAdmin would change.
My idea is that I would split options between an application.ini and an user.ini, where the options in user.ini take preference (so I can define standard values in application.ini).
Is this a good idea? How can I best implement this? The idea's I have are
- Extending Zend_Application to take multiple config files
- Making an init function in my Bootstrap loading the user.ini
- Parsing the config files in my index.php and pass these to Zend_Application (sounds ugly)
What shall I do? I would like to have the 'cleanest' solution, which is prepared for the future (newer ZF versions, and other developers working on the same app)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
我找到了这个问题的解决方案,该解决方案对于框架版本 1.10 来说可能是新的。创建 Zend Application 对象时,您可以在选项数组中传入合并在一起的 2 个配置文件路径:
I found a solution to this issue that may be new to framework version 1.10. When creating the Zend Application object, you can pass in 2 configuration file paths in the options array that get merged together:
你知道这会合并你想要的所有 inis 吗?
在应用程序.ini中
you know this will merge as much inis as you want?
in application.ini
这没有什么问题,我也做了类似的事情。我建议使用你的第二个选择。我只有一个 _initConfig() 方法,它负责使用 Zend_Config_Ini 加载用户配置。我不会扩展 Zend_App,这似乎有点多了。
编辑:
为了回应您的评论,您只需这样做:
因此,为了确保在数据库之前加载配置,您将拥有类似的内容:
无需使用 Zend_Registry,因为 Bootstrap _init 方法返回的任何内容都可以使用 getResource( )
There is nothing wrong with that, I do something similar. I suggest using your second choice. I just have an _initConfig() method that takes care of loading the user config using Zend_Config_Ini. I wouldn't extend Zend_App, that seems a bit much.
Edit:
In response to your comment, you would simply do:
Thus, to ensure config is loaded before DB, you'd have something like:
There is no need to use Zend_Registry as anything returned by a Bootstrap _init method is accessible using getResource()
配置文件可以有“config”项,它引用另一个配置文件。 Zend_Application 将包含此配置文件。包含的配置文件将具有优先权,并覆盖标准配置文件中已定义的键。
昨天,还在 Zend Framework 邮件列表
示例
application.ini:
config.ini:
public/index.php:
An configuration file can have the item 'config' which refers to another config file. Zend_Application will include this config file. The included config-file will have preference, and overwrite the keys already defined in the standard config-file.
Yesterday there was also started a thread on the Zend Framework mailing list
Examples
application.ini:
config.ini:
public/index.php:
在类似的场景中,我看到在实例化应用程序时可以以编程方式提供应用程序特定的参数。这有助于将与配置相关的参数放在 config.ini 中,
我实际上是这样做的:
在 index.php 中引导
引导程序内的应用程序
In a similar scenario, I saw that the application specific parameters can be provided programmatically when instantiating the application. This helped to place configuration related parameters within the config.ini
I did it actually this way:
inside the index.php to bootstap the application
inside the bootstrap
您可以通过在其他引导方法(需要配置对象)中指定类似以下内容的方式,确保在其他引导方法之前调用 _initConfig() 引导方法:
更完整的示例(引导类的上下文):
更新:
正如现在所提到的其他答案,如果仅在引导程序中需要配置,我会说使用
$this->getResource('Config')
方法。我使用注册表,以便可以在应用程序的其他部分轻松访问配置。You can ensure an _initConfig() bootstrap method is invoked before others by specifying in your other bootstrap methods (that require the config object) something like:
A more complete example (context of a Bootstrap class):
Update:
As has now been mentioned in other answers, if the config is only required within the bootstrap, I would say to use the
$this->getResource('Config')
method. I use the registry so that config can be accessed easily in other parts of my application.