http://www.yiiframework.com/doc/api/1.1/CWidget

These are essentially controllers with just one action, and although constructing them and configuring them ahead of time (passing them through the view-dictionary), you can also freely construct and run these from within the view.

Yii provides widgets for things like breadcrumbs, paging and menus. Would you consider those good condidates for “pull”?

Personally, I have always used “pull” for certain things – although in the strictest terms, Tom Anderson is correct in his comment above, and for that matter, I know some people who would claim that “pull” is not MVC at all, because you’re branching out of the view back into a controller, there is no longer any strict separation of the two. I still think it has legitimate uses for certain things though – especially when you don’t care how the data gets there, as long as it gets there.

Guy said that push models “requires defining in advance what should be pushed”. However, I’m not exactly in tune with this comment, since pull models also need to know what should be pulled!

I think the best way is to make the view dumb. If there’s something that needs to be shown, let the controller do the showing. The view needs to show the controller what is needed, but it doesn’t need to call the functions. In this way, the view exposes itself to the controller, and the controller pushes what needs to be pushed.

It means that you can test your program more thoroughly.

I never used the Magento e-Commerce Platform. But the way you describe how it works, sounds to me almost ideal. It combines the use of regular push model to create the main part of the content, and allows you to “pull” the other parts.

Similar, but maybe to a less extent, functionality is also provided in CakePHP by use of Elements.

Frameworks that only provide strict “push” model, like the second one you mention, in my opinion are less robust. While when well implemented this model can have higher performance (as it’s less complicated code-wise), the more configuration overhead leads to slower development. Furthermore, this model limits flexibility as it requires defining in advance what should be pushed (of course careful in-advance planning could work around it).

Magento also makes use of both described ways.
The general business logic is implemented in the controller actions that use models and push the results to the view.

But on more complex views especially when you have to conditionally load data you may use ‘blocks’, that itself have access to the needed models and get the data from them.

In my opinion this makes perfect sense. All logic that has to manipulate data in models only resides within the controller, so you should never put that part into such a block.

Furthermore I also worked with a framework that strictly enforces the ‘push’ model by defining all ‘blocks’, ‘widgets’, ‘portlets’ or whatever you call it, in a config file, so that all those parts will be invoked even before the templates are rendered. So the templates will never have to call methods for data retriving once the business logic is processed. This is a much ‘cleaner’ MVC approach by the cost of more configuration overhead.

Regards, Marc