Question

I’ve been working with Zend Framework (using Doctrine as the ORM) for quite a while now, and done a few projects with it.

In a few upcoming projects I am requiring the need for widgets similar to how WordPress does them. You have a post/page, which could look like:

Subscribe to my newsletter:
[subscribe/]

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

View this page's comments
[comments/]

Where say the subscribe widget would be replaced with Blog::subscribeWidget, and the events could be replaced with Events::eventsWidget, etc.

Now it has done my head in the past few weeks about how on earth do I do this??? I’ve come up with the following options:

1. I could place the widgets within controllers, and then call them like actions. Problem here is that code could be flying between controllers, and I have read this is expensive due to the amount of dispatches.

2. I could place the widgets as view helpers. So within the view I could have $this->renderPage($Page), which would then attend to all the widgets. Problem here is that what if the widgets need to do some business logic, like for example posting a new comment, that really shouldn’t be within the view, should it?

3. The other option is to place widgets within the model? But then how on earth do they then render content for display?

Extra complications come when:

1. Say the comments widget would also handle posting, deleting of comments etc.

2. Say for the events listing, if I want to do an ajax request to the next page of events, using method #2 (view helpers) how would this work?

Answer 1

I left Richards reply, the problem, and further use cases cook in my brain for a while longer and ended up coming to a solution.

I will have the following view helpers and methods:

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

I will have inside my configuration file:

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

I will also have the following models:

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

So inside my view I will do something like this:
echo $this->content()->render($this->Content)

Content::render() will then perform any content rendering and then perform rendering of the widgets by passing along to Content::renderWidgets(). Here we will use the configuration of app.widgets to link together the widget bbcode tag to it’s appropriate view helper (using the naming convention ‘render’.ucfirst($tag).’Widget’). So for example Content::renderCommentsWidget() would then proceed to render the comments.

Perhaps later on I will decide to have a Widget View Helper, and individual view helpers for each widget eg. ContentCommentsWidget View Helper. But for now that would just add additional unrequired complexity.

Now to answer the AJAX problem I mentioned. Say for the comments widget allowing for comments to be posted via ajax. It would simply have an appropriate method inside the Content Controller for it. So pretty much we also have a Event and Subscription controllers too – corresponding with the view helpers. Interaction between the view helper and controller will all be hard coded, there is no purpose for it to be soft coded.

I hope this helps someone else, and the current plan is to make the project where all this is used to be an open-source project. So maybe one day you can see it all in action.

Thanks.

---

Update:

You can find the source code of these ideas in action in the following repositories:

• BalCMS – this is the actual CMS which contains the widgets in /application/modules/balcms/view/helpers and contains the configuration in /application/modules/config/application/balcms.yaml
• BalPHP – this is the resource library which contains the widget view helper at /lib/Bal/View/Helper/Widget.php