“initView() and render() are no longer required by default. You can have an empty conroller class and it will still work with the view file by default.”

It’s true that once an action function meets the end if no render() is called it will automatically render the template..however, it’s still GOOD programming practice to include it. Personally I will always use it just to remind myself (and anyone else viewing the code) what to expect next.

I’m getting above error. Could you please explain me where is the problem?

Would be appreciated your help.

It’s probably best just to use $this->initView() as & when you need to.

e.g.

...
function indexAction()
{

$this->initView();
$this->view->assign ( ‘a’ , ‘b’ );
$this->render();
}
...

Hopefully this will get covered in the manual soon. It seems to be most pertinent to the Model part of MVC, which doesn’t have its own manual section. Maybe that’s why it’s not there yet.

Just to clarify, $this->initView() needs to be called before you can assign data to the view.

If you hadn’t initialized the view, the following action would throw a fatal error (for attempting to call a method on a non-object $this->view):

function indexAction()
{

$this->view->assign ( ‘a’ , ‘b’ );
$this->render();
}

I would favour creating an abstract class which extends Zend_Controller_Action, and defining the init() method in this class (as Ben has done in the concrete controller): all your controllers can then just inherit your abstract class, and you won’t need to worry about initView() any more.

I wonder if they’ll alter Zend_Controller_Action to do this by default for us …

Cheers, Amir

Having to call initView() is clumsy. Having ->render() echo instead of return is also asking for trouble (it means you have to output-buffer in order to nest templates).

.phtml isn’t always enabled, so you’re cutting out people on some shared-hosts. Stick to standards.

I also dislike having a pointless ‘scripts’ directory. It’s just one more thing I have to drill-down into[sigh]. Furthermore, it’s anti-semantic! The name ‘scripts’ directly contradicts one of the main reasons for using the .phtml extension—to make it easy to distinguish between ‘scripts’ and ‘views’. Putting non-script views in a scripts directory is nonsensical.

Of course, these are all critiques of the View object, and not your writing, Ben. Very handy & well-written tutorial.

Please note that I said this is the “default” behavior. You are allowed to customize and extend things as much as you want, so you are not locked into a rigid way of doing things. You can also specify a different location for your views or even a different named view than that of your action. It’s very flexible; what I’ve discussed in this post is not the only way to do things.

you don’t have to call $this->initView(); explicitly in your init method as the Zend_Controller_Action::render method does this automatically for you.

This way you can skip the instantiation in cases where you redirect or output via other mechanisms

Happy hacking,
Sascha

I’ve always liked the Velocity-like nature of the Zend View (and others), but it seems that way too much code was tacked on to reduce the amount of work/discipline on developer’s part.

This seems like an awefully strict structure to impose in the name of organization…one that would quickly breakdown if a need arose outside of what View was designed for.

While the wiki manual may be more up to date, the Zend_View section still does not explain what I described in this post. Instead, it continues to illustrate the use of views by instantiating a new Zend_View object, specifying the location of the views directory for it, and echoing a call to $view->render().