|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Lars Strojny - 14/Dec/07 10:32 AM
Type detection for Zend_Config
Support for Zend_Config_Xml and Zend_Config_Ini. Unit test case missing.
Another patch which is a) compatible against the latest trunk and b) removes the tabs used, sorry
My employer is happy with that. I've already signed one. So I will make Veit Bartels sign one too.
It is a convenience feature. When setting exceptions wheither exceptions are thrown in the front controller I just pass the plain configuration value (configuration is verified before against as XML schema therefore I'm sure the value exists) without headaches about types. I just want to avoid that the code is full of casts because my developers are not sure which type it is. So casting the value once is much cheaper for us.
Here is a code example where I use type detected Zend_Config: MyFrontController::getInstance()
->setParam('disableOutputBuffering', !$this->_config->controller->front->buffer)
->throwExceptions($this->_config->controller->front->exceptions)
->returnResponse(true)
->addModuleDirectory($this->_config->controller->modules);
I'm not sure why you need to cast as !"0" will result in boolean true anyway as PHP will auto-cast appropriately.
In general, it's very rare to have to worry about casting. One of the few cases I can think of is dealing with strings within SimpleXML elements. Regards, Rob... I have to agree with Rob at this point, as it has not been demonstrated to my satisfaction that such a typecasting feature is necessary.
So if you take a config file like snippet <exceptions>0</exceptions> it is much worse readable then <exceptions>false</exceptions>. But you are right, the exception example in the code above is bad, because the value is casted implicitly because of the negation. But think on
FrontController::getInstance() ->throwExceptions($config->throwExceptions); ->dispatch(); This will just not work. I have to sprinkle casts all over in my sourcecode instead of doing the business where it belongs: in the object which returns the data. The biggest problem with types and the config components is, that various adapters have various behaviours. This is really not the idea of adapters. Accessing an adapter through a front object should always provide the same behaviour independent of the used adapter. This is not the case for Zend_Config and our type detection is a way to fix that. Well, these are good points, especially the one that Zend_Config should behave the same ways for different configuration storage formats. We do have to consider backward compatibility, and changing this behavior is certainly not backward-compatible (e.g., a "false" value in XML resulting in boolean false differs from current behavior).
I suspect that the way to resolve this issue is with a proposal that unifies the behaviors across various adapters, and we could probably break some backward compatibility in ZF 2.0.0. Rob, what do you think? I would suggest adding this patch in the 1.x branch because it is optional anyway. Later on we can adjust Zend_Config to convert types per default.
The trouble is that it adds additional baggage to the class and I don't see enough of a use-case to justify it. The functionality could probably be done quite easily as a subclass that implements it's own __get(). Are there really enough uses for type-casted config data that it should be in the core component?
At the end it is a design decision. The Zend Framework tends to be strict or at least stricter on types than a number of other component libraries so I would stress, that adding type detection is a good idea.
I suggest that a proposal be written to further explore our options on such automatic casting behaviors.
Did this proposal get authored/submitted? I'd like to make sure this is tracked somewhere before closing the issue.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Patch
Resolved
Major
Automatic primitive type detection for Zend_Config
