Config object

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Config object

Post by alex.barylski »

First have a look at Zend Config object...

Nice eh? two problems:

1) XML, INI and PHP formats are supported
2) Doesn't support saving, it's outside of Zend's scope (currently)

I've searched the net high and dry for others and have yet to find anything half fast decent.

To add to my own library of code I shall write my own.

Before I do so, I have some ideas which would make a config object more uesful, but would like to hear your input first.

I can hear your aguments already:
1) Q: Hockey, just write your own driver for the Zend config and be done with it.
A: Sure, could do that, but Zend should do that...besides they use alot of (current, maybe, perhaps) words in there docs which suggest instabilitly.

2) Q: Saving isn't an essential feature of Config object.
A: Why not? I ran a poll a while back on this subject and it appears to be quite the split of opinion.

What are some features you think you'd find useful in a config object - as complicated as it is :P

Although Zend says saving is out of the scope and I beg to differ, please keep in mind this is *just* a config object, not a registry or similar object. Ideally it should work with any number of configuration file(s) from XML to Windows registry maybe, who knows. Perhaps LDAP?

Anyways, incase I've missed anything for a trivial object like this, what are some do's and don'ts you feel are justified?

Cheers :)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

- Have the configuration object automatically document itself and enforce constraints
- Allow extensions to register new configuration values in a sane way

:?:
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Ambush Commander wrote:- Have the configuration object automatically document itself and enforce constraints
- Allow extensions to register new configuration values in a sane way

:?:
I'm interested in hearing more about option 1) as I don't think I follow you 100%.

Enforce constraints??? You mean like linear data storage only, or fixed depth in structured storage?

By automatically document itself??? how do you mean, like transaction support, so you can undo?

As for the extensions, I'm not sure I'm totally clear how you or d11 are using extensions...I'm sure it's just a difference of vocabulary, but incase were not on the same page, can you show me an brief example, using Zend_Config_INI as an example?

How you would use an extension to modify the schema or a config repository?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

I think the approach is that Config values are imported from an external source, and then remain immutable - i.e. cannot be changed by client code. This prevents possible contamination of the original config values by other code.

Changing the values depends on your approach. If it's relatively infrequent - setup/admin changes/other - then simply create a Config_Writer set of classes mirroring your source formats which can import a typical Config object, change internal values, and write new source copies.

Supporting new formats (YAML for example) isn't very difficult.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Enforce constraints??? You mean like linear data storage only, or fixed depth in structured storage?
Like a certain configuration value must be an integer or (insert datatype here).
By automatically document itself??? how do you mean, like transaction support, so you can undo?
You want to tell users how to configure the application. So the configuration object should be able to interrogated for all the necessary information needed to build that documentation.
Changing the values depends on your approach. If it's relatively infrequent - setup/admin changes/other - then simply create a Config_Writer set of classes mirroring your source formats which can import a typical Config object, change internal values, and write new source copies.
I don't like this approach because I like to use one configuration file that autodetects the correct values for multiple setups. It make debugging a lot simpler, because all installs are using the same configuration file.
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

One way to do configurations, done in Prado, is to use objects as configuration, e.g.

Code: Select all

class BarConfig
{
    private $_propA;
    private $_foo;
    private $_moo='Cow';

    function init($config)
   {
   }

    function setPropA($value)
    {
         $this->_propA = TPropertyValue::ensureInteger($value);    
    } 

    function getPropA()
   {
        return $this->_propA;
   }

   function setFoo($value)
  {
      if($value instanceof FooConfig)
         $this->_foo=$value;
      else
         $this->_foo = ConfigRegistry::findConfigByID($value);
  }
  
  function getMoo()
 {
    return $this->_moo;
 }

  function setMoo($value)
  {
      $this->_moo = $value;
  }
}
and allow the class to be configured using other mean, such as using xml (parsing it using simplexml, and assume setter method name derived element attribute names).

e.g.

Code: Select all

<properties>
  <property class="BarConfig" PropA="1" />
</properties>
A registry may be used to hold the configuration objects as well.

quite flexiable and extendable, such as allowing property of properties, inheritance, etc. The default values are basically, the values defined in the object. Documentation is done by documenting the config classes.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Singleton class that implements __sleep(), __wakeup(), save(), load() and possibly setPath() and saves all its properties. You could put all the properties in an internal array by using __get and __set if you needed to isolate properties storing configuration data from those storing configuration state.

I do likes mi magic methods :)
Post Reply