Config, aber wie?

Hallo liebe Leute,

ich würde gerne wissen welche Art von Configuration bei euren Projekten ihr so benutzt und wie ihr Sie verarbeitet.
Bisher habe ich meine config files mit einfachen Konstanten gestaltet und simpel via include eingebunden, sodass sie global verfügbar sind.
Ich plane allerdings grade ein neues Projekt und sammle in diesem Zuge auch ein paar neue Ideen.
Natürlich habe ich schon ein bisschen im Netz gesucht und bin dabei auf ein paar neue Lösungsmöglichkeiten gestossen zu denen ich gerne eure Meinung hören würde.

1. Config Daten als Array
2. Config Daten als Objekt in einer Klasse
3. Die Nutzung von Pear Config mit den Typen
->XML
->Apache
->GenericConf
->IniFile

Über Vorschläge und Lösungsansätze mit eventuellen Beispielen wäre ich sehr dankbar.

A: Sollen die Daten per Script geändert werden können?
B: Sollen die Daten händisch editiert werden können?


Zu 1: Von serialisierten Arrays möchte ich abraten.*
* Ansonsten eine schöne Methode. A und B einfach zu realisieren.


Zu 2: Im Falle eines DI Containers/Factory zu empfehlen, wobei A dann nicht so einfach zu realisieren ist.


Zu 3:
Zend_Config sollte auch erwähnt *werden.




* XML halte ich für fehl am Platze. Es ist ein Datenaustauschformat, speziell für die Übertragung zwischen verschiedenen Systemen. Deine Config bleibt aber auf einem System. Also ein unnötiger Wasserkopf.
Aber ansonsten: A und B leicht realisierbar.




Auch das speichern der Config in sqlite ist möglich.

A: Sollen die Daten per Script geändert werden können?
B: Sollen die Daten händisch editiert werden können?

Beides kann ich mit ja beantworten.

Mit Zend habe ich noch nicht gearbeitet und an SQLite habe ich noch garnicht gedacht, mit beidem werde ich mich erstmal auseinander setzen.

Ich habe mich jetzt entschieden die Config als Klasse zu schreiben.
Joomla löst dies in seiner Config mit var $varname; , soweit ich weiss ist var aber veraltet und wurde durch private etc. ersetzt.

Wäre dann eine config in diesem Stil sinnvoll?

class MyConfig {
public $username = "uname";
public $database = "databla";
.... usw.

}

Nicht wirklich....
A bleibt auf der Strecke.



Was du da baust, sieht ein wenig nach "Registry Design Pattern" aus.*


Public Eigenschaften sind selten sinnvoll.
Machs entweder über Setter/Getter oder implementiere das ArrayAccess Interface.

ähm *räusper*
Also offengesagt kann ich mit den Begriffen "Registry Design Pattern" und "ArrayAccess Interface" nicht soviel anfangen. Ich dreh den Spieß jetzt mal um frage wie du das in deinen Projekten gelöst hast

Die verschiedensten "OOP Design Patern" findest du u.A. bei Wikipedia und das ArrayAccess Interface im PHP Handbuch.


Im Grunde kommen alle genannten Verfahren bei mir zum Einsatz. Halt je nach dem...




Die Array Variante:*

PHP-Code:

<?php
error_reporting(-1);
ini_set('display_errors', TRUE);

function array2phpfile(Array $array, $filename)
{
  $content  = "<\x3fphp \n";
  $content .= "return   \n";
  $content .= var_export($array,TRUE)."; \n";
  file_put_contents($filename,$content);
}

function file2array($filename)
{
 return include $filename;
}

// Testcode
$configdatei = "./config.php"; // Die Datei, wo es dann drin ist

$default = array();
$default['dbserver']    = 'localhost';
$default['dbuser']      = 'willi';
$default['dbpasswort']  = 'qwertzui';
$default['dbank']       = 'datenbank';


if(file_exists($configdatei))
  $zwischenlager = file2array($configdatei);
  else $zwischenlager = $default;

if(!empty($_POST['key']))
{
    $zwischenlager[$_POST['key']]=$_POST['value'];
}

if(!empty($_POST['config']))
{
  foreach($_POST['config'] as $key => $value)
  {
    $zwischenlager[$key]=$value;
  }
}


array2phpfile($zwischenlager,$configdatei);


?>

<form action="" method="post">
<table>
 <tr>
  <th>Key</th>
  <th>Value</th>
 </tr>
<?php
foreach($zwischenlager as $key => $value)
{
  echo '<tr><td>';
  echo  htmlentities($key).'</td><td>'.
        '<input type="text"
                name="config['.htmlentities($key).']"
                value="'.htmlentities($value).'"
         >
         <br /> ';
  echo '</td></tr>';
}
?>
 <tr>
  <td><input type="text" name="key" value=""></td>
  <td><input type="text" name="value" value=""></td>
 </tr>

 <tr>
  <td>&nbsp;</td>
  <td><input type="submit"  value="Speichern"></td>
 </tr>
</table>
</form>

<pre>
<?php print_r($zwischenlager) ?>
</pre>

Die Sternchen musst du dir weg denken, die macht mein Browser leifer da rein.

-->

Ich bin jetzt einen ganz anderen Weg gegangen.
Nach einigem Suchen bin ich auf parse_ini_file gestossen.
Ich finde das ne super Sache, A und B werden erfüllt.
Das ganze bleibt für User lesbar und editierbar.
Ich wundere mich das ich der Funktion noch nie über den Weg gelaufen bin, auf den ersten Blick eine tolle Sache.

Anmerkungen oder Kritik?

Zudem bin ich im Manual auf eine Lösung gestossen die wie für mich gemacht ist. OOP ist allerdings für mich zur Zeit noch Neuland und ich bin grade erst dabei mich da einzuarbeiten.
Aus dem Grund wäre ich Dankbar wenn man mir folgende Klasse aus dem Manual etwas Kommentieren könnte, ich lehne es grundsätzlich ab, code zu verwenden den ich nicht zu hundert Prozent verstehe.

PHP-Code:

class Settings {
    private static $instance;
    private $settings;
    
    
    private function __construct($ini_file) {
        $this->settings = parse_ini_file($ini_file, true);
    }
   
    public static function getInstance($ini_file) {
        if(! isset(self::$instance)) {
            self::$instance = new Settings($ini_file);           
        }
        return self::$instance;
    }
   
    public function __get($setting) {
        if(array_key_exists($setting, $this->settings)) {
            return $this->settings[$setting];
        } else {
            foreach($this->settings as $section) {
                if(array_key_exists($setting, $section)) {
                    return $section[$setting];
                }
            }
        }
    }
} 


Zitat von analyzer

Ich bin jetzt einen ganz anderen Weg gegangen.
Nach einigem Suchen bin ich auf parse_ini_file gestossen.

Das verwende ich schon lange in meinem Frameworkprojekt - einfach optimal, da Anwender problemlos für ihre eigenen Teile hinzufügen und ändern können wie sie wollen. Ist auch relativ unkritisch beim bearbeiten.

Eine config sollte sich danach richten wie weit sie von Anwendern durch eigene Einbauten verändert werden können oder dürfen.

In der Version 2 meiner CMS werde ich das da ebenfalls verwenden.

Zitat von analyzer

Aus dem Grund wäre ich Dankbar wenn man mir folgende Klasse aus dem Manual etwas Kommentieren könnte, ich lehne es grundsätzlich ab, code zu verwenden den ich nicht zu hundert Prozent verstehe.

Das ist ein Singleton mit einem magic Getter.
Da der Konstruktor private ist, kann man nicht direkt eine neue Instanz erzeugen (new Settings() liefert Laufzeitfehler). Man muss die Methode getInstance() aufrufen und die liefert immer das selbe, einzige Settings-Objekt.
Die Methode __get() ist ein Interzeptor, also was PHP-spezifisches, und simuliert sozusagen Getter-Methoden für alle Konfig-Variablen, die in der ini-Datei vorkommen.

Aber: clone() wurde nicht überschrieben, also ist es kein wasserdichtes Singleton; Fehlerbehandlung gibt es auch nicht; und wieso darf es nur einen (Singleton) INI-Reader geben? Ich kenne viele Applikationen, die mit mehreren INI-Dateien arbeiten.

Übrigens ... schau mal ins Zend Framework. Da gibt es einen guten INI-Reader/Writer.

Der Code funzt, auch wenn man alles besser schreiben kann.

Er hat sich auch nicht viel MÜhe gemacht denn er stammt 1:1 von hier:

PHP: parse_ini_file - Manual

Ich habe doch gesagt hab ich aus dem manual, aus den Comments Also bitte keinen code Diebstahl unterstellen

Vielen dank für die Antworten. Ich werde mit mit den beschriebenen Funktionen mal auseinander setzen.

Und vielen Dank an combie für die umfangreiche Hilfe.

Zitat von analyzer

Ich habe doch gesagt hab ich aus dem manual, aus den Comments Also bitte keinen code Diebstahl unterstellen

Nein , wenn da Code gepostet ist immer verwenden wenn man es gebrauchen kann.

Und es ist eine gute Referenz auch wenn andere gleich darüber herfallen.

Ich stand vor dem selben Problem.

Hatte mich zuerst für XML entschieden - da bei meinem CMS jedes Modul eine eigene Config-Datei haben sollte und sich die Strukturen dementsprechend individuel darstellen ließen.

Habe die Config dann aber auf Ini-Dateien umgebaut denn für ein paar Variablen ist XML überproportioniert.