to setup and where.
- Locality
- View
- Session
- Db
- etc.
These have been swapped around back and forth to my fit needs, but for sure
I have had this dicussion multiple times with fellow colleagues.
jkush1121 wrote:
>
> 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--tp19458419p19467400.html
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论