不幸的是,更复杂的问题被跳过了,因为如果没有真正具体的目的或目标,编写示例或操作指南就非常困难。我花了一些时间在这里帮助另一个开发人员,他想要
修改隐藏元素的显示方式,但他的情况非常特殊,所以更容易深入具体细节。
大多数更复杂的任务实际上归结为针对特定字段类型扩展默认助手。例如,我有一个项目,我想在表单提交后将类“error”应用于所有未通过验证的字段,而不是编写验证错误文本:
<label for="field">Label:</label>
<input type="text" name="field" id="field" class="error">
这是一个相当复杂的过程,因为实际的表单元素默认情况下不可用于视图助手,所以助手无法检查元素是否具有验证错误。因此,我进行了以下过程:
我必须为每个字段类型创建一个客户视图辅助程序,以便将“error”类应用于它们。在其中,我重写了
formXXX()
方法,并添加了一个检查以查看元素是否有错误。此外,我添加了一个
setElement()
方法,装饰器可以调用该方法来设置元素的实例,以便我的辅助程序可以检查错误。
接下来,我必须覆盖默认的
Zend_Form_Decorator_ViewHelper
。在其中,我访问视图并实例化表单元素类型的辅助程序,并检查我在视图辅助程序中创建的
setElement()
方法是否存在,如果存在则进行设置。通过这样做,我可以扩展一些表单元素类型而不破坏整个脚本。
在每个表单的init()函数中,我必须添加一个新的元素前缀路径(
addElementPrefixPath('My_Form_Decorator'), 'path/to/decorator'
),它指向我的新表单装饰器。
最后,我必须将帮助程序路径添加到我的应用程序中,以便Zend Framework可以找到我在第一个项目中创建的帮助程序:
addHelperPath('/path/to/helpers', 'My_View_Helper');
你可以看到为什么编写复杂的教程确实需要真实世界的问题。设置这些类型的辅助程序或复杂的装饰器方案的好处是,虽然一开始可能很烦人,但如果需要进行更改,它允许您非常轻松地创建许多遵循相同设计方案的表单,并快速统一修改其输出。但另一方面,如果你觉得你花了很多时间来解决一个应该是简单任务的问题,那我会建议你跳过它!
然而,如果你需要更具体的帮助,我将非常乐意提供帮助。只需提出另一个问题(或更新此问题),我会尽力帮助你。