Page 1 of 1

Config object

Posted: Mon Sep 25, 2006 7:44 pm
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 :)

Posted: Mon Sep 25, 2006 8:41 pm
by Ambush Commander
- Have the configuration object automatically document itself and enforce constraints
- Allow extensions to register new configuration values in a sane way

:?:

Posted: Mon Sep 25, 2006 9:25 pm
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?

Posted: Tue Sep 26, 2006 3:16 am
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.

Posted: Tue Sep 26, 2006 7:44 pm
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.

Posted: Wed Sep 27, 2006 12:29 am
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.

Posted: Sat Sep 30, 2006 5:54 pm
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 :)