2009-10-04 3 views
3

Я уже давно работаю с Zend Framework (используя Doctrine как ORM), и сделал с ним несколько проектов.Виджеты внутри Zend Framework - Куда они должны идти?

В нескольких предстоящих проектах мне требуются виджеты, похожие на то, как Wordpress делает их. У вас есть записи/страницы, которая может выглядеть следующим образом:

Subscribe to my newsletter: 
[subscribe/] 

View my events 
[events limit=5 sort=date/] 

View this page's comments 
[comments/] 

Где говорят, подписываются виджет будет заменен Блог :: subscribeWidget, и события могут быть заменены События :: eventsWidget и т.д.

Теперь он сделал мою голову в последние несколько недель о том, как я это делаю? Я придумал следующие варианты:

  1. Я могу разместить виджеты внутри контроллеров, а затем называть их как действия. Проблема здесь в том, что код может летать между контроллерами, и я прочитал, что это дорого из-за количества отправлений.

  2. Я могу разместить виджеты в качестве помощников вида. Таким образом, в представлении у меня может быть $ this-> renderPage ($ Page), который затем будет обслуживать все виджеты. Проблема здесь в том, что, если виджеты должны выполнять некоторую бизнес-логику, например, например, опубликовать новый комментарий, который действительно не должен быть в представлении, не так ли?

  3. Другой вариант - разместить виджеты внутри модели? Но тогда как же они тогда отображают контент для показа?

Дополнительные осложнения приходят, когда:

  1. Произнесите комментарии виджет будет также обрабатывать проводки, удаление комментариев и т.д.

  2. Say для события листинга, если я хочу сделать ajax на следующую страницу событий, используя метод # 2 (просмотреть помощники), как это будет работать?

ответ

0

Я оставил Ричардсу ответ, проблема и дальнейшие варианты использования кулинарии в моем мозгу на некоторое время дольше и в конечном итоге пришли к решению.

я буду иметь следующий вид хелперы и методы:

Content; with methods: render, renderWidgets, renderWidget, renderCommentsWidget (comments). 
Event; with methods: renderEventsWidget (many events), renderEventWidget (one event) 
Subscription; with methods: renderSubscribeWidget (subscription form).

я есть в моем файле конфигурации:

app.widgets.comments.helper = content 
app.widgets.subscribe.helper = subscription 
app.widgets.events.helper = event

Я также будет иметь следующие модели:

Content for use for all pages. 
Event for use for all events. 
Subcriber for use for subscriptions to content

Итак, в моем представлении я сделаю что-то вроде этого: echo $this->content()->render($this->Content)

Содержимое :: render() будет выполнять любой контент-рендеринг, а затем выполнять визуализацию виджетов, передавая Content :: renderWidgets(). Здесь мы будем использовать конфигурацию app.widgets для связывания тега bbcode виджета с соответствующим помощником вида (используя соглашение об именах 'render'.ucfirst ($ tag).' Widget '). Таким образом, например, Content :: renderCommentsWidget() будет продолжать делать комментарии.

Возможно, позже я решит, что для каждого виджета будет использоваться помощник виджетов и отдельные видовые помощники. ContentCommentsWidget View Helper. Но на данный момент это просто добавит дополнительную нерегулярную сложность.

Теперь, чтобы ответить на проблему AJAX, я упомянул. Скажем, для виджета комментариев, позволяющего отправлять комментарии через ajax. Он просто имел бы подходящий метод внутри Контроллера содержимого для него. Таким образом, у нас также есть контроллеры событий и подписки - соответствующие с помощниками вида. Взаимодействие между помощником представления и контроллером будет жестко закодировано, нет никакой цели для его мягкого кодирования.

Я надеюсь, что это поможет кому-то другому, и текущий план должен сделать проект, где все это используется как проект с открытым исходным кодом. Поэтому, возможно, однажды вы сможете увидеть все это в действии.

Спасибо.


Update:

Вы можете найти исходный код этих идей в действии в следующих хранилищах:

  • BalCMS - это фактическая CMS, которая содержит виджеты/приложение/модули/balcms/view/helpers и содержит конфигурацию в /application/modules/config/application/balcms.yaml
  • BalPHP - это библиотека ресурсов, которая содержит помощник виджетов в /lib/Bal/View/Helper/Widget.php
5

Если я вас правильно понял ваши виджеты будут нужны свои собственные контроллеры действий, который является, где их логика для извлечения данных, которые будут отображаться, анализ формы представления и т.д., должны идти. Разница между виджетами и страницей в этом случае заключается в том, как она отображается, т. Е. Как фрагмент HTML, а не как целая страница; вы можете использовать Action View Helper для достижения этого.

Если ваш виджет содержит форму, он должен, вероятно, использовать AJAX для отправки данных формы обратно на сервер, так что использование виджета не приводит к случайному перемещению пользователя от страницы. Вы можете ввести требуемый JavaScript на страницу, в которую вы включили виджет, используя Head Script Helper в представлении и/или действии вашего виджета.

+0

Привет, Ричард благодарит за ответ, я очень благодарен. Я позволю вашему ответу, проблеме и дальнейшим вариантам использования кулинария в моем мозгу на некоторое время дольше и в конечном итоге пришел к решению. Который теперь оглядывается назад в значительной степени, что вы коснулись. Так что спасибо, и я отправлю подробное решение в течение следующих нескольких минут в качестве другого ответа. – balupton

+0

Я рад, что вы нашли мой ответ полезным. Возможно, вы проголосуете за это, чтобы немного помочь моему представителю;) –

+0

Будет ... Когда я смогу получить достаточное количество голосов, чтобы проголосовать! – balupton

Смежные вопросы