Re: [fw-general] Setting up controllers for common vars etc
Hi Matthew Carlton,
Thanks for the suggestions. I decided in the end to use an action
helper and preDispatch to do this. So here is my current idea on it.
So far so good it seems to work;
1. Create and action helper
?php
class My_Controllers_Helpers_ActionSetup extends extends
Zend_Controller_Action_Helper_Abstract
{
public function preDispatch()
{
$this-_actionController-_MyCoolAppsRegistry =
Zend_Registry::getInstance();
}
}
2. Register the helper in my bootstrap
// N.B. This class is stored in /library/My/Controllers/Helpers/ActionSetup.php
Zend_Controller_Action_HelperBroker::addHelper(new
My_Controllers_Helpers_ActionSetup());
3. Use it in a Controller
As I am using preDispatch, its run before my controller action is
setup, therefore the vars should be already registered and setup for
me
class IndexController extends Zend_Controller_Action
{
public function indexAction()
{
Zend_Debug::dump($this-_MyCoolAppsRegistry);
}
}
Done. I think
If you get a chance you may like to let me know if I got that all
sorted out correctly.
Cheers
AJ
.
On Thu, Jul 3, 2008 at 1:17 PM, Matthew Weier O'Phinney
[EMAIL PROTECTED] wrote:
-- AJ McKee [EMAIL PROTECTED] wrote
(on Thursday, 03 July 2008, 12:51 PM +0100):
Please excuse my ignorance here.
I have several Controllers that all do various things. However there
are common things I wish them all to do. Mostly just set up vars for
ease of use. Eample
protected $_myRegistry = null;
protected $_myDebug = false;
public function init()
{
$this-_myRegistry = $this-_registry = Zend_Registry::getInstance();
%this-_myDebug = $this-_myRegistry-get('debug');
}
I am trying to apply the principle of DRY here, because as the
application grows, I am repeating myself more and more.
I created an action plugin thinking I was on the right track, however
I discovered I was not. Basically, I want all this stuff setup before
my controller is called, but have it available to my controller in a
manner similar to $this-_myRegistry. Or would I best be doing this in
an action helper?
Action Helper is the way to go here. An action helper has introspection
into the action controller, and its primary purpose is to push all those
bits of code you need to re-use to a common place so that they can be
used on-demand by any controller.
Additionally, you can have action helpers listen on controller
intialization and pre/postDispatch() events; this can be useful for
injecting variables into your action controllers. The variables will
need to be public, obviously, but there are very few cases where this
should be an issue.
Does anyone have any pointers to me about how I would accomplish this,
if its possible.
I've written a tutorial on action helpers on DevZone:
http://devzone.zend.com/article/3350-Action-Helpers-in-Zend-Framework
that should serve as a good starting point.
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
Re: [fw-general] Setting up controllers for common vars etc
-- AJ McKee [EMAIL PROTECTED] wrote
(on Thursday, 03 July 2008, 12:51 PM +0100):
Please excuse my ignorance here.
I have several Controllers that all do various things. However there
are common things I wish them all to do. Mostly just set up vars for
ease of use. Eample
protected $_myRegistry = null;
protected $_myDebug = false;
public function init()
{
$this-_myRegistry = $this-_registry = Zend_Registry::getInstance();
%this-_myDebug = $this-_myRegistry-get('debug');
}
I am trying to apply the principle of DRY here, because as the
application grows, I am repeating myself more and more.
I created an action plugin thinking I was on the right track, however
I discovered I was not. Basically, I want all this stuff setup before
my controller is called, but have it available to my controller in a
manner similar to $this-_myRegistry. Or would I best be doing this in
an action helper?
Action Helper is the way to go here. An action helper has introspection
into the action controller, and its primary purpose is to push all those
bits of code you need to re-use to a common place so that they can be
used on-demand by any controller.
Additionally, you can have action helpers listen on controller
intialization and pre/postDispatch() events; this can be useful for
injecting variables into your action controllers. The variables will
need to be public, obviously, but there are very few cases where this
should be an issue.
Does anyone have any pointers to me about how I would accomplish this,
if its possible.
I've written a tutorial on action helpers on DevZone:
http://devzone.zend.com/article/3350-Action-Helpers-in-Zend-Framework
that should serve as a good starting point.
--
Matthew Weier O'Phinney
Software Architect | [EMAIL PROTECTED]
Zend Framework | http://framework.zend.com/
Re: [fw-general] Setting up controllers for common vars etc
On 3 Jul 2008, at 12:51, AJ McKee wrote:
I have several Controllers that all do various things. However there
are common things I wish them all to do. Mostly just set up vars for
ease of use. Eample
protected $_myRegistry = null;
protected $_myDebug = false;
public function init()
{
$this-_myRegistry = $this-_registry =
Zend_Registry::getInstance();
%this-_myDebug = $this-_myRegistry-get('debug');
}
I am trying to apply the principle of DRY here, because as the
application grows, I am repeating myself more and more.
Does anyone have any pointers to me about how I would accomplish this,
if its possible.
Hi AJ,
One thing you **could do** is extend Zend_Controller_Action in order
to override the constructor.
(You then have your application controllers extend from that).
?php
class My_Controller_Action extend Zend_Controller_Action
{
// shared class properties here
public function __construct(Zend_Controller_Request_Abstract $request,
Zend_Controller_Response_Abstract $response,
array $invokeArgs =
array()
)
{
// stuff to happen before init()
parent::parent::__construct($request, $response, $invokeArgs);
//stuff to happen after init()
}
// Class Continues...
}
The key thing is to call parent::_construct() which runs init() as
its last action. Also you can't access things like $this-getRequest
() until after you've done so (however they are already in scope so
you may not want to...)
I use this approach myself for loading module include paths. In
general though I'd want to avoid loading too much into the controller
this way as plugins and action helpers are more flexible in the main.
(Note to self: move module include path stuff to a plugin! :-)
I hope this helps.
regards,
Carlton
