pm-Modul als Konfigurationsdatei

[opi]

Hallo und guten Abend!

Vor einiger Zeit hatte ich mal einen Thread aufgemacht bezüglich "Konfigurationsdateien auslesen". Der Eine oder Andere mag sich noch daran erinnern, wenn nicht... dann ist es nicht so wichtig.

Bisher schauen meine Konfigurationsdateien folgendermaßen aus:

[Sektionsname]
parm1=value1
parm2=value2
parm3=value3

In all meinen Perlproggis habe ich dann natürlich ein Stück Code, um die Datei auszulesen und lade alles in einen Hash. Nun hatte ich mir gedacht, eine kleine Subfunktion für das "Stück Code" zu schreiben und diese in ein Modul auszulagern. Mit diesem Gedanken kam aber auch sofort die Idee, wie es wohl wäre, ein Modul selber als Konfigurationsdatei zu "mißbrauchen".

package conf;
...
our @EXPORT = qw(%conf);
...
my %conf;
$conf{parm1}="value1";
$conf{parm2}="value2";
$conf{parm3}="value3";

Dieses Schema schaut mir so einfach aus, dass es aber doch bestimmt irgendwelche Haken hierbei gibt?! Gibt es zum Beispiel ein CPAN-Modul, mit dem ich Werte aus einem "Konfigurations-Modul" ändern kann? Zum Beispiel den Wert von $conf{parm1} auf value43 fixen. Das stelle ich mir nämlich nicht so einfach vor.

Greez,
opi

[Struppi]

Bisher schauen meine Konfigurationsdateien folgendermaßen aus:

[Sektionsname]
parm1=value1
parm2=value2
parm3=value3

Das ist Config::IniFiles;

package conf;
...
our @EXPORT = qw(%conf);
...
my %conf;
$conf{parm1}="value1";
$conf{parm2}="value2";
$conf{parm3}="value3";

Vielleicht besser our %conf;

Aber ansonsten würd ich sagen das ist Geschmackssache, das Modul macht eigentlich alles was man braucht. Eine Datei im ersten Format läßt sich ein bisschen leichter ändern.

Struppi.

[opi]

Hallo,

Das ist Config::IniFiles;

Dieses Modul gilt für beide Conf-Arten oder nur für die erste?

Vielleicht besser our %conf;

ja, sorry.

Greez,
opi

[Struppi]

Das ist Config::IniFiles;

Dieses Modul gilt für beide Conf-Arten oder nur für die erste?

nur für das erste Beispiel.

Struppi.

[opi]

Hallo Struppi,

Das ist Config::IniFiles;

Dieses Modul gilt für beide Conf-Arten oder nur für die erste?

nur für das erste Beispiel.

der Gedanke, ein Modul als Konfigurationsdatei zu nutzen scheinte mir im ersten Augenblick recht ellegant, aber da ich Benutzern und Admins die Möglichkeit bieten möchte, die bestimmte Daten über den Browser zu ändern, wäre das erste Beispiel viel angenehmer!

Ich habe mir das Modul runtergeladen und mal in IniFile.pm reingeschaut! Recht nett :-)

Dankeschön.

Greez,
opi

[Siechfred]

Tag opi.

In all meinen Perlproggis habe ich dann natürlich ein Stück Code, um die Datei auszulesen und lade alles in einen Hash. Nun hatte ich mir gedacht, eine kleine Subfunktion für das "Stück Code" zu schreiben und diese in ein Modul auszulagern.

Meiner Meinung nach ist das eine schöne kleine Aufgabe, um mit OOP in Perl zu beginnen. Ich habe dir mal ein eigenes Beispiel hochgeladen: DB_Session.pm, das sicher nicht perfekt ist, aber als Anregung für dein Vorhaben durchaus taugen sollte.

Siechfred

[opi]

Hallo Siechfred,

Meiner Meinung nach ist das eine schöne kleine Aufgabe, um mit OOP in Perl zu beginnen. Ich habe dir mal ein eigenes Beispiel hochgeladen: DB_Session.pm, das sicher nicht perfekt ist, aber als Anregung für dein Vorhaben durchaus taugen sollte.

ja es ist erstaunlich, was man damit alles machen kann. Ich programmiere noch nicht lange mit Perl, aber seit geraumer Zeit fange ich an, größere Schritte zu machen.

Mittlerweile sind die meisten meiner Perl-CGI Skripte so aufgebaut, dass ich mir nur noch Gedanken um den Body machen muss, alles andere wird mit Funktionen erledigt, Beispiel:

use Irgend_ein_Modul;
unless($username=check_cookie()) { login(1); }
%arg=argv();
unless(%profile=prof($username)) { login(2); }

start

header($title);
navigation($username);
...
... # body
...
baseboard();

ende

In meinem Projekt hatte ich zuvor vorwiegend mit Tabellen und Frames gearbeitet, aber das ist nirgends gut angekommen. Jetzt gibt es bei mir nur noch DIVs und CSS... Tabellen nur noch für echte Tabellen und Frames für generierte Grafiken, obwohl ich hierfür auch noch eine Lösung suche.

Eine Frage habe ich noch. Bei der Auswahl des Modulpfades und der Deklaration der Subfunktionen ist mir aufgefallen, dass ich ziemlich aufpassen muss, welche Namen ich hier vergebe. Wie kann ich sichergehen, dass nie eine Funktion eines geladenen Perl-Moduls überschrieben wird?

Greez,
opi

[Struppi]

Mittlerweile sind die meisten meiner Perl-CGI Skripte so aufgebaut, dass ich mir nur noch Gedanken um den Body machen muss, alles andere wird mit Funktionen erledigt, Beispiel:

use Irgend_ein_Modul;
unless($username=check_cookie()) { login(1); }

sowas läßt sichm it Perl schöner formulieren:

login(1) unless $username=check_cookie();

Eine Frage habe ich noch. Bei der Auswahl des Modulpfades und der Deklaration der Subfunktionen ist mir aufgefallen, dass ich ziemlich aufpassen muss, welche Namen ich hier vergebe. Wie kann ich sichergehen, dass nie eine Funktion eines geladenen Perl-Moduls überschrieben wird?

Objektorientiert arbeiten und möglichst wenig in deinen Namespace importieren.

Struppi.

[opi]

Hallo,

unless($username=check_cookie()) { login(1); }

sowas läßt sichm it Perl schöner formulieren:

login(1) unless $username=check_cookie();

oh, genau! Das ist der gleiche Aufbau wie zum Beispiel

next if $var == 1;
print "..." if $var == 2;

Daran mangelt es mir noch... kommt aber stetig :)

Wie kann ich sichergehen, dass nie eine Funktion eines geladenen Perl-Moduls überschrieben wird?

Objektorientiert arbeiten und möglichst wenig in deinen Namespace importieren.

Zudem sehe ich ja auch, welche Funktionen ich in meinen Namensraum importiere, denn die Funktionen werden ja namentlich "angesprochen".

Greez,
opi

[Siechfred]

Tag opi.

Eine Frage habe ich noch. Bei der Auswahl des Modulpfades und der Deklaration der Subfunktionen ist mir aufgefallen, dass ich ziemlich aufpassen muss, welche Namen ich hier vergebe.  Wie kann ich sichergehen, dass nie eine Funktion eines geladenen Perl-Moduls überschrieben wird?

Naja, standardmäßig kannst du ein eigenes und auch die meisten CPAN-Module ganz einfach in das gleiche Verzeichnis legen. Bei CPAN-Modulen musst du aber aufpassen, was du bei "use" schreibst. Liegt das Modul im gleichen Verzeichnis wie das Skript, darfst du use nur mit dem Namen des Moduls ohne die Endung pm angeben.

Und dass es Probleme mit gleichnamigen Funktionen gibt, ist bekannt. Dies kannst du umgehen, indem du -- wie Struppi schon schrieb -- strikt objektorientiert arbeitest. Hättest du zwei Module, die beide eine Methode "header" haben, würdest du dann Probleme bekommen, wenn du die Funktionen in den Namespace des aufrufenden Scripts importierst (siehe mein Posting vom 12.01.2005). Würdest du diese Funktionen als Methoden zweier verschiedener Objektinstanzen aufrufen, dürfte es m.E. keine Probleme geben.

Siechfred