Modulentwicklung
Aus DeDi-Help
Module sind und bleiben das Herzstück von DeDi, dahingehend wurden Module um Einiges an Funktionalität erweitert und die Einbindung in DeDi verbessert.
Inhaltsverzeichnis |
[bearbeiten] Vorneweg Einiges an Begrifflichkeit
Der Modulname, kennzeichnet das Modul und ist in jedem Fall eindeutig.
Grundsätzlich haben wir zwei Zustände von Modulen: gespeichert und installiert, wobei ein installiertes Modul immer auch ein gespeichertes Modul ist.
Installierte Module können natürlich auch deinstalliert werden, was abhängig vom Speicherort einer Löschung gleichkommt!
Wir definieren auch zwei Speicherorte: Client (Projekt) und Store (Datenbank).
Module im Store sind nicht installiert sondern nur gespeichert. Module in einem Client sind immer installiert!
Module können vererben. Das bedeutet das ein Modul ein Parent ist sobald von ihm ein Modul abgeleitet (instanziert) wird (Child).
Module im Store können Parents und Child sein aber nicht Child einen Moduls aus einem Client, Module in einem Client können Parent sowie auch Child sein aber nicht Parent eines Moduls aus dem Store.
Ein Modul das nur in einem Client geuploadet wurde und auch nur da vorhanden ist kann in den Store exportiert (kopiert) werden, dabei dreht sich allerdings das Parent-Child Verhältnis um und das Modul im Store ist der Parent.
Innerhalb des Parent-Client Verhültnisses können Module geupdatet werden. Das heisst eine höhere Version eines Moduls bietet innerhalb dieser Beziehung ein Update an welches auf Knopfdruck durchgeführt wird.
Beziehungen der Module können vom Child gelöscht werden, so das ein Child Modul wieder eigenständig wird.
Ein Modul welches geklont wird ist automatisch ein Child vom Vorbild Modul.
Module die aus dem Store in einen Client installiert (importiert) werden, sind ebenfalls automatisch Childs.
Module im Store können nur gelöscht werden wenn es keine Verknüpfungen zu Childs in Clients gibt.
In einem Client wird das nicht so restriktiv behandelt, ein gelöschtes Parent übergibt sein Verhältnis (wenn es mehrere Childs gibt) einfach an das nächste Child.
Ein Modul kann innerhalb einer Abhängigkeit nur einmal existieren! Eine jede Modulinstanz ist ein eigenständiges Modul, welches auch so behandelt werden kann, nur im Rahmen der Abhängigkeiten werden Einschränkungen getroffen die für ein Modul als solches einmalig sein sollen und so nur für ein Parent zugelassen sind!
Das hat den Vorteil das ein Modul auch innerhalb eines Clients vererben kann und so mehrere Versionen/Konfigurationen eines Moduls existieren können.
Diese Abhängigkeiten sind auch notwendig um das nächste Feature zu ermöglichen.
[bearbeiten] SQL-Installation/-Deinstallation und Update
Ein Modul kann SQL-Statements mitbringen die von DeDi zu bestimmten Aktionen ausgeführt werden. Beim Installieren eines Moduls oder Importieren in einen Client wird 'Install' ausgeführt. Beim Löschen eines Moduls aus einem Client wird 'Uninstall' ausgeführt. Beim Hochladen eines Moduls das neuer ist als ein vorhandenes, beim Online-Update über das Repository oder nach dem direkten ändern eines Parents (Version wird geändert) wird ein Update bei allen von diesem Modul direkt abhängigen Modulen angeboten indem eine 'gelbe Lampe' zu sehen ist!
Diese SQL-Statements können in Design->Module->'Modul bearbeiten'->'Sql bearbeiten' gepflegt werden.
Ein Statement kann auch als Block mehrere Statements enthalten.
Eine Syntaxprüfung ist angedacht aber nicht implementiert.
Eine Erweiterung auf Scripting mit Php ist ebenfalls angedacht.
Dieses Feature ist auf ein installiertes Parent Modul begrenzt, also nicht für jedes Child erweiterbar!
Einige Variablen stehen bei der Entwicklung der Statements zur Verfügung:
- {mod_client_prefix} <-> 'dedi_mod_x_' wird in beide Richtungen übersetzt
- {mod_prefix} <-> 'dedi_mod_' wird in beide Richtungen übersetzt
- {client_prefix} <-> 'client_x_' wird in beide Richtungen übersetzt
- {table_prefix} <-> 'dedi_' wird in beide Richtungen übersetzt
- {client_id} -> x wird nur in eine Richtung übersetzt
- {now} -> x wird nur in eine Richtung übersetzt
Sinn macht das ganze deshalb, weil es mit Sicherheit Module geben wird die eigene Tabellen/Langstrings oder Values mitbringen.
Um diese Funktionalität aus dem eigentlichen Modulcode rauszuhalten ist dieses Feature gedacht.
[bearbeiten] Syntaxprüfung Modulcode
Beim abspeichern und während anderer Aktionen im Client wird ein Modul auf Funktion geprüft. Dazu wird das Modul in eine Sandbox gesteckt und nur mit den wichtigsten DeDi-Variablen gefüttert ($db, $perm, $catside usw.) Übergabeparameter aus den GET/POST oder aus der Modulkonfiguration werden nicht weitergegeben. Der Sinn dahinter ist ganz einfach, je sicherer ein Modul geschrieben ist um so sicherer wird auch der Umgang damit sein. Vorhandene Syntaxfehler oder Fehlfunktionen werden erkannt und angezeigt (mit einer orangenen Hervorhebung!).
Wir wollen die User nicht gängeln, diese Feature dient einzig und allein dazu entsprechende Hilfestellung zu geben (dazu wird es noch weiter ausgebaut).
Im Grundegenommen sollten wir uns an einen gewissen Standard bei der Entwicklung von Modulen halten.
Einige Punkte sind im Forum schon öfters aufgetaucht oder gemeinhin sowieso bekannt. Doch Neuanfängern wollen wir das Ganze ja nicht zu sehr verbauen und auch nicht das Entwickeln neuer Module verhindern.
Zu nennen wären:
- Eingangsverarbeitung/Aufbereitung
- Kapseln von Funktionen/Klassen
- Aufräumen der verwendeten Variablen
- Eindeutige Namensgebung
- Einhalten von Konventionen
Tips:
- Funktionen und Klassen
Funktionen/Klassen sollte man Kapseln,
das heisst die jeweilige Funktion oder Klasse wird innerhalb von
if ( ! function_exists('FUNKTIONSNAME') ) { function FUNKTIONSNAME ...
eingeschlossen (Klassen mit class_exists())
- Variablen und Arrays
Variablen/Array sind nicht immer vorhanden und schnell kommt es zu Fehlermeldungen
oder Fehlverhalten des Moduls.
Deswegen sollte das vorhandensein geprüft werden bzw. immer davon ausgegangen werden
das diese nicht vorhanden sind.
Beispiel:
if (is_array($array)) foreach ($array as $key => &val)...
- Datenbankabfragen
Datenbankabfragen sollten nur laufen wenn auch die dazugehörigen
Argumente (Variablen) vorhanden sind.
Beispiel:
if (isset($eingang)) $sql = "SELECT * FROM tabelle WHERE beispiel = '" . $eingang . '"";
- Umgehung
ab DeDi Version 1.01 ist eine Umgehung der Prüfung einzelner Codeteile möglich.
Da einzelne Code-Implementationen in einem Modul nur Fehlerhaft getestet werden können kann ein Codeteil mit
if (!defined('__DEDIMODTEST')) {... ausgeklammert werden.
Achtung:
Mit dieser Funktionalität Bitte sorgsam umgehen, da das die ganze Modulüberprüfung sonst absurdum führt!
[bearbeiten] Pre-Konfiguration eines Moduls
Ein Modul kann vorkonfiguriert werden und so gewisse Einstellungen des Moduls schon bei der Installation übernommen werden. In der Modulkonfiguration, zu erreichen unter Design->Module->Modul konfigurieren, kann das Modul einmal voreingestellt und die Einstellungen können dann in jedem Container übernommen werden. Die Darstellung des Schraubenschlüssels als Menüpunkt wechselt die Farbe von schwarz auf Rot wenn ein Modul vorkonfiguriert ist.
Das ganze wird dadurch abgerundet das ein Modul diese Features/Einstellungen auch mit sich bringt. Das heisst ein Modul kann mit samt allen Einstellungen mittels der modulname.dedimod Datei gespeichert und weitergegeben werden!
Änderungen/Erweiterungen sind vorbehalten. Das ist nur eine vorläufige Dokumentation!
Die gesamte Entwicklung/Erweiterung ist eigentlich abgeschlossen und befindet sich in der jetzigen Beta im Test, Abweichungen sind BUGS!
Einige Teilbereiche werden aber erst zur folgenden Beta/Final freigeschaltet und sind somit noch nicht zugänglich (Stichwort: Online-Repository).
