Labels
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
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.
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.
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.
3 more comments by: Simon Mundy, Thomas Weidner
I think it could returns informations about Zend Framework components too.
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?
I think, the better is to use the ReflectionExtension() and get_loaded_extensions() instead of parsing output from phpinfo().
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.
ZF Home Page
Code Browser
Wiki Dashboard
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.