Config verschachtelt

[MB]

moin Community,

nach längerem tüfteln ist ein mögliches Problem aufgetaucht. Ich muss nämlich bestimmte Objekte, Arrays in eine Config schmeißen. Als beispiel nehme ich die Database konfiguration:

Ich könnte die Konfiguration in Strings ablegen, die Kategorie vorangestellt:

Config::set( 'DATABASE_DRIVER','mysql' );
Config::set( 'DATABASE_HOST', 'localhost' );
Config::set( 'DATABASE_DBNAME', 'mydb' );
Config::set( 'DATABASE_USER', 'root' );
Config::set( 'DATABASE_PASSWORD', '' );

ich kann das auch als array ablegen

Config::set( 'database', [
  'driver'  => 'mysql',
  'host'    => 'localhost',
  'dbname'  => 'mydb',
  'user'    => 'root',
  'password'=> '',
] );

oder in Strings

Config::set( [ 'database' ][ 'driver' ],   'mysql' );
Config::set( [ 'database' ][ 'host' ],     'localhost' );
Config::set( [ 'database' ][ 'dbname' ],   'mydb' );
Config::set( [ 'database' ][ 'user' ],     'root' );
Config::set( [ 'database' ][ 'password' ], '' );

oder eben in ein Objekt

Config::set( 'DATABASE', new \Type\Database(
  'mysql', 'localhost', 'mydb', 'root', '' 
) );

Wärend ich weiter programmieren würde, würden noch mehr Verschachtelungen auftauchen z.B. Message mit z.B. category -> subject -> message

dann würde ich das wie im Thread Konfiguration auslagern machen. Da hat man erstmal den ersten Eintrag category in meinem Beispiel wech, aber da sind Untereinträge die einem ein Array mit Subarrays aufzwingen.

ein einfaches define( 'KATEGORY_SUBKATEGORY_SUBJECT_MESSAGE', $something ) um dieses zu lösen finde ich nicht förderlich. Da passt mir schon die statischen Klassen Programmlogik intern besser. Aber da habe ich dieses besagte Problem 😕.

Ist das jedem Projekt selbst überlassen oder steckte eine Konvention hinter?

vlg MB

[dedlfix]

Tach!

Ist das jedem Projekt selbst überlassen oder steckte eine Konvention hinter?

Mir ist da keine Konvention bekannt. Nimm Objekte, die lassen sich von der IDE autovervollständigen. Generell die Empfehlung, wann immer die Struktur feststeht, nimm Klassen/Objekte statt assoziativer Arrays. Solche Arrays (oder anderenorts Dictionarys) haben keinen Vorteil bei der Ausführung, nur den Nachteil der schlechten Unterstüzung seitens der IDE. Eine Datenbankklasse braucht zum Beispiel stets den Hostnamen, Usernamen und Passwort, also kannst du da eine vordefinierte Konfigurationswerteklasse nehmen statt einem Array mit "Magic Strings" als Bezeichner. Ein Zugriff auf nicht vorhandene Objekteigenschaften kann die IDE erkennen, Zugriff auf nicht vorhandene Array-Elemente, beispielsweise wegen Tippfehler im Feldnamen, kann sie nicht erkennen.

dedlfix.

[MB]

moin dedlfix,

Mir ist da keine Konvention bekannt. Nimm Objekte, die lassen sich von der IDE autovervollständigen.

ok

Generell die Empfehlung, wann immer die Struktur feststeht, nimm Klassen/Objekte statt assoziativer Arrays.

Danke für den Rat, werde ich machen. Kannst du mir n kleines Anwendungsbeispiel geben. Metasyntaktische variabel reichen.

also kannst du da eine vordefinierte Konfigurationswerteklasse nehmen statt einem Array mit "Magic Strings" als Bezeichner.

was sind Array mit "Magic Strings"?

vlg MB

[dedlfix]

Tach!

Generell die Empfehlung, wann immer die Struktur feststeht, nimm Klassen/Objekte statt assoziativer Arrays.

Danke für den Rat, werde ich machen. Kannst du mir n kleines Anwendungsbeispiel geben. Metasyntaktische variabel reichen.

Hab ich doch schon erwähnt. Eine Datenbankzugangskonfiguration ist beispielsweise feststehend. Du brauchst den Hostnamen, den Datenbanknamen, den Usernamen, das Passwort. Diese Angaben brauchst du immer. Es ist nicht so, dass da noch beliebige weitere Felder hinzukommen, deren Namen du erst zur Laufzeit kennst. Also kannst du dafür eine Klasse erstellen. Als Leser sieht man dann auch anhand des Codes der Klasse, was konkret für Felder da sind und braucht nicht noch eine zusätzliche Dokumentation, die die Namen der erwarteten Felder auflistet. Und wie auch gesagt, die IDE kann diese Klassendefinition lesen und weiß, welche Felder sie dir zum Autovervollständigen anbieten kann und auch zur Prüfung auf im Code erkennbare (Tipp)Fehler nehmen kann.

was sind Array mit "Magic Strings"?

Wenn du einen String verwenden musst, um dein Programm zu steuern, dann ist das ein Magic String. Nur mit dem richtigen String kommst du voran. Wenn du auf deine Konfigurationswerte zugreifen möchtest, die in einem assoziativen Array abgelegt sind, musst du den passenden Namen als String angeben, um auf das richtige Feld zugreifen zu können. Strings sind normalerweise Datentypen, du verwendest sie aber als Bezeichner. Und wenn du dich vertippst, merkst du das erst zur Laufzeit, weil der Zugriff fehlschlägt. Ein ordentlicher Bezeichner (z.B. Eigenschaftenname einer Klasse) kann von der IDE schon während der Codeeingabe erkannt werden und auch wenn es einen solchen wegen Tippfehler nicht gibt.

dedlfix.

[MB]

moin dedlfix

Generell die Empfehlung, wann immer die Struktur feststeht, nimm Klassen/Objekte statt assoziativer Arrays.

Danke für den Rat, werde ich machen. Kannst du mir n kleines Anwendungsbeispiel geben. Metasyntaktische variabel reichen.

Hab ich doch schon erwähnt. Eine Datenbankzugangskonfiguration ist beispielsweise feststehend.

ach, da bist du! Ja, habe ich auf dem Schirm. Wusste nicht, dass du darauf Bezug nimmst.

was sind Array mit "Magic Strings"?

Wenn du einen String verwenden musst, um dein Programm zu steuern, dann ist das ein Magic String.

Aso, ok Danke Dir.

vlg MB

[pl]

Strukturen im Namen abzubilden ist schlecht. Also statt

'DATABASE_DRIVER','mysql'

ist [ 'database' ][ 'driver' ], 'mysql' zu bevorzugen. Ich würde sogar einen Schritt weiter gehen und für jede zu konfigurierende DB-Verbindung einen unabhängigen Namen festlegen. z.B. so:

[webdaten]
base = myweb
user
pass
port
host
..

Dann reicht ein Aufruf $this->pdo('webdaten') zum Herstellen einer Verbindung. Die Methode pdo() weiß selbst wo sie die Konfigdaten+Credentials findet.

MfG

[MB]

moin pl,

wie im vorherigen Thread gesagt, ich möchte das die Konfiguration in der Programlokig selbst ist und nicht extern. Aber danke für den Rat es nicht üver strings sonder über Arrays zu machen :).

vlg MB

[pl]

Mahlzeit,

wie im vorherigen Thread gesagt, ich möchte das die Konfiguration in der Programlokig selbst ist und nicht extern. Aber danke für den Rat es nicht üver strings sonder über Arrays zu machen :).

Keine Ursache 😉

Der Grund ist die direkte Adressierbarkeit. Einen String hingegen musst Du erst zerlegen. Wie sagte doch Niklaus Wirth bereits 1980 so schön:

Sequenzen werden sequentiell erzeugt und sequentiell gelesen. Ein wahlfreier Zugriff (Random Access) jedoch findet nicht in Sequenzen sondern im Hauptspeicher statt. Es gibt Algorithmen die zwischen diesen beiden Sachverhalten vermitteln.

Und daß Konfigurationsdateien auch nur Sequenzen sind sollte klar sein 😉

MfG