Zend_Environment Proposal Review
 | Proposal Review Period This proposal is for review until August 27, 2006. This may change as the review progresses and more or less time is needed. You may enter comments directly at the end of the document, or for more directed comments you may create a new issue in the issue tracker for this project. |
Zend Framework: Zend_Environment Component Proposal
| Proposed Component Name | Zend_Environment |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Environment |
| Proposers | Simon Mundy Alexander Veremyev (Zend Liaison) |
| Revision | 0.1 - 30 June 2006: Initial proposal. 0.2 - 3 July 2007: Revised proposal with 2 new methods. (wiki revision: 22) |
Table of Contents
1. Overview
Zend_Environment provides a singular method for obtaining supplementary information on PHP, PHP Modules and other environmental settings
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- Gathers output from phpInfo() and stores as an associative array
- Provides per-section and/or per-module information from phpInfo()
- Provides OS information as associative array
- Provides list of currently loaded extensions or tests for existence of specific extension
- Provides a module interface to allow further extensions (e.g. security)
4. Dependencies on Other Framework Components
- Zend_Exception
5. Theory of Operation
A Zend_Environment instance is created by passing one or more Zend_Environment_Module instances to the constructor. The object then parses each module (according to that module's own interpreter) and builds a profile of 'section/module' information.
Currently it retrieves only php-related information, but will be used in the future to gather runtime information on the Zend Framework itself (versions installed, etc) or any other supplementary info that would assist developers during testing/debugging. It could also be used as a diagnostic during install processes for self-installing applications (e.g. checkModule() for modules/php/etc).
Each module that is passed to the Zend_Environment is iterable and allows further inspection of each of the modules contained. The common object returned from a module query is a Zend_Environment_Info, which will always return the following properties (which are set at the discretion of each module):-
6. Milestones / Tasks
- Milestone 1: Create prototype with 'core' modules - Ini, Core, Extension, Os - Currently in progress as of 20th Sep 2006
- Milestone 2: Develop, refine and finalise with feedback from community and Zend
- Milestone 3: Commit to Incubator, include simple demo and use cases [
- Milestone 4: Unit tests exist, work, and are checked into SVN
- Milestone 5: Commit initial documentation
- Milestone 6: Extend modules with Security, Hostinfo (tbc) - Contingent on Security module completed by Ed Finkler
- Milestone 7: Add localised (localized?
warnings, info and error messages - Depends on Zend_Translate being finalised
7. Class Index
- Zend_Environment
- Zend_Environment_Exception
- Zend_Environment_Info
- Zend_Environment_Module_Abstract
- Zend_Environment_Module_Core
- Zend_Environment_Module_Os
- Zend_Environment_Module_Extension
- Zend_Environment_Module_Server
- Zend_Environment_Module_Ini
- Zend_Environment_Decorator_Interface
- Zend_Environment_Decorator_Text
- Zend_Environment_Decorator_Html
- Zend_Environment_Decorator_File
8. Use Cases
| UC-01 |
|---|
9. Class Skeletons
For class skeletons please see attached file
21 Comments
comments.show.hideJun 30, 2006
Thomas Weidner
Some additional functionality would be great as Zend_Environment
could be used to get a complete overview of the whole system.
Gettings configuration values from phpinfo :
Getting settings from php.ini :
Getting system values:
Get version of executables
Just to count some good functionality which could do well in this class.
Jun 30, 2006
Simon Mundy
Hi Thomas - the class already does the first two points:-
print_r(Zend_Environment::getInfo('general'));
print_r(Zend_Environment::getInfo('general', 'Configure Command'));
print_r(Zend_Environment::getInfo('configuration'));
print_r(Zend_Environment::getInfo('configuration', 'include_path');
print_r(Zend_Environment::getInfo('modules', 'session');
print_r(Zend_Environment::getInfo('environment');
print_r(Zend_Environment::getInfo('environment', 'TERM_PROGRAM');
...it uses the same options that phpInfo() uses to classify the directives.
I agree, some additional system values would be a nice addition. I'll have to research a bit to find out how we can query that from within PHP - one of the original criteria for this class was that it needed to be free of extension dependency.
Jun 30, 2006
Thomas Weidner
Not all settings from php.ini are presented in phpinfo().
So some values are not passed by Zend_Environment. Therefor i meant to get the settings from php.ini or direct through function call (instead of parsing phpinfo() )
What do you mean with "free of extension dependency"...
Framework Components or PHP Extensions ??
Even when "dependend" it would be nice to provide the information when the extension is available or get a notification/exception when the extension was not found.
Jun 30, 2006
Simon Mundy
Which values from php.ini are not coming across from phpinfo()? I'd like to cross-check to ensure the class doesn't miss anything.
By 'free of extension dependency' I mean that Zend_Environment should be able to interrogate the system without the use of third-party extensions or add-ons that do not come with a default/minimum install of PHP. For example, it would be nice to get more info on the processor type, chip speed, etc., but if it required a passthru() or some other external library then I'd have to forego that.
The getExtension() method does indeed pass an array of currently loaded extensions, or returns a boolean if you wish to test for the existence of a specific extension.
E.g. if (Zend_Environment::getExtension('tidy'))
I don't think throwing an exception would be required for this kind of operation.
Jul 01, 2006
Thomas Weidner
I'm missing f.e. memory_limit and register_long_arrays in phpinfo.
But I've not crosschecked the whole ini.
As useable extension I would define all which come with PHP.
This includes for example the process lib.
The network settings should be readable with php.
But such information as processor type and chip speed I think we could not get without 3rd party extensions so we would not provide them. Maybe someone will write an ZF-Extension for this sometimes
I think we should include the informations we can get using the php-libs or the ones we could get writing by our own.
Jul 01, 2006
Simon Mundy
You can get those with:-
$core = Zend_Environment::getInfo('configuration', 'php core');
var_dump($core['memory_limit']);
var_dump($core['register_long_arrays']);
Which network settings specifically would you be looking at - I'm gathering a few new methods together based on the feedback from the mailing list.
Jul 01, 2006
Thomas Weidner
Ok... then when all php.ini settings are coming through phpinfo this should be no problem
Following functions/datas could be nice to know through Zend_Environment
I'm sure that not all of this informations are avaiable without extensions, but some should be.
So someone could make an action depending on a defined system-status.
Jun 30, 2006
Wojciech Naruniec
I think it could returns informations about Zend Framework components too.
Jun 30, 2006
Simon Mundy
The biggest stumbling block I can see so far is that version numbers are not stored within Zend components, so even if we could iterate through the Zend_* directories, we still wouldn't have any clue as to the pedigree of a class. It'd be nice to enforce some kind of version number for components so that we could look this information up... Feature request, anyone?
Jun 30, 2006
Thomas Weidner
I think that not every component should have a own version number.
But the whole framework should have one.
Jul 05, 2006
Ondrej Ivanic
I think, the better is to use the ReflectionExtension() and get_loaded_extensions() instead of parsing output from phpinfo().
Jul 06, 2006
Simon Mundy
Hi Ondrej,
Sounds ideal, but the reality wasn't off to a flying start...
I tested the getExtensionVersion with the examples shown on the reflection documentation page and it returned:-
Name : gd
Version : NO_VERSION
Functions : [87] array (
'gd_info' =>
ReflectionFunction::__set_state(array(
'name' => 'gd_info',
)),
..etc..
So the version information doesn't seem to be fully populating. If this approach is standardised across all the PHP modules (5.2? 6.0?) then I'd certainly be in favour of this cleaner method.
Jul 17, 2006
Superbiji
Zend_Environment::getOs();
should also return 'common OS name'
for example, Win XP, Win 2000, Win NT are "Windows"
Sep 25, 2006
Simon Mundy
The API has changed somewhat for Zend_Environment - please review the Use Case above for an example of usage.
Oct 26, 2006
Gavin
Conditionally accepted with the following changes required:
Documentation clarifies the purposes of this class, including a focus on analysis of the environment and reporting in a structure manner, not performance.
Non-trivial errors reported or found by Zend_Environment should include a link to a wiki page, such as: http://framework.zend.com/wiki/display/ZFDEV/Zend_Environment/en/gd-memory-leaks
Zend_Environment will include an option to email the $environment->asArray() to a Zend list (TBD: possibly fw-env), which can be used to help understand common problems and patterns (e.g. the PATH_INFO rewrite router/subdir problem). Zend_Environment will also provide a way to transform the array into a human readable (friendly) format.
Zend_Environment will include an option to calculate a server signature method used to identify changes in the deployment platform. The signature might be created using a checksum of environmental properties.
This component could be used in conjunction with the Zend_Registry_Defaults (global "INI"), such that information from Zend_Environment could be cached and then fed into the registry.
Jul 12, 2007
Darby Felton
Some components make use of UTF-8/Unicode support in PCRE, but such support is not always available.
Please see http://framework.zend.com/issues/browse/ZF-1641 and the affected classes (e.g., Zend_Filter_Alpha) for how we have addressed it so far. You may note that the check for this support occurs on a per-class basis, which is too often. What if you use many classes? Must they all check for this support independently? To do so does not follow the DRY principle. Instead, for classes that need to check for such support, it would be nice to write something simple like:
Though the exact syntax may vary, something simple and similar to the above would allow ZF components and user code to very quickly check such things that may be specific to a particular environment, while meeting the DRY principle better.
Jul 14, 2007
Simon Mundy
Sounds like a great idea. Perhaps a more flexible method would be to create a naming convention either for constants or public properties for Zend_Xxxx components, so that Zend_Environment could check for the existence of a property and then return a boolean.
In Zend_Filter_Alpha and all similar components you could set a property like so:
An advantage to this is that additional properties could be added over time without tying Zend_Environment to a specific implementation. For now it could be as simple as
Sep 24, 2007
Wil Sinclair
Is there a way to override these environment properties? It would be difficult to test applications- and possibly override some unwanted behavior in production- if there isn't such a mechanism. I think be able to shadow them in the config file makes some sense. In fact, since configuration is a part of the environment, one could argue that it would make sense to access all config + environment values through this component. That is a larger discussion, however.
Aug 27, 2008
Stephan Wentz
A method for checking wether the current environment runs in CLI or Web context would be nice. Or is this possible right now?
Oct 31, 2008
Ben Scholzen
True, both should be possible, checking for common OS-Name (or something like $env->isWindows() | $env->isLinux(), etc, and something to check if you are in a webserver- or console (cli/cgi) enviroment.
Dec 24, 2008
Alexander Veremyev
Proposal has been reviewed by Zend team. We have the following notices:
Thus we have made a decision to move current form of the Proposal into Archived.
On the other hand the idea of the component for accessing environment info is really great. So this decision shouldn't stop anyone from re-developing Zend_Environment proposal.