context object
Moderator: General Moderators
context object
Browsing through the agavi and symfony code I saw they used a context object while other popular frameworks do not. I'm a bit annoyed with passing objects like request and response all over the place so I thought the context object could be nice in dealing with that. The other option to get rid of these method arguments would be to use a global registry with getters and setters aimed at these frequently needed objects instead. The platform independence could then be reached in a similar matter.
Enyone with opinions about this choice?
Enyone with opinions about this choice?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: context object
I would choose a Registry over a Context object. A Registry will encourage modularity better.
(#10850)
Re: context object
You're probably right. The coupling relationships with a registry are also very clear.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Re: context object
The problem though, for the ZF at least, is that they are cornered. To maintain component independence they can only rely on components that are obviously related. Zend_Registry is not obviously related to Zend_Controller, hence they use setters over a Registry interface. Of course you can argue, as many of us do, that they spoil even that by adding such tight integration (by default) between the Controller and View (i.e. the ViewRenderer and it's Controller related render() method and configuration options).
Re: context object
What do you mean by "they use setters over a Registry interface". AFAIK they use setters and getters in the front controller. Hence to get things like the dispatcher they use methods which call the singleton frontcontroller instance and get the dispatcher from there.
eg somewhere in zend_controller_action: $dispatcher = Zend_Controller_Front::getInstance()->getDispatcher();
If they use a registry for these things I haven't encountered it yet. Anyway, I don't like the above construction.
eg somewhere in zend_controller_action: $dispatcher = Zend_Controller_Front::getInstance()->getDispatcher();
If they use a registry for these things I haven't encountered it yet. Anyway, I don't like the above construction.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Re: context object
Substitute "instead of" for "over a". Same meaning - sorry I get a bit obscure when typing at times
.
Re: context object
I see what you mean now with "over a". Being non-english it's sometimes easy to misread/misunderstand. The problem is not with your use of words.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Re: context object
It sounds like ZF needs a healthy dose of the separated interface pattern. Instead of relying on the Registry component, they simply rely on a Registry interface.
I've always been a fan of context objects (effectively registry objects passed by parameter) because they are truly local. Registries are glorified globals and should be treated with care.
I've always been a fan of context objects (effectively registry objects passed by parameter) because they are truly local. Registries are glorified globals and should be treated with care.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: context object
Context objects are still glorified globals. The only difference is the contract is with a method name rather than a registered name. That means a Context object is simply an inflexible, inextensible registry. Which you may want, or you may not want.
(#10850)
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Re: context object
Bear in mind, the Registry in ZF is global for one specific Registry instance. Many components utilise the Registry as the default Context class and chug along with numerous non-global instances.