> 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 :)
thx
keith
>
> 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]
> ----------------------------------------------------------------------
>
--
----------------------------------------------------------------------
[MuTe]
----------------------------------------------------------------------
没有评论:
发表评论