What does a return do in _init methods of ZF Bootstrap class?

Question

Here's a sample of _init method of Zend_Bootstrap from ZF manual. At the end there is return command:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initView()
    {
        // Initialize view
        $view = new Zend_View();
        $view->doctype('XHTML1_STRICT');
        $view->headTitle('My First Zend Framework Application');

        // Add it to the ViewRenderer
        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper(
            'ViewRenderer'
        );
        $viewRenderer->setView($view);

        // Return it, so that it can be stored by the bootstrap
        return $view;    // Why return is here?
    }
}

can be stored by the bootstrap

Why to return? Where the bootstrap stores it and why? What object calls this method and who gets the result? And what will happen if no to return?

UPDATE:

On Available Resource Plugins page, in the section about View, they show the following way of initiation of Zend_View:

Configuration options are per the Zend_View options.

Example #22 Sample View resource configuration

Below is a sample INI snippet showing how to configure the view resource.

resources.view.encoding = "UTF-8"

resources.view.basePath = APPLICATION_PATH "/views/"

And it seems convenient and reasonable to initiate the View this way, from application.ini file, together with all the other resources they write about in the Zend_Application Quick Start page. But at the same time on the same Zend_Application Quick Start page they say that the View has to be initiated from the Bootstrap:

Now, we'll add a custom view resource. When initializing the view, we'll want to set the HTML DocType and a default value for the title to use in the HTML head. This can be accomplished by editing your Bootstrap class to add a method:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initView()
    {
        // Initialize view
        $view = new Zend_View();
        $view->doctype('XHTML1_STRICT');     // the same operations, I can set this in application.ini
        $view->headTitle('My First Zend Framework Application');   // and this too

        // Add it to the ViewRenderer
        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper(
            'ViewRenderer'
        );
        $viewRenderer->setView($view);

        // Return it, so that it can be stored by the bootstrap
        return $view;
    }
}

And event more interesting with other resources, with Request for example here:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initRequest()
    {
        // Ensure the front controller is initialized

        $this->bootstrap('FrontController');   // why to initialized FC here if it is going to be initialized in application.ini anyway like resource.frontController.etc?

        // Retrieve the front controller from the bootstrap registry
        $front = $this->getResource('FrontController');

        $request = new Zend_Controller_Request_Http();
        $request->setBaseUrl('/foo');
        $front->setRequest($request);

        // Ensure the request is stored in the bootstrap registry
        return $request;
    }
}

So it seems that they offer a choice to initiate resources this or that way. But which one is right then? Why they mix them? Which one is better to use?

In fact I can just remove all those lines about FC from my application.ini:

resources.frontController.baseUrl = // some base url
resources.frontController.defaultModule = "Default"
resources.frontController.params.displayExceptions = 1

and rewrite it something like this:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
    {
        protected function _initFrontController()
        {

            $this->bootstrap('FrontController');
            $front = $this->getResource('FrontController');
            $front->set ...  
            $front->set ...   // and here I set all necessary options

            return $front;
        }
    }

What is the difference between application.ini way and _initResource way? Does this difference means something serious in work?

Answer 1

Although you would have got your answers after some time going through the zend manual. However I'll try to answer your questions.

1.Why to return?

Although there is no need to return and it is not mandatory.A return is only used to store the
variable in the zend container which is usually the Zend registry.This stored variable can be accessed by you anywhere the need be.If you don't return the only difference it would make is that you won't be able to fetch the variable anywhere. Found the following on the zend manual while writing the answer. It will surely help.

As an example, consider a basic view resource:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initView()
    {
        $view = new Zend_View();
        // more initialization...

        return $view;
    }
}
You can then check for it and/or fetch it as follows:

// Using the has/getResource() pair:
if ($bootstrap->hasResource('view')) {
    $view = $bootstrap->getResource('view');
}

// Via the container:
$container = $bootstrap->getContainer();
if (isset($container->view)) {
    $view = $container->view;
}

2.Where the bootstrap stores it and why?

I think the first one answers this.

3.What object calls this method and who gets the result?

An Application object calls the bootstrap usually(at the very beginning) and you can call individual resource methods too through the object. But if you don't specify any parameters while calling the bootstrap method all the resource methods(e.g _initView(),_initRouters()) will get executed .

4.What will happen if no return.

Answered by 1 I think.

This contains almost all the answers you are looking for. http://framework.zend.com/manual/1.12/en/zend.application.theory-of-operation.html

Hope it helps.

UPDATE:

Saw your update.. Actually that is a matter of choice I think.

Where you want to define your resources is up to you.

Been working on a project where only the basic resources are defined in the application.ini file and most of the resources are loaded from the bootstrap...

Again its your choice however you would feel the comfort and flexibility when using the bootstrap for loading the resources.(e.g defining custom routes etc).

That is what I feel.