Another option for the common users' data is to simple create a View Helper which runs the relevant query to get the total user count (have the helper grab the Model instance and perform the work). Then simply call that View Helper from within your template as needed. Just to be smart, you can use the same helper if its really really needed within a Controller using $this->view->myHelper().
The reason an Action Helper for that case may be inappropriate, is that the data is needed by the View, but is not needed by the Controller, so why even bother doing it in the Controller? ;) Skip the middleman. As for configuration, why not create an Action Helper to simply encapsulate the Zend_Config instance? Then from a controller, you can access the instance using something like: $this->_helper->config The only work required would be formulating the helper as a basic proxy to the underlying Zend_Config instance using PHP's magic methods, and registering the Action Helper to the HelperBroker. See: http://devzone.zend.com/article/3350-Action-Helpers-in-Zend-Framework In general it's a good idea to avoid extending Zend_Controller_Action to add functionality. It's the easy option, and like all similarly easy options it can turn into a bloated, overused, unportable class. Rob Allen-3 wrote: > > > On 8 Jan 2009, at 11:13, Ionut Gabriel Stan wrote: > >> On 1/8/2009 12:05, Rob Allen wrote: >>> >>> On 8 Jan 2009, at 09:26, Bart McLeod wrote: >>> >>>> You can of course have a base custom controller, but you do not >>>> need to. >>>> >>>> Depending on what you need exactly you can use either an action >>>> helper >>>> in the init method or a plugin or both a plugin and an action >>>> helper. >>>> >>>> public function init(){ >>>> $this->_helper->myInit(); //instead of your six lines of code >>>> } >>> >>> >>> Actually, if you have a My_Controller_Action::init(), you don't >>> need to >>> define and init() at all in the child classes, whereas if you use a >>> helper, you do need to define the init() in the controllers where you >>> need the myInit(). >> >> Depends on the place where you register the helper, because >> HelperBroker::__construct() will call the init() method of all >> registered helpers at the time Zend_Controller_Action is >> instantiated. Then, the same HelperBroker will call the >> preDispatch() and postDispatch() method of all helpers before and, >> respectively, after Zend_Controller_Action::dispatch(). >> >> There's a nice representation of this process here: >> >> http://surlandia.com/wp-content/uploads/2008/11/zf-dispatch-lifecycle-bw.jpg >> >> So, IMHO, a helper could be the solution, the only issue remaining >> might be the place to register the helper and then what callback >> method to use, init() or preDispatch(). > > > > That's correct, but if you register the helper with the broker and use > the hooks, you will get the initialisation for every single > controller. If you use a superclass, then you can choose whether to > extend a given controller with it or not. > > Personally, I would use a helper and an init() function in the > controllers where I want to use that common functionality. > > Regards, > > Rob... > > > ----- Pádraic Brady Blog: http://blog.astrumfutura.com Free Zend Framework Book: http://www.survivethedeepend.com OpenID Europe Foundation - Irish Representative -- View this message in context: http://www.nabble.com/Best-Practices%3A-Eliminate-redundancy-within-various-controller-init-methods--tp21341232p21350275.html Sent from the Zend Framework mailing list archive at Nabble.com.
