Question

我正在为我们的应用程序创建一个显示对象库。它们在各种视图中呈现许多常见对象（用户，对话，消息等）的html。通过视图我的意思是对象可以用不同的标记来回吐自身的不同“缩放级别”。

某些显示对象包含要渲染的其他显示对象，例如。用户列表对象在特定视图中呈现用户对象（此特定视图将它们反映在列表项中，以便它们适合列表）

我正在尝试将这些转换为在ZF中正确处理的方式，但我无法确定这些是否应该都是视图助手，或者它们是否都是视图脚本/部分。

只是让他们查看脚本并使用 - ＆gt; render（）渲染它们似乎有点脏，因为我想传递给它们的任何信息或参数都必须分配给视图对象。

部分似乎更正确，除了不确定它们是否适合在这些中做显示逻辑（如果'showNotificationStatus'作为参数传递，渲染此跨度）。或者，如果它用于部分渲染其他部分（用户列表呈现用户对象）的犹太洁食。

查看助手似乎可能是正确的方法，但我不知道这是否过度使用了视图助手。每个对象都可以是一个视图助手，并接受一个对象视图参数，因此它知道要渲染自己的缩放级别/容器，或者每个对象视图甚至可以是它自己的帮助器（因此对象内部没有大的switch语句）。关于视图的一个好处是你可以传递参数，如果你需要那个级别的东西，它仍然可以访问视图上下文。

其中大部分将接受模型，少数需要一些额外的参数来知道该做什么（例如上面的showNotificationStatus）。什么是适当的工具？

Answer 1

偏爱的核心思想之一是它们意味着尽可能地重复使用 - 因此它们有自己的可变范围。我喜欢将partials用作少量HTML的相当愚蠢的容器。除了少数if()或foreach()语句之外，没有其他主要逻辑。

如果我需要严肃的逻辑 - 我使用帮手。助手应该负责处理逻辑和调用渲染方法。我知道在Rails世界中，帮助程序倾向于封装一些逻辑，比如处理链接或图像标记的构造。这很好，但我不认为在ZF中使它们更复杂是有害的。我基本上使用它们将我的业务对象翻译成视图。

我认为使用partials和helper的最佳方法是让helper设置数据，然后将其传递给partials。通过这种方式，您的HTML保持非常容易维护（我怀疑每次有人键入echo "<a href='". $my_link . '"/>"小猫在某处死亡）。

编辑（详细说明）：

关于帮助程序要记住的是，它们可以像普通类一样对待，使用带参数的构造函数并拥有私有成员。因此，当您实例化一个帮助程序时，您可以使用一个业务对象，然后使用多个方法来呈现HTML（通过部分）。

所以在我看来：

<?php $helper = $this->_helper->MyUserHelper($users); ?>
<ul>
  <?php $helper->user_list(); ?>
</ul>

此处，user_list()方法返回<li>元素的集合，其中包含所有适当的数据。

我的助手可能看起来像这样：

class MyWidgetHelper 
{
  private $_widget;   

  public function __construct($users)
  {
     $this->_users = $users;
  }

  public function user_list()
  {
     // do any necessary logic here
     // then return the html that gets rendered. 
     // you can call a partial from here, and it just returns an HTML string.
     return $this->_view->partial('partials/_user_item.phtml', array('users' => $users)
  }
}

Answer 2

助手用于逻辑（例如将对象转换为数组），部分用于装饰逻辑（将递归数组显示为<ul>树）。

请注意，您也可以使用$this->render('anyfile.ext')或include()。

Zend Framework - 何时使用viewscripts / partials vs view helpers

2 个答案: