Thursday, September 25. 2008
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
There are many, many components in Zend Framework that are pluggable; I suspect you're not reading deeply enough in the manual. 
ZF's MVC has a front controller plugin system for global events, action helpers for action controllers (which can also listen to init/pre/postDispatch hooks), view helpers (which are basically plugins for your views), and more. Your example of wanting to add advertisements to a site sounds like a good candidate for either a front controller plugin or a view helper (which would be consumed by your layout script). In either case, the functionality could be easily re-distributed to work with other applications.
ZF's MVC has a front controller plugin system for global events, action helpers for action controllers (which can also listen to init/pre/postDispatch hooks), view helpers (which are basically plugins for your views), and more. Your example of wanting to add advertisements to a site sounds like a good candidate for either a front controller plugin or a view helper (which would be consumed by your layout script). In either case, the functionality could be easily re-distributed to work with other applications.
Hi Matthew
Thanks for the reply. I'll freely admit that there is much in the manual I'm not aware of. Every time I go to the site I seem to learn something new.
That being said I'm aware of the front controller plugins and helpers although I haven't used them a lot yet. I'm more familiar with the view helpers. From what I've seen they're more structural than what I had in mind. I doubt structural is the correct term but what I mean is you put in x and you get out y.
Contrasting that with django_monetize if you put in x you might get out y, z, a, b, c, . . . depending on your config options, where the user is coming from, which letters have already been displayed etc.
ZF has a strong foundation on which to build more involved plugins and as you say they could be easily distributed. My point was that such plugins, occupying the middle ground between the structural and the Magento like, aren't being distributed yet.
Thanks for the reply. I'll freely admit that there is much in the manual I'm not aware of. Every time I go to the site I seem to learn something new.
That being said I'm aware of the front controller plugins and helpers although I haven't used them a lot yet. I'm more familiar with the view helpers. From what I've seen they're more structural than what I had in mind. I doubt structural is the correct term but what I mean is you put in x and you get out y.
Contrasting that with django_monetize if you put in x you might get out y, z, a, b, c, . . . depending on your config options, where the user is coming from, which letters have already been displayed etc.
ZF has a strong foundation on which to build more involved plugins and as you say they could be easily distributed. My point was that such plugins, occupying the middle ground between the structural and the Magento like, aren't being distributed yet.
There is some momentum building in the community to start distributing user plugins, and I think in the next few months you'll start seeing something concrete. Keep your eyes on the fw-general mailing list for announcements. There is already one individual accumulating view helpers for redistribution, and another has contacted me about setting up a "forge" type site, which would offer even greater opportunities.
You missed the built-in plugin support we have in symfony. It is one of the great strength of the symfony framework.
A symfony plugin can package anything you can have in a "normal" project: controllers, templates, images, javascripts, routing rules, configuration, and much more.
As an added bonus, it's pretty easy to install a symfony plugin (the system is based on PEAR):
./symfony plugin:install sfGuardPlugin
The great thing about being based on PEAR is that you can host you own symfony plugin repository and can manage dependencies, symfony and PHP compatibility, ...
We have more than 280 plugins right now and it's growing everyday:
http://www.symfony-project.org/plugins/
A symfony plugin can package anything you can have in a "normal" project: controllers, templates, images, javascripts, routing rules, configuration, and much more.
As an added bonus, it's pretty easy to install a symfony plugin (the system is based on PEAR):
./symfony plugin:install sfGuardPlugin
The great thing about being based on PEAR is that you can host you own symfony plugin repository and can manage dependencies, symfony and PHP compatibility, ...
We have more than 280 plugins right now and it's growing everyday:
http://www.symfony-project.org/plugins/
Very interesting!
This seems to be exactly the type of thing I was thinking about. It looks as though you have the full range of plugins I talked about from the simple login system right up to blogs and forums.
Thanks for posting.
This seems to be exactly the type of thing I was thinking about. It looks as though you have the full range of plugins I talked about from the simple login system right up to blogs and forums.
Thanks for posting.
"One of the issues I've had with projects like phpBB and wordpress is that they only play nicely with other projects if they're in charge."
- Could you give any examples of this? My issue with those two would be that they have crazy architecture or rather lack of any. They are pretty backward. Not so familiar with PHPBB, but WP still has some quite basic problems.
- Could you give any examples of this? My issue with those two would be that they have crazy architecture or rather lack of any. They are pretty backward. Not so familiar with PHPBB, but WP still has some quite basic problems.
Hello David
Firstly let me say that this isn't a problem solely with these two projects. Many others have the same limitations. The popularity of those two projects just mean they are the first which come to mind.
My issue with them is there is no easy way to tell them that someone is logged in or to pass user credentials to them. They assume that the user will login using their system and then you'll root around in there code/database schema looking for the data you want.
My preference would be that somewhere in a config file you can tell them that instead of using the PHPBB_Auth class to instead use MY_CUSTOM_Auth class which implements the PHPBB_Auth_Interface.
Firstly let me say that this isn't a problem solely with these two projects. Many others have the same limitations. The popularity of those two projects just mean they are the first which come to mind.
My issue with them is there is no easy way to tell them that someone is logged in or to pass user credentials to them. They assume that the user will login using their system and then you'll root around in there code/database schema looking for the data you want.
My preference would be that somewhere in a config file you can tell them that instead of using the PHPBB_Auth class to instead use MY_CUSTOM_Auth class which implements the PHPBB_Auth_Interface.
The author does not allow comments to this entry
