Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<h1><ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[Zend_Environment]]></ac:plain-text-body></ac:macro> Proposal Review</h1>

<ac:macro ac:name="info"><ac:parameter ac:name="title">Proposal Review Period</ac:parameter><ac:rich-text-body>
<p>This proposal is for review until <strong><ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><Unable to render embedded object: File (plain-text-body></ac:macro></strong>. 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 <a><ac:plain-text-body><) not found.[CDATA[10022]]></ac:plain-text-body>">create a new issue</a> in the issue tracker for this project.</p></ac:rich-text-body></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[]]></ac:plain-text-body></ac:macro>
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

]]></ac:plain-text-body></ac:macro>

<ac:macro ac:name="include"><ac:default-parameter>ZFDEV:Zend Proposal Zone Template</ac:default-parameter></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 30, 2006

    <p>Some additional functionality would be great as Zend_Environment <br />
    could be used to get a complete overview of the whole system.</p>

    <p>Gettings configuration values from phpinfo :</p>
    <ul>
    <li>as value / standalone</li>
    <li>as list / blockwise
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    echo Zend_Environment::getConfig('General','include_path');
    // single value
    $configlist = Zend_Environment::getConfig('General');
    // returns the complete General Block as list-array
    ]]></ac:plain-text-body></ac:macro></li>
    </ul>

    <p>Getting settings from php.ini :</p>
    <ul>
    <li>as value / standalone</li>
    <li>as list / blockwise
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    echo Zend_Environment::getPHPIni('max_execution_time');
    // returns f.e. 130
    $list = Zend_Environment::getPHPIni('session*');
    // returns all session settings as list of arrays
    ]]></ac:plain-text-body></ac:macro></li>
    </ul>

    <p>Getting system values:</p>
    <ul>
    <li>memory</li>
    <li>CPU</li>
    <li>network adapter settings</li>
    <li>other hardware settings/values</li>
    <li>process list
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    $settings = Zend_Environment::getSystem('Network');
    // returns all Network Adapter Settings f.e.
    $process = Zend_Environment::getProcess();
    // returns the actual process list from system
    ]]></ac:plain-text-body></ac:macro></li>
    </ul>

    <p>Get version of executables</p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    echo Zend_Environment::getVersion('C:/myprogram/program.exe');
    // returns the version string from exe file
    ]]></ac:plain-text-body></ac:macro>

    <p>Just to count some good functionality which could do well in this class.</p>

    1. Jun 30, 2006

      <p>Hi Thomas - the class already does the first two points:-</p>

      <p>print_r(Zend_Environment::getInfo('general'));<br />
      print_r(Zend_Environment::getInfo('general', 'Configure Command'));<br />
      print_r(Zend_Environment::getInfo('configuration'));<br />
      print_r(Zend_Environment::getInfo('configuration', 'include_path');<br />
      print_r(Zend_Environment::getInfo('modules', 'session');<br />
      print_r(Zend_Environment::getInfo('environment');<br />
      print_r(Zend_Environment::getInfo('environment', 'TERM_PROGRAM');</p>

      <p>...it uses the same options that phpInfo() uses to classify the directives.</p>

      <p>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.</p>

      1. Jun 30, 2006

        <p>Not all settings from php.ini are presented in phpinfo().</p>

        <p>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() )</p>

        <p>What do you mean with "free of extension dependency"...<br />
        Framework Components or PHP Extensions ??</p>

        <p>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.</p>

        1. Jun 30, 2006

          <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[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'))

          Unknown macro: { ...do stuff... }

          I don't think throwing an exception would be required for this kind of operation.]]></ac:plain-text-body></ac:macro>

          1. Jul 01, 2006

            <p>I'm missing f.e. memory_limit and register_long_arrays in phpinfo.<br />
            But I've not crosschecked the whole ini.</p>

            <p>As useable extension I would define all which come with PHP.<br />
            This includes for example the process lib.</p>

            <p>The network settings should be readable with php.<br />
            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 <ac:emoticon ac:name="smile" /></p>

            <p>I think we should include the informations we can get using the php-libs or the ones we could get writing by our own.</p>

            1. Jul 01, 2006

              <p>You can get those with:-</p>

              <p>$core = Zend_Environment::getInfo('configuration', 'php core');<br />
              var_dump($core<ac:link><ri:page ri:content-title="'memory_limit'" /></ac:link>);<br />
              var_dump($core<ac:link><ri:page ri:content-title="'register_long_arrays'" /></ac:link>);</p>

              <p>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.</p>

              1. Jul 01, 2006

                <p>Ok... then when all php.ini settings are coming through phpinfo this should be no problem <ac:emoticon ac:name="smile" /></p>

                <p>Following functions/datas could be nice to know through Zend_Environment</p>

                <ul>
                <li>Network settings :
                <ul>
                <li>Adapter Name</li>
                <li>Mac Adress</li>
                <li>DHCP en-/disables</li>
                <li>DHCP adress</li>
                <li>WINS en-/disabled (primary and secondary)</li>
                <li>WINS adress</li>
                <li>IP Adress</li>
                <li>IP Mask</li>
                <li>Gateway Adress</li>
                <li>DNS Adress</li>
                <li>DNS Name</li>
                <li>Hostname</li>
                <li>Type of Adapter (f.e. Ethernet)</li>
                </ul>
                </li>
                </ul>

                <ul>
                <li>Process functions
                <ul>
                <li>List of running processes</li>
                <li>Memory useage per process (Real/Virtual)</li>
                <li>Used Handles</li>
                <li>Dependent processes</li>
                </ul>
                </li>
                </ul>

                <ul>
                <li>System functions
                <ul>
                <li>Memory useage of whole system</li>
                <li>Additional system informations</li>
                </ul>
                </li>
                </ul>

                <p>I'm sure that not all of this informations are avaiable without extensions, but some should be.</p>

                <p>So someone could make an action depending on a defined system-status.</p>

                <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
                if (Zend_Environment::getSystemMemoryUseage() > 1000000)

                Unknown macro: { print "memory shortage"; }

                echo Zend_Environment::getProcessList();

                if (Zend_Environment::getProcess('MyProcess') > 100000)

                Unknown macro: { MyClass}

                echo 'Network Status:';
                echo 'DHCP:'.Zend_Environment::isDHCP();
                echo 'My Hostname:'.Zend_Environment::ownHostname();
                echo 'Own IP:'.Zend_Environment::ownIPAdress();
                ]]></ac:plain-text-body></ac:macro>

  2. Jun 30, 2006

    <p>I think it could returns informations about Zend Framework components too.</p>

    1. Jun 30, 2006

      <p>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?</p>

      1. Jun 30, 2006

        <p>I think that not every component should have a own version number.<br />
        But the whole framework should have one.</p>

  3. Jul 05, 2006

    <p>I think, the better is to use the ReflectionExtension() and get_loaded_extensions() instead of parsing output from phpinfo().</p>

    1. Jul 06, 2006

      <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[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..

      Unknown macro: {/code}

      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.]]></ac:plain-text-body></ac:macro>

  4. Jul 17, 2006

    <p>Zend_Environment::getOs();</p>

    <p>should also return 'common OS name'<br />
    for example, Win XP, Win 2000, Win NT are "Windows"</p>

  5. Sep 25, 2006

    <p>The API has changed somewhat for Zend_Environment - please review the Use Case above for an example of usage.</p>

  6. Oct 26, 2006

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Feedback</ac:parameter><ac:rich-text-body><p>Conditionally accepted with the following changes required:</p>

    <p>Documentation clarifies the purposes of this class, including a focus on analysis of the environment and reporting in a structure manner, not performance.<br />
    Non-trivial errors reported or found by Zend_Environment should include a link to a wiki page, such as:
    <a class="external-link" href="http://framework.zend.com/wiki/display/ZFDEV/Zend_Environment/en/gd-memory-leaks">http://framework.zend.com/wiki/display/ZFDEV/Zend_Environment/en/gd-memory-leaks</a></p>

    <p>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.</p>

    <p>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.</p></ac:rich-text-body></ac:macro>
    <ac:macro ac:name="info"><ac:rich-text-body>
    <p>Notes: If used with production applications, this class could be combined with Zend_Cache or similar to address performance concerns.</p>

    <p>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.</p></ac:rich-text-body></ac:macro>

  7. Jul 12, 2007

    <p>Some components make use of UTF-8/Unicode support in PCRE, but such support is not always available.</p>

    <p>Please see <a class="external-link" href="http://framework.zend.com/issues/browse/ZF-1641">http://framework.zend.com/issues/browse/ZF-1641</a> 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:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    if (Zend_Environment::supports('pcre.unicode')) {
    // ...
    ]]></ac:plain-text-body></ac:macro>

    <p>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.</p>

    1. Jul 14, 2007

      <p>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.</p>

      <p>In Zend_Filter_Alpha and all similar components you could set a property like so:</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      const ZFPROP_UNICODE = 1
      ]]></ac:plain-text-body></ac:macro>

      <p>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</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      if (Zend_Environment::hasProperty('Zend_Filter_Alpha', 'unicode')) ... // checks class

      or

      if (Zend_Environment::hasProperty($this, 'unicode')) ... // checks instance
      ]]></ac:plain-text-body></ac:macro>

  8. Sep 24, 2007

    <p>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.</p>

  9. Aug 27, 2008

    <p>A method for checking wether the current environment runs in CLI or Web context would be nice. Or is this possible right now?</p>

  10. Oct 31, 2008

    <p>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.</p>

  11. Dec 24, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>Proposal has been reviewed by Zend team. We have the following notices:</p>
    <ul>
    <li>Offered implementation (with parsing phpinfo() output) will be really slow in comparison to corresponding ini_get() (and others) calls.</li>
    <li>Proposal should describe its goals and problems it intended to resolve. Should it be used in production/development environment/at deployment stage/...?</li>
    <li>Nature of the component implicates future extending (to access additional information retrieved not only from phpinfo()). Proposal should describe rules for such extending to provide unified API (or at least completely describe existing API).</li>
    <li>We don't think it's necessary to have decorators for this component.</li>
    <li>Offered implementation will not work in command line (phpinfo() has plain text output there).</li>
    </ul>

    <p>Thus we have made a decision to move current form of the Proposal into Archived.</p>

    <p>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.</p></ac:rich-text-body></ac:macro>