-- Kevin Schroeder <[EMAIL PROTECTED]> wrote
(on Thursday, 07 February 2008, 11:23 AM -0600):
> Been working in Framework for a while and I’ve taught the
> Framework
> course 1 or 2 times and while I enjoy using Framework there is one thing that
> slows me down. That is, often configuration options are set using associative
> arrays. That, in and of itself, is no problem. But the problem I’ve run into
> is that usually you have to go into the Framework code itself to find out what
> the keys for the config arrays need to be. If I know what the option name is
> that I want to use it’s not that big of a deal, but there’s no way that me,
> average Framework developer, can memorize all of the configuration options for
> all of the classes. To make that easier it would be nice to have class
> constants provided for configuration options. That way an IDE’s code
> completion could be used to help developers specify which options they want to
> set without breaking any current code, plus using phpDoc we could document
> each
> option individually rather than in a big block for $this->_options. For
> example, in Zend_Cache_Core we currently have:
In the Zend_Form components, I followed this rule:
* Any set*() method is available as a config option and is normalized
to ucfirst():
setAction() => action or Action
setMethod() => method or Method
setLegend() => legend or Legend
* All methods are documented in the end-user docs, and the above rule
is explained (along with any exceptions)
However, that does *not* address IDE completion, as you note. However,
you could potentially eschew configuration via array in such a case and
simply use the accessors (which is what setConfig() and setOptions() end
up doing anyways).
<snip - Zend_Config example from current code>
> Would have this added
>
> class Zend_Cache_Core
> {
> /**
> * Sets the lifetime of the cache
> */
> const CONFIG_LIFETIME = ‘lifetime’;
> const CONFIG_CACHING = ‘caching;
> const CONFIG_LOGGING = ‘logging’;
No. no. no. Configuration constants should be easy to use, and their
names should correspond pretty much one-to-one to what they represent.
We need to standardize this; in some classes, we have the constant equal
to its literal string (e.g., Zend_View_Helper placeholders, Zend_Form),
in others we have it equal to a camel-cased version of itself (e.g.,
Zend_Validate, Zend_Filter). Whichever way we choose, it should be
consistent between all classes -- though this could potentially be a BC
break, and should be reserved for a major revision.
Another thing to note, though: in many cases (Zend_Form is one), we
don't use constants at this point, and there are *so* many configuration
keys that creating the constants is going to be a pretty time consuming
and painful task -- and a moving target.
Otherwise, I agree with you -- this *would* improve IDE awareness as
well as provide nice documentation of configurable items for developers.
:-)
> Then to specify the options you would do
>
> $options = array(
> Zend_Cache_Core::CONFIG_LIFETIME => 60
> );
>
> $cache = Zend_Cache::factory(‘File’, ‘Page’, $options);
>
> That way developers wouldn’t have to browse the Framework code to see what all
> the config options are. Instead, code completion would help them find the
> right setting.
>
> What do y’all think? It helps us document things better and it also makes
> life
> a lot easier for the developer.
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
