Re: [fw-mvc] why setting the $bootstrap variable to TRUE in index.php?

Truthfully, I think a few modifications to the Central Application is not
only the best soluttion, but also the most properly MVC-displayed solution.
I've been using a central application routine since I was a java developer,
and I never quite followed why it was rejected with Zend. However, I know it
was the intentions to keep a loosely coupled framework, and I've already got
a great setup. So Im OK :)

However, I also use routeStartup/Shutdown to handle setup ( especially for
needed request info ).
It's a great tool.

For example, in my initialization plugin, at the routeShutdown, I do:

// Handles namespaced module session initialization
Project::getSingleton('core/session',array(
'_namespace'=> $this->getRequest()->getModuleName()))->start();

So, I agree that the event handling is best for what Zend is trying to
accomplish.

goriol wrote:
>
> Thank you Matthew for this clarification.
>
>
> Matthew Weier O'Phinney-3 wrote:
>>
>> -- jkush1121 <jonKushner@gmail.com> wrote
>> (on Friday, 12 September 2008, 12:12 PM -0700):
>>> Now that you explain it like that, then yes that makes perfect sense.
>>> However, now that this topic has been brought up, I must admit that I am
>>> a
>>> much larger fan of keeping the setup outside of the public bootstrap (
>>> as
>>> you changed to within the new quickstart ). I try to abstract my index
>>> to
>>> where I can pass in a set of codes, types, and options, and then handle
>>> the
>>> setup itself somewhere else down the road.
>>
>> This is actually the intention behind separating index.php from
>> bootstrap.php. In my own projects, I typically do initialization during
>> a routeStartup() plugin -- which works similarly to what you outline
>> below. We would like to address the idea of a standard component for
>> setting up your application, but would prefer to get useful information
>> out to developers *now* so we can debate that topic properly.
>>
>> In the revisions to the quick start I've just made (not yet published),
>> I've put the autoloading setup in index.php, which leaves bootstrap.php
>> for literally setting up the application environment.
>>
>>> This, I believe, will help with
>>> new developers, projects, and so on.
>>>
>>> IE... // cron.php
>>>
>>> try {
>>> Bootstrap::getInstance()
>>> ->loadObserver('crontab')
>>> ->addEvent('crontab')
>>> ->dispatch();
>>>
>>> } catch (Exception $e) {}
>>>
>>> IE... // index.php
>>>
>>> try {
>>> Bootstrap::getInstance()->dispatch();
>>> } catch (Exception $e) {}
>>>
>>> Maybe it's not exactly in tune with what the discussion is about, but I
>>> think my point is that the setup should be handled as it was changed
>>> to...
>>> outside the index.
>>>
>>>
>>>
>>> Matthew Weier O'Phinney-3 wrote:
>>> >
>>> > -- jkush1121 <jonKushner@gmail.com> wrote
>>> > (on Friday, 12 September 2008, 10:11 AM -0700):
>>> >> Don't take my word for final, as this is clearly something which
>>> Matthew
>>> >> should respond, but my understanding is that it serves as a
>>> preventative
>>> >> measue to ensure that the bootstrap will setup once. Upon turning to
>>> >> false,
>>> >> the setup will bypass. I see what you are saying though, being that
>>> it
>>> >> only
>>> >> hits the page one time. It might just be more preventative measures.
>>> >
>>> > It's nothing to do with preventative measures. It's to allow for
>>> re-use
>>> > of the bootstrap.php file when testing or scripting, two situations
>>> > where the environment may be setup differently than the standard web
>>> > application.
>>> >
>>> > I'm considering moving this setup to the index.php file prior to
>>> calling
>>> > the bootstrap.php file, to allay this confusion.
>>> >
>>> >
>>> >> goriol wrote:
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> > The new quickstart for ZF 1.6 explains how to create a public
>>> index.php
>>> >> > file that will be the only entry point of the application. This
>>> file
>>> >> > starts with:
>>> >> >
>>> >> > <?php
>>> >> > // Step 1: Set a flag indicating setup is necessary
>>> >> > $bootstrap = true;
>>> >> > ...
>>> >> >
>>> >> > Then, the boostrap.php is described and an example is given that
>>> starts
>>> >> > with:
>>> >> >
>>> >> > <?php
>>> >> > // Step 1: Check to see if the applicaiton environment is already
>>> setup
>>> >> > if (isset($bootstrap) && $bootstrap) {
>>> >> > ...
>>> >> >
>>> >> > My question is:
>>> >> > why setting a $bootstrap variable and testing it in the bootstrap
>>> file?
>>> >> > As the index.php will be run at every request, the $bootstrap
>>> variable
>>> >> > will always be true and the "if" section will always be executed.
>>> >> >
>>> >> > Did I miss something?
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/why-setting-the-%24bootstrap-variable-to-TRUE-in-index.php--tp19458419p19460320.html
>>> >> Sent from the Zend MVC mailing list archive at Nabble.com.
>>> >>
>>> >
>>> > --
>>> > Matthew Weier O'Phinney
>>> > Software Architect | matthew@zend.com
>>> > Zend Framework | http://framework.zend.com/
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/why-setting-the-%24bootstrap-variable-to-TRUE-in-index.php--tp19458419p19462290.html
>>> Sent from the Zend MVC mailing list archive at Nabble.com.
>>>
>>
>> --
>> Matthew Weier O'Phinney
>> Software Architect | matthew@zend.com
>> Zend Framework | http://framework.zend.com/
>>
>>
>
>

--
View this message in context: http://www.nabble.com/why-setting-the-%24bootstrap-variable-to-TRUE-in-index.php--tp19458419p19467339.html
Sent from the Zend MVC mailing list archive at Nabble.com.