Skip to end of metadata
Go to start of metadata


<p>This page contains information not otherwise found in the <a href="">issue tracker</a>, especially for proposed improvements and notes on design decisions.</p>

<ac:macro ac:name="toc-zone"><ac:parameter ac:name="location">top</ac:parameter><ac:parameter ac:name="type">list</ac:parameter><ac:parameter ac:name="minlevel">3</ac:parameter><ac:parameter ac:name="indent">20px</ac:parameter><ac:parameter ac:name="printable">true</ac:parameter><ac:rich-text-body>

<h3>Allow loading of multiple sections</h3>

<p>Adapters could allow the section specification parameter to be <code>mixed</code>:</p>

<li><code>string</code> - Names a single section to be loaded (currently supported)</li>
<li><code>array</code> - Array of strings, which are the names of multiple sections to be loaded</li>
<li><code>null</code> - Indicates that all sections should be loaded</li>

<p>Implementing this would mean:</p>

<li>Adding a <code>getSectionName()</code> method would no longer be semantically appropriate</li>
<li>First level properties would correspond with section names (e.g., $config->sectionName)</li>

<p>See <a href="">ZF-413</a></p>

<h3>Add <code>getSectionName()</code> method</h3>

<p>This is in order to easily retrieve the configuration data section name upon demand without having to store it outside the class or create an extending class. This is particularly useful where a Zend_Config object instance is stored and fetched using an application registry.</p>

<h3>Add <code>getWithDefault()</code> method</h3>

<p>Ability to simplify:</p>

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$dbName = $config->db->name ? $config->db->name : 'default';

<p>Not sure how function signature would look though.</p>

<p>See <a href="">ZF-414</a></p>

<h3>Test for circular section extension in adapters</h3>

<p>A configuration data section may inherit from another section, but an exception should be thrown where circular inheritance is detected by the storage adapter.</p>

<p>See <a href="">ZF-415</a></p>

<h3>Remove Zend_Config_Array</h3>

<p>The current version of Zend_Config may be instantiated with an array of configuration data. Zend_Config_Array is no longer necessary, since its only added value is that it loads a specified file, and it rather arbitarily requires that the array be named <code>$config</code>.</p>

<p>See <a href="">ZF-416</a></p>

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Aug 16, 2006

    <p>getWithDefault() could be: get($name, $default = null)</p>

  2. Sep 29, 2006

    <p>Re loading of multiple sections:</p>

    <p>I think that getSectionName() would still be useful as it would still contain what was loaded. Instead of just returning a string, it would return a string, an array of string or null. (i.e. the same as what was used to load the config originally.)</p>

  3. Jan 07, 2007

    <p>Is the plan for there to be an ->update() function that writes to the ini or xml config file? What is the $allowModifications actually for?</p>

    <p>This would be useful for installing a cms (like the one I'm writing at the moment). At the end of the install process you will have tested the db connections etc provided by the user and could now safely write the config file... but alas, zend config doesn't do it. Yet?</p>

    <p>Also, in my cms I have a flag in the config file called site.downForMaintenance which lets me gracefully tell the user that the site is down before trying to connect to non existant db's etc. </p>

    <p>It would be nice to be able to trigger that from the backend without having to write a fwrite function to go and do it for me.</p>

    <p>Thanks! ZF rocks the party!</p>

    1. Feb 11, 2007

      <p>Hi Jonathan,</p>

      <p>$allowModifications determines whether the $config object that has been loaded can be modified.</p>



  4. Jan 07, 2007

    <p>Not sure how I get to the uber leet status of someone who can report bugs, but I just noticed that in 0.60 (dont know if this is a new thing, assume not) that an exclamation mark in the config file comments cause it to throw a warning.</p>

    <p>For example</p>
    <li>This is a test comment!</li>


    <p>// This is a test comment!</p>

    <p>Both throw a warning:</p>

    <p>Warning: Error parsing ./application/config.ini on line 23 in /var/www/clarity/library/Zend/Config/Ini.php on line 73</p>

    <p>Thanks again!</p>


    1. Jan 07, 2007

      <p>That'll teach me to preview...</p>

      <li>This is a test comment!</li>

      <p>was meant to be:</p>

      <p># This is a test comment!</p>

      <p>Wiki Markup actually means something... <ac:emoticon ac:name="wink" /> </p>

      <p>J. </p>

      1. Jan 07, 2007

        <p>I actually started my post (below) before you wrote this! I should type faster <ac:emoticon ac:name="smile" /></p>

    2. Jan 07, 2007

      <p>Hi Jonathan,</p>

      <p>Thanks for the report!</p>

      <p>Can you provide a minimal complete config file that does this? </p>

      <p>From the PHP manual for parse_ini_file, comments start with a ; (semi colon) rather than a // so I suspect that the problem you are seeing is due to that.</p>



      1. Jan 08, 2007

        <p>Hi Rob</p>

        <p>Yup, you're right... it parses fine with the ; as the commenter.</p>

        <p>I also realise that the strange behaviour I'm seeing with the # and // commenting is probably just parse_ini_file() ignoring lines that it can't make sense of... Although one would expect a parse error since when I print_r($config) I don't see any remnants of my commenting in the config array.</p>

        <p>Technically I guess this could be considered a parse_ini_file() bug as you would expect it to throw an error/warning when it tries to parse a config file like this:</p>
        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[

        1. These lines should make no sense to php_ini_file() and one would
          // expect them to throw an error but they don't.
        1. This line will! due to the exclamation mark

        <p>As you can imagine this behaviour can be confusing to a developer who thinks that their #'s are commenting.</p>

        <p>Also Rob, do you have an answer for my first question re writing back to config files?</p>

        <p>Thanks again,<br />

        1. Jan 08, 2007

          <p>Hi Jonathan,</p>

          <p>Zend_Config itself is very unlikely to ever have write back capabilites. I expect that at some point someone will write a Zend_Config_Writer though.</p>



  5. Jun 27, 2008

    <p>Hi All..</p>

    <p>Funny Rob should mention Zend_Config_Writer ive been needing to write back Xml files and have knocked up a very simple Config_Xml_Writer class to extend the Config_Xml class</p>

    <p>So far it has proved very useful in writing Config data back to an XML file.. </p>

    <p>I thought that other may also benefit from it if they are stuck for writing one themselves. its not 100% but its simple enough to read and tweak.</p>

    <p>The source is posted at</p>


  6. Jan 31, 2009

    <p>> getWithDefault() could be: get($name, $default = null)</p>

    <p>+1 for this option - I think this is the more flexible (no BC break) and the easiest to use. I would like this kind of improvment in this component.</p>

    <p>Moreover, it would be extremely simple to implement.</p>