问题标签 [zend-config]

我目前正在 Phing 中开发一个构建系统，该系统采用 Zend Framework 项目模板并根据 Phing 参数对其进行配置。我遇到的一个问题是在使用 Zend_Config_Writer_Ini 时。

我的 Phing 任务从 repo 中获取一个名为 application.default.ini 的预填充文件，并使用 Zend_Config_Ini 对其进行修改，以从构建文件中添加参数（数据库详细信息等）。然后将其写入 application.ini 以供项目使用。相关任务代码的简化版本如下所示：

就数据库凭据而言，这可以正常工作，但是当涉及到包含已定义常量的预填充路径时，就会出现问题。例如：

变成：

有没有办法在读取/写入不同的 ini 文件时保留这些配置行，或者我应该在运行任务之前重组我的构建文件以复制文件并且只修改我需要更改的 ini 行？

当变量/属性的类型错误时，我经常遇到问题。问题是很难追踪，因为我的 PHP (5.3) 只是崩溃了，没有发出错误，甚至没有写入错误日志 (*1)。它只是崩溃。

我认为访问像数组这样的字符串不应该是不可追踪的吗？我的意思是，PHP 不是 C 对吗？

有没有办法改变这种行为或某种最佳实践来解决这个问题？除了一直检查每个变量并因此编写 5 倍以上的代码之外？

[更新]：好的，如果我在 Zend 之外简化代码，它似乎可以工作。它一定与 Zend 相关。虽然我确实在我的 application.ini 中设置了所有 phpSettings：

导致错误的代码（我刚刚尝试在沙箱中工作）是这样的：

其中 $obj 是一个 json 字符串。

[更新 2]：所以我尝试使用代码上方的 ini_get 回显 php 设置，它说 error_reporting 在 E_ALL|E_STRICT 上，display_error 为 ON 等。

所以这：

发这个：

然后停止。有任何想法吗？

*1。php.ini 有 display_errors = On 和 error_reporting = E_ALL 等等。都好。

我的 Zend 应用程序使用 3 个 ini 配置文件，总共需要解析 200 多行，包含 100 多条指令。这些文件是否解析每个请求？有些人说他们是（比如这里和这里）。如果是这样，这不是效率问题吗？

这些链接中的评论意见不一——有人说您应该避免使用 ini 配置文件并在 PHP 中进行配置，有人说您可以使用 Zend_Cache_Frontend_File，还有人说这不是问题。但是，如果您预计会有大量流量，那么为每个请求解析 200 行文本肯定会很快成为一个问题？

如果您确实建议使用缓存技术，您能否准确解释一下您将如何实现它？

到目前为止，我一直在使用Bootstrap.php将 application.ini 配置加载到 Zend_Registry 以及记录器实例中。我想知道将这些存储在 Zend_Cache 中是否会是一个更好的解决方案，因为它们在应用程序的生命周期内保持不变，并且每当我重新部署应用程序时，无论如何都会在第一次运行时清除缓存。你对此有何判断？

有人还建议创建一个控制器，将记录器和配置存储在受保护的变量中，然后所有应用程序控制器都将从那里继承。我不认为这是一个比当前 Zend_Registry 更好的解决方案，不确定我是否有道理。

我有一个如下结构：

在 indexController.php 中

我得到错误

致命错误：找不到类“Structure_Form_Department”

尝试zf enable form module接收时：

我认为这是一个类似配置的问题......但不明白我需要做什么......

编辑 1

在这里找到了很好的解决方案

但是对于某种方式，zend_init...从默认的 bootstrap.php 开始重复执行函数......

我在 config.ini 文件中有以下内容：（Zend_Form_Element）

如您所见，这应该是一个下拉（选择）框，但它被呈现为标准文本框。我究竟做错了什么？

--> 编辑

我没有将元素绑定到表单，而是尝试将它们绑定到数据库：在我的代码中，它看起来像这样：

从那里我会拉入表单将代表数据的数据库表（一个或多个表，必要时）。至于这种方法的原因是（在路上），我想定义（通过 ini 或其他一些存储方法）一个配置文件，它将是属于特定表单的字段/元素列表（非程序员类型可以轻松编辑），“通用”表单类将读取、提取元素信息并动态创建表单。

但是我确实意识到这带来了另一个我还没有弄清楚的问题，那就是如何使用表查找来选择元素（无需将查找的数据库检索编码到表单中，以便非用户可以轻松地在没有任何编程、纯粹配置的情况下定义它，但这是另一个主题，不是我的问题的一部分。（我认为无论如何我对这部分问题有可行的想法/解决方案）——额外的配置条目和通用例程差不多。

我希望这能阐明我的思维过程以及我为什么按照上面示例中的方式这样做的原因。

我正在尝试使用 Zend_Config_Ini 创建表单元素。在其他元素中，我有一个 datepicker 元素 (zendx_jquery_form_element_datepicker) 无法工作。

我试过像这样设置元素：

和

无论哪种方式都以相同的错误消息结束：

或者

请帮忙，谢谢。

我的系统上的每个客户端都有一个 ini 文件，并添加了一个新的部分和要动态创建的密钥。

我需要一些这样的想法：

当前的ini文件：

并且需要将这个（使用 php/zend）代码更改为：

需要添加一个名为 section_b 的新部分，其中包含一个名为 key_a 的新键，但我在 Zend_Ini_Config 上找不到任何方法，如“$ini->add('section_b','key_a')”。

观察：

任何帮助！

更新

我的 application.ini 中有这些值

问题是所有数据库和异常值都可以正常工作，这意味着它们按照应有的方式正确继承

但是我为 Title 和 url 设置的值不能正确继承，只使用第一个定义的值。

为什么是这样？这是设计使然吗？是否仅继承预定义/标准环境值，例如数据库和异常？

还是我在某个地方犯了错误？

我似乎遇到了一个问题，即使用 Zend_Config 对象加载 Zend_Application 对象与使用文件名加载 Zend_Application 对象产生不同的结果。为了说明我的观点，我有以下两种加载方法，第一种有效（请注意，此时也定义了所有常量：

这个不起作用并给我错误：

致命错误：在 /var/www/RoommateExpenseBuddy/allan/library/Zend/Application/Bootstrap/Bootstrap.php:91 中未捕获的异常“Zend_Application_Bootstrap_Exception”和消息“没有向前端控制器注册的默认控制器目录”

堆栈跟踪：#0 /var/www/RoommateExpenseBuddy/allan/library/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#1 /var/www/RoommateExpenseBuddy/allan/public/index.php(36): Zend_Application->run()

#2 {main} 在第 91 行抛出 /var/www/RoommateExpenseBuddy/allan/library/Zend/Application/Bootstrap/Bootstrap.php

他们都使用相同的文件，如下所示：

我的目录结构看起来像这样，重要的文件夹展开了。

所以重申一下，使用 Zend_Application 的构造函数中的文件名加载 INI 文件会产生预期的结果（工作应用程序）。将 Config 对象传递给 Zend_Application 的构造函数会给我上述错误。

关于为什么这会有所作为的任何线索？