(on Monday, 13 April 2009, 08:12 PM +0100):
> 2009/4/13 keith Pope <mute.pop3@googlemail.com>:
> > Looks like a good solution until we can afford the time to create a DI solution.
> >
> > btw did you have any other thoughts on the module bootstrapping?
>
> One other thought I had was how ZApp handles exceptions, in the
> frontcontroller we have a way of turning exception throwing on and
> off, it would also be useful to have a way of handling Zapp exceptions
> in a similar way.
>
> The main reason for this is generally you dont want to provide full
> exceptions if you are in a production environment. I understand this
> is a difficult issue as you have no view etc instantiated etc, but
> maybe a callback or something would work.
>
> This is obviously a very trivial matter as you can achieve similar
> results wrapping the bootstrap call in a try statement, but I wanted
> to just air my thoughts :)
That's the kind of functionality you could wrap into the _bootstrap()
and run() methods. ;)
> > 2009/4/13 Matthew Weier O'Phinney <matthew@zend.com>:
> >> -- Benjamin Eberlei <kontakt@beberlei.de> wrote
> >> (on Monday, 13 April 2009, 07:05 PM +0200):
> >>> A local registry is a nice approach in contrast to the global. But maybe the
> >>> naming should show the difference to Zend_Registry :-)
> >>
> >> I was actually thinking of using set/getContainer(), without any
> >> typehinting. This would make it easy to later use a DI container, but
> >> still default to a registry if nothing is specified.
> >>
> >>> Additionally, the way of transporting the registry is probably the way
> >>> to move a DI container through the application.
> >>>
> >>> I like it as a first start :-)
> >>
> >> That's my thought as well. Start here, and move forward.
> >>
> >>> On Monday 13 April 2009 16:50:01 Matthew Weier O'Phinney wrote:
> >>> > Greets, all --
> >>> >
> >>> > One thing I -- and others -- have been struggling with regarding
> >>> > Zend_Application is how to share resources both during bootstrapping as
> >>> > well as during the actual application runtime.
> >>> >
> >>> > The easy way to do this is simply to define your resources such that
> >>> > they add to the registry:
> >>> >
> >>> > public function _initFoo()
> >>> > {
> >>> > $foo = new Foo();
> >>> > Zend_Registry::set('Foo', $foo);
> >>> > }
> >>> >
> >>> > This is problematic on a few levels, though. Global registries are
> >>> > difficult to test against, and introduce hard to track dependencies into
> >>> > your code.
> >>> >
> >>> > Another possibility is to introduce a DI Container into ZF. This is a
> >>> > nice solution, and one I want to entertain -- but requires a lot of
> >>> > thought and effort, and I don't want to hold up 1.8 for this.
> >>> >
> >>> > Yet another possibility is to introduce a local registry. A little known
> >>> > fact about Zend_Registry is that you can also create non-global
> >>> > registries with it. This would allow us to push the registry into module
> >>> > bootstraps as well as the front controller, which would allow you to
> >>> > pull from it in your action controllers, helpers, and plugins.
> >>> >
> >>> > The idea here would be that if a resource method or plugin has a
> >>> > non-null return value, then that value would be registered with the
> >>> > registry. As an example, let's look at a potential implementation of the
> >>> > FrontController resource plugin:
> >>> >
> >>> > class Zend_Application_Resource_Router extends
> >>> > Zend_Application_Resource_Base {
> >>> > public function init()
> >>> > {
> >>> > // Grab the registry from the bootstrap:
> >>> > $registry = $this->getBootstrap()->getRegistry();
> >>> >
> >>> > // Grab the front controller:
> >>> > $front = $registry->frontcontroller;
> >>> >
> >>> > // do some stuff, and initialize the router...
> >>> > // add the router to the front controller:
> >>> > $front->setRouter($router);
> >>> >
> >>> > return $router;
> >>> > }
> >>> > }
> >>> >
> >>> > Because the resource now has an explicit return value, the Bootstrap
> >>> > would register it with the local registry. To keep things simple and
> >>> > consistent, the key would match the resource. So, if you wanted to
> >>> > retrieve the router, you'd use this:
> >>> >
> >>> > $router = $registry->router;
> >>> >
> >>> > In your action controllers, you'd use the following:
> >>> >
> >>> > $registry = $this->getInvokeArg('registry');
> >>> > $router = $registry->router;
> >>> >
> >>> > This would be a simple change to make to the Zend_Application API, easy
> >>> > to document, and not really affect BC with those who have been
> >>> > experimenting with the 1.8 preview release.
> >>> >
> >>> > Any thoughts?
> >>>
> >>> --
> >>> Benjamin Eberlei
> >>> http://www.beberlei.de
> >>>
> >>
> >> --
> >> Matthew Weier O'Phinney
> >> Project Lead | matthew@zend.com
> >> Zend Framework | http://framework.zend.com/
> >>
> >>
> >
> >
> >
> > --
> > ----------------------------------------------------------------------
> > [MuTe]
> > ----------------------------------------------------------------------
> >
>
>
>
> --
> ----------------------------------------------------------------------
> [MuTe]
> ----------------------------------------------------------------------
>
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
没有评论:
发表评论