Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:start [09.06.2021 07:22] – [Modellierung - fällt aus] sbel
+++ faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:start [21.06.2021 15:34] (aktuell) – [Datenbank-Klasse] sbel
@@ Zeile 37: / Zeile 37: @@
      * @return object       DB-Handle
      */
-    function mysqldb($dbusername, $dbpassword, $dbname, $host="localhost" ) {
+    function __construct($dbusername, $dbpassword, $dbname, $host="localhost" ) {
     try {
@@ Zeile 48: / Zeile 48: @@
     }
-    return $pdo;
+    $this->connection=$pdo;
     }
@@ Zeile 84: / Zeile 84: @@
 </code>
-  * Ergänze innerhalb der ''render''-Methode Code, der eine Datenbanlk Verbindung erzeugt.
+  * Ergänze innerhalb der ''render''-Methode Code, der eine Datenbank Verbindung erzeugt.
   * Mache dir klar, welche Funktion das dabei erzeugte Objekt ''$dbhandle'' im weiteren Verlauf des Programms hat.
-  * Teste, was passiert, wenn du eine falsches Benutzer/Passwort-Kombination, eine nicht existente Datenbank oder einen anderen Host als localhost angibst.
+  * Teste, was passiert, wenn du eine falsches Benutzer/Passwort-Kombination, eine nicht existente Datenbank oder einen anderen Host als ''localhost'' angibst.
 <code>
-$dbhandle = new mysqldb("DBUSER", "dbuserPASS", "DBNAME");
+$mydb = new mysqldb("DBUSER", "dbuserPASS", "DBNAME");
 </code>
+==== Plugin-Konfiguration ====
+Sehr unschön ist jetzt natürlich, dass die datenbank Credentials im Quelltext des Plugins stehen - auf diese Weise kann man ein solches Plugin schlecht veröffentlichen oder weitergeben. Wesentlich sind hier 2 Implikationen:
+  - Das kollidiert massiv mit der Versionsverwaltung: Man sollte unbedingt vermeiden, Benutzernamen und Passwörter in öffentlich einsehbare Git-Repos einzuchecken.
+  - Wenn ein anderer Benutzer in ferner Zukunft das Plugin in seinem eigenen Wiki verwenden möchte, muss dieser, um das Plugin für sich nutzbar zu machen den Quelltext editieren um dort seine eigenen Datenbank Zugangsdaten einzutragen - das ist aus vielen Gründen Mist, einer ist z.B.: wie das Plugin jetzt auf neue Versionen aktualisiert werden soll, denn  dabei würden diese Änderungen ja jedes mal wieder rückgängig gemacht.
+DokuWiki bietet für dieses Problemfeld die Möglichkeit, Plugin-Einstellungen über das DokuWiki Webinterface festlegen zu können - das wollen wir im Folgenden für unser Plugin umsetzen.
+=== Konfigurations-Konventionen ===
+Im Plugin-Ordner gibt es ein Unterverzeichnis ''conf'' in diesem befinden sich zwei Dateien: ''default.php'' und ''metadata.php'', die Funktionsweise zeigt das folgende Schaubild:
+{{ :faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:conf.png |}}
+Wenn wir jetzt also unser Plugin durch DokuWiki "konfigurierbar machen wollen, müssen wir drei Fragen beantworten:
+  - Welche Optionen brauchen wir und was müssen wir diesbezüglich in die Datei ''metadata.php'' schreiben?
+  - Was sollen die Vorgabewerte für diese Optionen sein und was muss in ''default.php'' stehen?
+  - Wie können wir im Quelltext des Plugins auf die Werte unserer Konfigurationsoptionen zugreifen?
+Die **Optionen** liegen auf der Hand: DB-Username, DB-Passwort, DB-Name und DB-Host. Sinnvolle **Vorgabewerte** sind "leer", außer beim DB-Host, da dürfte ''localhost'' Sinn machen. Alle Optionen sind als Zeichenketten einzugeben.
+In den Dateien ''default.php'' und ''metadata.php'' stellt sich das dann wie folgt dar (zunächst nur für den DB-Usernamen):
+<code php metadata.php>
+$meta['dbusername'] = array('string');
+</code>
+<code php default.php>
+$conf['dbusername'] = ''; // leerer String
+</code>
+Die vollständige Entwicklerdokumentation findet sich [[https://www.dokuwiki.org/devel:configuration|hier]], dort kann man auch die unterschiedlichen Konfigurationstypen für die ''metadata.php'' nachschlagen.
+Zugriff auf die Werte der Plugin-Optionen erfolgt mit
+<code php>
+$dbuser = $this->getConf('dbusername');
+</code>
+----
+{{:aufgabe.png?nolink  |}}
+=== (A3) ===
+Füge die Informationen aus dem vorigen Abschnitt deinem Plugin hinzu und mache auf diese Weise den Datenbankbenutzer konfigurierbar.
+Teste die Änderungen, indem du den Konfigurationsmanager öffnest:
+{{ :faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:auswahl_388.png?500 |}}
+Dort sollte es jetzt einen Abschnitt für das Plugin ''projekt'' geben, in dem die Plugin-Optionen angezeigt werden.
+{{ :faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:auswahl_389.png?500 |}}
+{{ :faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:auswahl_390.png?500 |}}
+Trage deinen DB-Benutzernamen dort ein und speichere die Einstellungen.
+Modifiziere dann deine ''syntax.php'' so, dass der Datenbankbenutzer, der dem Konstruktor der DB-Klasse übergeben wird, aus den Einstellungen ausgelesen wird.
+Teste, ob die Datenbankverbindung immer noch ordnungsgemäß zustande kommt.
+Ergänze die weiteren Optionen für Passwort, Datenbankname und Datenbankhost, konfiguriere das Plugin mit den Werten, die für deinen Benutzer passen und teste die Verbindung erneut.
+++++ Hilfestellung |
+In der ''syntax.php'' kann das in etwa so aussehen - die Optionsnamen können natürlich abweichen, je nachdem wie du diese benannt hast.
+<code php>
+ // get settings
+ $dbuser = $this->getConf('dbusername');
+ $dbpasswd = $this->getConf('dbpasswd');
+ $dbname = $this->getConf('dbname');
+ $dbhost = $this->getConf('dbhost');
+ //make db connection
+ $dbhandle = new mysqldb($dbuser, $dbpasswd, $dbname, $dbhost);
+</code>
+++++
 ==== Modellierung - fällt aus ====
@@ Zeile 96: / Zeile 175: @@
 Eigentlich sollte man sich an dieser Stelle überlegen, wie man seine Problemstellung (objektorientiert) modellieren möchte, das fällt uns etwas schwer, weil wir noch keine Problemstellung haben. Ein paar Überlegungen kann man an dieser Stelle dennoch anstellen.
-Eine grundlegende Frage könnte z.B. sein, wie man die ''mysqldb''-Klasse weiter entwickelt: Man kann weitere Methoden implementieren, die Abfragen oder Manipulationen an der Datenbank ermöglichen. Man könnte solche Programmfunktionen jedoch auch (wie im Schema oben angedeutet) nach Objektkategorien zusammengefasst auf weitere Klassen verteilen. Das Schema demonstriert ein solches Vorgehen für ein Micro-Blog mit Benutzern, die Posts verfassen können.
+Eine grundlegende Frage könnte z.B. sein, wie man die ''mysqldb''-Klasse weiter entwickelt: Man kann weitere Methoden in der mysqldb-Klasse implementieren, die Abfragen oder Manipulationen an der Datenbank ermöglichen. Man könnte solche Programmfunktionen jedoch auch (wie im {{ :faecher:informatik:oberstufe:datenbanken:projekt:dokuwiki_plugin:dbklasse:render_as_control_class.png?linkonly|Schema}} oben angedeutet) nach Objektkategorien zusammengefasst auf weitere Klassen verteilen. Das Schema demonstriert ein solches Vorgehen für ein Micro-Blog mit Benutzern, die Posts verfassen können. In diesem Setting liefert die mysqldb-Klasse lediglich das DB-Handle, das seinerseits dann an die Methoden in den user- und posts-Klassen weitergegeben wird, so dass diese die entsprechenden Funktionen - auch auf der Datenbank - erfüllen können.
+Wir entwickeln zunächst weitere Methoden innerhalb unserer mysqldb-Klasse - wenn sich unsere Problemstellung konkretisisert können wir im Zuge eines Code-Refactoring weitere Aufteilungen und Modellierungsschritte vornehmen.