-- J DeBord <[email protected]> wrote (on Friday, 21 August 2009, 06:44 PM +0200): > What is the preferred approach to supply constant values to a View Helper? > > If a view helper requires configuration constants. For example, a google api > key or amazon web services access keys, is it best to: > > A) Make the developer put these values in a Zend_Config object and then access > the config object in the View Helper's constructor? > > B) Make the developer assign the values as view variables and access them > with > $this->view->var inside the view helper? > > C) Pass the variables to the view helper when it is called in the view script? > > I am not a fan of any of these choices, but if I had to pick one I'd go with > A.
Except that config objects are not global. ;) There are two standard patterns we've been using for this problem: * Accessors in the helper for setting these values. In this case, typically calling the helper with no arguments will return the helper instance (or you can use getHelper() to grab it as well), and you then call the accessors. * Specify a Zend_Registry key or keys from which values will be pulled if present. In this case, if the developer does not manually pass in the values, it then tries the Registry; if nothing is found there, it then throws an exception. Typically, the key(s) used is named after the class that uses it: Zend_Translate, Zend_Locale, etc. Typically, you'll be passing in values such as API keys in the controller or your bootstrap -- not the view -- so I think your concerns about exposing the information in the view are unwarranted. I'd recommend the above two-pronged approach, and go from there. > I like the fact that A centralizes the constants in a relatively secure spot. > They would be sitting next to database passwords, etc. But I don't like the > constraints it places on the developer. Not only would Zend_Config need to be > used, but the config object would either need to be stored in a registry, or > created inside the view helper. Even if I create the Zend_Config object inside > the view helper, I would still need to pass the constant params needed for > Zend_Config... > > I don't like the idea of adding what could be sensitive information, the aws > private key for example, to the view object, so that eliminates B and C. > > I think C is the worst of all because it adds an extra var to supply when > calling the view helper. > > What other options are there if any? What would be acceptable dependencies for > a Zend_View_Helper? > > To make things slightly more complicated, I guess there is the possibility > that > these "constant" values could change during the life of a single request or on > a page by page basis, thus they would no longer be constant. This could happen > if someone uses two or more AWS accounts for example. This could be dealt > with, > but would add complexity. > > I want to make decisions that result in the most flexible and easy to use > view_helper possible. > > I am working on a Zend_View_Helper proposal http://framework.zend.com/wiki/ > display/ZFPROP/Zend_View_Helper_S3Link+-+Jason+DeBord and I think this is the > only issue holding up the completion of the prototype code. > > The view helper I created to accomplish what is outlined in my proposal uses a > Zend_Config object stored in Zend_Registry. While this works great and might > be > fine for my colleagues purposes, I am not sure it is a viable solution for a > Zend Framework component. > > Thanks a lot, > > Jason -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/
