Skip to end of metadata
Go to start of metadata

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

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

Zend Framework: Zend_Config_Writer Component Proposal

Proposed Component Name Zend_Config_Writer
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Config_Writer
Proposers Ben Scholzen
Zend Liaison Ralph Schindler
Revision 1.0 - 1 October 2008: Initial Draft.
1.1 - 1 October 2008: Refactored proposal to use Zend_Config only as sources. (wiki revision: 16)

Table of Contents

1. Overview

Zend_Config_Writer is an addition to Zend_Config to write config objects back to files. It can take any Zend_Config object and save it with one of the adapters. Slight additions are required in Zend_Config for this.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will be able to create new config files.
  • This component will be able to write INI as well as XML config files
  • This component will support (extending) sections
  • This component will output the data in a generic format
  • This component will not preserve formatting or comments in existing config files when rewriting them

4. Dependencies on Other Framework Components

  • Zend_Config
  • Zend_Config_Xml
  • Zend_Config_Ini
  • Zend_Config_Exception

5. Theory of Operation

First an instance of Zend_Config is created. Then modifications are directly done on this instance. After that an instance of Zend_Config_Writer_Interface is created. Then the modifications can be saved by calling Zend_Config_Writer_Interface::write();

6. Milestones / Tasks

  • Milestone 1: [DONE] Finishing proposal
  • Milestone 2: [DONE] Collecting community comments
  • Milestone 3: [DONE] Approval by Zend
  • Milestone 4: [DONE] Prototype finished and checked into SVN
  • Milestone 5: [DONE] Unit tests exist, work, and are checked into SVN.
  • Milestone 6: [DONE] Initial documentation exists.

7. Class Index

  • Zend_Config_Writer
  • Zend_Config_Writer_Exception
  • Zend_Config_Writer_Interface
  • Zend_Config_Writer_Xml
  • Zend_Config_Writer_Ini

8. Use Cases

UC-01

Creating a new config file

UC-02

Updating an existing config file

UC-03

Cloning a section and resetting extend parameter

UC-04

Converting an INI to an XML config file

9. Class Skeletons

]]></ac:plain-text-body></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. Oct 01, 2008

    <p>Perhaps it would be a nice addition to allow for a parameter to update existing files? If you would want to do this, I've written this functionality for INI files: <a class="external-link" href="http://gitorious.org/projects/vogel/repos/mainline/blobs/master/project%2Flibrary%2FVogel%2FConfig%2FIni.php">http://gitorious.org/projects/vogel/repos/mainline/blobs/master/project%2Flibrary%2FVogel%2FConfig%2FIni.php</a></p>

    <p>Supporting this for XML should be fairly easy I suppose. Then again, if new formats are to be supported in the future a Writer interface would also have to be written so it might not be that good an idea.</p>

    <p>Anyway, I'm eagerly awaiting this component <ac:emoticon ac:name="smile" /></p>

    1. Oct 01, 2008

      <p>Updating existing configs will be possible.</p>

      1. Oct 01, 2008

        <p>Sorry, I should have phrased that differently. I meant updating not as in "creating a new config and saving it over the current one" but updating as in "updating the config line by line, thus preserving comments" <ac:emoticon ac:name="wink" /></p>

        1. Oct 01, 2008

          <p>Well for that use file() and file_put_contents() ;></p>

          1. Oct 01, 2008

            <p>How does that preserve comments? The requirements, constraints and acceptance criteria currently lists:</p>

            <ul>
            <li>This component will not preserve formatting or comments in existing config files when rewriting them</li>
            </ul>

            <p>What I was saying is that perhaps you can change "will not" to "will" using my existing class. <ac:emoticon ac:name="smile" /></p>

            1. Oct 01, 2008

              <p>Sorry nope, as the adapters have to extend the Zend_Config readers, so when something in the read-structure changed, the writers dont have to be updated as well. Thus Zend_Config_Writer_Xml will use simplexml, which doesnt know about formatting and comments.</p>

        2. Oct 01, 2008

          <p>Also, you probably want to put those always changing config settings in a separated config file, to keep the user-modified config files clean.</p>

  2. Oct 01, 2008

    <p>$vote++</p>

    <p>Feature request for the proposals wiki: a vote counter <ac:emoticon ac:name="wink" /></p>

  3. Oct 01, 2008

    <p>I don't see why Zend_Config_Writer should be able to read config files. The way I see it, Zend_Config_Writer should <em>only</em> know about Zend_Config, that is; it should only deal with reading an in-memory config object.</p>

    <p>Further on, there should be reader classes for config files. Instead of having two classes Zend_Config_Ini and Zend_Config_Xml that extend Zend_Config, there should be two classes Zend_Config_Reader_Ini and Zend_Config_Reader_Xml (or Zend_Config_IniReader and Zend_Config_XmlReader) which implements a Zend_Config_Reader_Interface (or Zend_Config_IReader). This would separate reader and writer logic, and keep Zend_Config itself as slim as possible.</p>

    <p>Generally, the API would be way cleaner this way, and it would be clearer what components to use, and why/where to extend the various classes. If reading and writing are separated to their own classes, the only reason for extending Zend_Config would be to add logic to the actual configuration handling (e.g. filtering and validation), which in my opinion is what it should be used for. Having child classes of Zend_Config for reading various formats doesn't make any sense, because they act <em>exactly</em> like Zend_Config once instantiated. Also, having reading in Zend_Config_Xml and writing in Zend_Config_Writer_Xml might be confusing on a semantic level.</p>

    1. Oct 01, 2008

      <p>This comment goes a bit offtopic, doesnt it? Refactoring Zend_Config itself is a BC break, which can only be done with ZF 2.0.</p>

      <p>As for why Zend_Config_Writer must be able to read config files: Zend_Config_Writer works with raw data, while Zend_Config works with processed data. Those processed data can't be used to write a raw config file.</p>