Платформа зенда - Когда использовать viewscripts/partials по сравнению с помощниками представления
Я создаю библиотеку экранных объектов для нашего приложения. Они представляют HTML большого количества общих объектов (пользователи, переговоры, сообщения, и т.д.) в различных представлениях. Представлениями я подразумеваю, что объект может плюнуть назад различными 'уровнями масштабирования' себя с другой разметкой.
Некоторые экранные объекты содержат другие экранные объекты для рендеринга, например, объект списка пользователей представляет пользовательские объекты в определенном представлении (это конкретное представление плюется ими назад в элементы списка, таким образом, они вписываются в список),
Я пытаюсь переместить их в надлежащий способ сделать вещи в ZF, но я не могу решить, должны ли они все быть помощниками представления, или если они - все представление scripts/partials.
Просто заставив их просмотреть сценарии и рендеринг их с-> рендеринг () кажется немного грязным, потому что любая информация или параметры, которые я хочу передать им, должны быть присвоены объекту представления.
Partials кажутся немного более корректными, кроме не уверенный, если его надлежащее для выполнения логики дисплея в них (если 'showNotificationStatus' передается в качестве параметра представьте этот промежуток). Или если его кошерное, чтобы partials представил другой partials (список пользователей, представляющий пользовательский объект).
Помощники представления походят возможно на правильный способ сделать это, но я не знаю, злоупотребляет ли это помощников представления. Каждый объект мог быть помощником представления и принять objectview параметр, таким образом, он знал, какой уровень/контейнер масштабирования представить себя в, или каждый objectview мог даже быть его собственный помощник (таким образом, нет никакого большого оператора переключения в объекте). Одна хорошая вещь о представлениях - Вы, может передать параметры, и она все еще имеет доступ к контексту представления при необходимости в чем-то от того уровня.
Большинство из них будет моделями принятия с некоторыми требующими, чтобы некоторые дополнительные параметры знали, что сделать (например, showNotificationStatus сверху). Каков надлежащий инструмент для этого?
2 ответа
Одна из основных идей частиц заключается в том, что они предназначены для повторного использования, насколько это возможно, поэтому они имеют свою собственную область видимости переменных. Мне нравится использовать партиклы как довольно глупые контейнеры для небольших фрагментов HTML. Никакой серьезной логики, кроме нескольких if() или foreach() операторов.
Если мне нужна серьезная логика - я использую помощника. Хелперы должны отвечать за работу с логикой и вызов методов рендеринга. Я знаю, что в мире Rails хелперы обычно инкапсулируют небольшие кусочки логики, например, обработку построения ссылок или тегов изображений. Это здорово, но я не думаю, что есть какой-то вред в том, чтобы сделать их более сложными в ZF. По сути, я использую их для преобразования бизнес-объектов в представления.
Я думаю, что лучший способ использовать и партиции, и хелперы: хелперы устанавливают данные, а затем передают их в партиции. Таким образом, ваш HTML остается очень простым в поддержке (и я подозреваю, что каждый раз, когда кто-то набирает echo ""где-то умирает котенок).
EDIT (подробнее):
Главное помнить, что с хелперами можно обращаться как с обычными классами, использовать конструктор с аргументами и иметь приватные члены. Таким образом, когда вы инстанцируете хелпер, вы можете создать бизнес-объект, а затем иметь несколько методов, которые рендерят HTML (через партиции).
Итак, на мой взгляд:
<?php $helper = $this->_helper->MyUserHelper($users); ?>
<ul>
<?php $helper->user_list(); ?>
</ul>
Здесь метод user_list() возвращает коллекцию элементов со всеми нужными данными в них.
Мой хелпер может выглядеть так:
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)
}
}
Помощники предназначены для логики (например, преобразовывают объект в массив), части предназначены для украшения логики (отображают рекурсивный массив как дерево ).
Помните, вы также можете использовать $ this-> render ('anyfile.ext') или include () .