On Fri, Aug 21, 2009 at 8:01 PM, Matthew Weier O'Phinney <matt...@zend.com>wrote:
> -- J DeBord <jasdeb...@gmail.com> 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 > Hector, Matthew, Excellent. Thanks! For my config idea, I was assuming the config object would be stored in the registry or as a resource if using Zend_Application. My main concern was forcing the user to do one thing or another. I am going to go forward with your suggestions Mathew. Thanks a lot. If anyone else has any ideas, I'd love to hear them. Jason
