Frage zu Handling von Config - Einträge (Allgemeines zu Perl)

[thread]20625[/thread]

Frage zu Handling von Config - Einträge

Tags: perl5 Ähnliche Threads

Leser: 12

Articles: hide open all | hide show old branches

+3 replies
YAPD

2019-06-06 19:59
User since
2015-09-20
146 Artikel
BenutzerIn
Hallo Zusammen,

nach einem regen Austausch mit HAJ ( danke nochmal ), der mir riet,
meine alte Idee zu verwerfen und mit Moose zu arbeiten,
habe ich mir das Modul nun genauer angesehen. Natürlich habe ich noch
einiges zu lernen aber ich habe bereits eine Verständnisfrage, bei der
ihr mir vielleicht weiterhelfen könnt. :)

Ich habe zur Zeit 3 Files :

1. Installer.pl -> Grunddatei zum Starten der Anwendung
Code: (dl )

1 2 3 4 5 6 7 8 9 10 11 12

use Moose; use Kernel::Config; # ------------------------------------------------------------------------ my %Config = Kernel::Config -> Config_Loader( ); print "Value des Config - Objekts : $Config{ 'DB_Handle' }"; # ------------------------------------------------------------------------- 1;
Hier lädt er das Config - Modul & stellt die Ergebnisse als Hash zur Verfügung,
auf die ich mit
Code: (dl )

$Config{ 'Werte des Hashs aus der Config' }
zugreifen kann.

___________________________________________________________________________________________

2. Die Config.pm
Code: (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

package Kernel::Config; use Moose; extends 'Kernel::Config::Defaults'; # ------------------------------------------------------------------------ sub Config_Loader { my %Config_Werte = ( Home => 'C:\Scripts\Aktuell' ); my $Defaults_Handler = Kernel::Config::Defaults -> new( ) ; my $Defaults_Referenz = $Defaults_Handler -> Load_Defaults( ) ; my %Defaults_Werte = %$Defaults_Referenz; # print "@{[ %Defaults_Werte ]}"; return( %Defaults_Werte ); } # -------------------------------------------------------------------------------- no Moose; # --------------------------------------------------------------------------------- __PACKAGE__ -> meta -> make_immutable;
Die Variable "Home" im Hash "%Config_Werte" ist äußerst wichtig, da sie
den Basispfad für die ganze Anwendung angibt, sie muss anpassbar sein
und wird überall verwendet, bzw. soll verwendet werden.

Dies ist auch der einzige Wert, der wirklich in der Config.pm steht, alle
anderen Config - Einträge stehen in der Datei "Defaults.pm", die ich mit
Code: (dl )

my $Defaults_Handler = Kernel::Config::Defaults -> new( ) ;
initialisiere.

Dann lade ich alle Config - Einträge mit :
Code: (dl )

$Defaults_Referenz = $Defaults_Handler -> Load_Defaults( );
Ich dereferenziere noch den Hash und gebe die Ergebnise als Hash zurück :
Code: (dl )

1 2 3

my %Defaults_Werte = %$Defaults_Referenz; return( %Defaults_Werte );
___________________________________________________________________________________________

3. Die Defaults.pm
Code: (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

package Kernel::Config::Defaults; use Moose; # -------------------------------------------------------------------------------------------------------------------------------------------------------- sub Load_Defaults { my %DB_Connection = ( DB_Handle => 'Microsoft SQL Server' ); if ( -e "C:/Scripts/Aktuell/Kernel/Config/Files" ) { print "Positive Erkennung des Config - Files Ordners ..." , "\n"; } return { %{ \%DB_Connection } } }; # -------------------------------------------------------------------------------------------------------------------------------------------------------- no Moose; # -------------------------------------------------------------------------------------------------------------------------------------------------------- __PACKAGE__ -> meta -> make_immutable; 1;
Hier komme alle Config - Einträge rein, ungefähr 200 oder mehr, die ich wie
beschrieben aufrufen kann.

___________________________________________________________________________________________

DAS PROBLEM

Ich hatte vorher eine Config - Datei, in der die Config - Einträge in folgendem Format standen :
Code: (dl )

1 2 3

$Self -> { Database } = 'Bezeichnung der DB'; $Self -> { DatabaseUser } = 'Standard User'; $Self -> { DatabasePw } = 'XXXXXXXX';
anstatt akuell als Hash :
Code: (dl )

my %DB_Connection = ( DB_Handle => 'Microsoft SQL Server' );
Und bei Prüfung des Verzeichnis für das Verzeichnis "C:/Scripts/Aktuell/Kernel/Config/Files" wurde anstatt
Code: (dl )

-e "C:/Scripts/Aktuell/Kernel/Config/Files/"
folgender Code verwendet :
Code: (dl )

-e "$Self->{Home}/Kernel/Config/Files/"
Dies war so weil in der alten Config.pm die Variable "$Self->{Home}" auch so definiert war, anstatt aktuell als Hash.

DIE FRAGE

Ich möchte nun, dass :

1. ihr mir grundsätzlich sagt, ob es sinnvoll ist, es wieder auf diese Art zu handlen, oder ob ich es bei
Hashes belassen soll wie es ist. Wenn ich wieder das Format "$Self->{Home}" verwendet soll, kriege ich
das nicht bewerkstelligt mit Self und dem Hash. :/

2. das Script wenn die Prüfung erfolgreich ist, also das o. g. Verzeichnis existiert, alle .PM Dateien in
dem Ordner wiederum reinlädt und die Variablen übergibt ( entweder auch Hashes oder "$Self -> < Parameter >"

Ich verwende das so, weil ich es nicht so schreiben konnte ( aufgrund Unwissen wahrscheinlich ), dass Moose
in einem "has" Befehl z. B. 20 Variablen enthält. Ich würde es auch ungern als Sub - Routine oder ähnliches
machen. Oder könnt ihr mir sagen, wie ich das bewerkstellige, eine Config - Datei mit sehr vielen Parametern
als Moose has Objekt ???

Ich hoffe ihr könnt mir helfen und erwarte sehnsüchtig Eure Antwort. :) XD

Viele Grüße
YAPD
Last edited: 2019-06-06 20:18:02 +0200 (CEST)
Yet Another Perl Developer
- rosti
  
  2019-06-07 06:48
  
  User since
  2011-03-19
  3472 Artikel
  BenutzerIn
  
  In Konfigurationsdateien sind Perlvariablen unüblich. Von daher sind Konfigurationsdateien auch keine *.pm sondern *.ini, *.xml usw. also von der Programmiersprache unabhängig.
  
  Und wenn eine Konfiguration mit mehreren 1000 Einträgen aus verständlichen Gründen als .ini, .xml, .json usw. nicht mehr performant ist, wird sie in ein maschinenlesbares Format umserialisiert. So habe ich z.B. seit Jahrzehnten eine Konfigdatei mit mehr als 1 MB und dafür einen eigenenen Serialize Algorithmus in verschiedenen Programmiersprachen (Perl, PHP, C, JavaScript).
  
  So ist eine INI menschenlesbar und damit zur Bearbeitung vorgesehen. Die Binärdatei hingegen ist maschinenlesbar und aus Performancegründen wird nicht die INI sondern die Binärdatei deployed. Daher auch meine Erfahrung daß Konfigurationsdateien als Perldateien ineffizient sind.
  
  MFG
  
  PS: Wenns unbedingt eine Perldatei für die Konfig sein soll, definiere da keine zusätzlichen Variablen sondern binde die mit $cfg = do 'config.pm'; ein, also nutze den Returnvalue. Das heißt, daß Deine letzte Zeile entweder eine [] Arrayref oder {} Hashref ist.
  Last edited: 2019-06-07 17:04:57 +0200 (CEST)
- haj
  
  2019-06-07 17:25
  User since
  2015-01-07
  555 Artikel
  BenutzerIn
  Hallo YAPD,
  
  ...weil ich an der Wahl von Moose nicht ganz unschuldig bin, versuche ich mal auf die Fragen einzugehen.
  
  Es ist schon so wie rosti schreibt, dass Perl-Code als Konfigurations-Format unüblich (oder mit meinen Worten: "rustikal") ist. Es gibt auf CPAN (zu) viele Module, die Config-Dateien in allen möglichen und einigen unmöglichen Formaten bearbeiten, aber das verschiebe ich mal.
  
  Eine Empfehlung vorneweg: Moose kann ... zu viel. Setze die Besonderheiten nur ein, wenn Du den Mehrwert jemand anderem erklären kannst. Der Kürze wegen lasse ich hier auch einige Sachen weg, die ich sonst grundsätzlich verwende.
  
  Gleich ein Hinweis zu einem Unterschied zwischen Objekt und Hash, den Du auch schon festgestellt hast: Hash-Zugriffe werden in Strings interpoliert, Methodenaufrufe nicht. Dagegen ist leider nichts zu machen.
  
  Code (perl): (dl )
  
  1 2 3
  
  -e "$Self->{Home}/Kernel/Config/Files/" # wird wie erwartet interpoliert -e "$Self->Home()/Kernel/Config/Files/" # Hier wird nur $Self interpoliert. -e ($Self->Home . "/Kernel/Config/Files/") # So geht's dann wieder.
  
  Beim weiteren bin ich nicht ganz sicher, ob ich Deinen Anwendungsfall richtig verstanden habe, daher schreibe ich mal meine Annahmen auf:
  
  Ich gehe mal davon aus, dass Du Deine gesamte Konfiguration als ein Objekt der Klasse Kernel::Config haben willst.
  Du hast viele Einzeldateien mit Konfigurationsvariablen im Format $Self->{ WasAuchImmer } = 'Es muss sein';
  Welche Konfigurationsvariablen es überhaupt geben soll, entscheiden die Defaults-Konfigurationsdateien und nicht die Config-Module.
  Du willst also nicht für jede einzelne Variable ein has schreiben.
  Alle Konfigurationsvariablen taugen syntaktisch als Moose-Attribute (Beispiel: $Self->{'Database User'} taugt nicht)
  
  Dann kann man Kernel::Config::Defaults wie folgt schreiben:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
  
  package Kernel::Config::Defaults; use strict; # ---------------------------------------------------------------------- sub Load_Defaults { my ($Config_Dir) = @_; our $Self = { DB_Handle => 'Microsoft SQL Server'}; if ( -e "$Config_Dir" ) { print "Positive Erkennung des Config - Files Ordners $Config_Dir\n"; # Ich nehme an, hier wird noch mehr Zeug aus den Dateien # in den Hash eingetragen, hier einfach hart codiert: $Self -> { Database } = 'Bezeichnung der DB'; $Self -> { DatabaseUser } = 'Standard User'; $Self -> { DatabasePw } = 'XXXXXXXX'; } else { die "Keine Defaults, keine Attribute. Versuch's nochmal."; } return %$Self; }; # ---------------------------------------------------------------------- 1;
  
  Ich habe Moose rausgeworfen. Wird ja nix genutzt davon. Und ich habe den Directory-Namen als Parameter übergehen und nicht fest einprogrammiert. Die Routine gibt gibt meinem Verständnis nach einen Hash mit 200 oder mehr Konfigurationsvariablen mit Default-Werten zurück, und die Aufgabe besteht nun darin, aus den Schlüsseln des Hash Attribute der Klasse Kernel::Config zu machen.
  
  Das wird nun wie folgt in Kernel::Config eingebaut:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
  
  package Kernel::Config; use Moose; use Kernel::Config::Defaults; # ------------------------------------------------------------------------ my $Home = $ENV{CONFIG_HOME} // 'C:\Scripts\Aktuell'; # ------------------------------------------------------------------------ has Home => ( is => 'rw', default => $Home, ); my %Config = Kernel::Config::Defaults::Load_Defaults($Home); while (my ($attribute,$default) = each %Config) { has $attribute => ( is => 'rw', default => $default, ); } # -------------------------------------------------------------------------------- no Moose; # --------------------------------------------------------------------------------- __PACKAGE__ -> meta -> make_immutable;
  
  Nebenbei: Man kann an has auch gleich eine Liste von Attributen übergeben:
  
  Code (perl): (dl )
  
  has => ([ keys %Config ], is => 'rw');
  
  ...dann sind allerdings keine Defaults versorgt.
  
  Die Verwendung im Installer sieht dann so aus:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11
  
  use strict; use Kernel::Config; # ---------------------------------------------------------------------- my $Config = Kernel::Config -> new(DatabasePw => 'Geheim!!11!'); # ------------------------------------------------------------------- printf ("Value des Config - Werts Home: %s\n", $Config->Home); printf ("Value des Config - Werts Database: %s\n", $Config->Database); printf ("Value des Config - Werts DatabasePw: %s\n", $Config->DatabasePw); printf ("Value des Config - Werts DB_Handle: %s\n", $Config->DB_Handle);
  
  ...und die Ausgabe nach dem Aufruf mit CONFIG_HOME=/tmp:
  
  Code: (dl )
  
  1 2 3 4 5
  
  Positive Erkennung des Config - Files Ordners /tmp Value des Config - Werts Home: /tmp Value des Config - Werts Database: Bezeichnung der DB Value des Config - Werts DatabasePw: Geheim!!11! Value des Config - Werts DB_Handle: Microsoft SQL Server
  
  Hier siehst Du, welche Quellen für die Konfiguration herangezogen wurden: Home kommt aus der Umgebungsvariablen (ich will kein C:/Scripts bei mir einrichten), Database aus einer Defaults-Datei und DatabasePw aus dem Aufruf im Installer, hier wurde der Default also überschrieben. Auch wenn das nicht genau Deinen Einsatzfall trifft, sollte es Dir einen Überblick über die Möglichkeiten geben.

View all threads created 2019-06-06 19:59.