btw did you have any other thoughts on the module bootstrapping?
Thx
Keith
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]
----------------------------------------------------------------------
没有评论:
发表评论