Hier eine vorab Doku

(alle Angaben gelten als Ergänzung/Änderung zur Admin-Doku, wenn nicht anders beschrieben)

Module sind und bleiben das Herzstück von D*DI, dahingehend wurden Module um einiges an Funktionalität erweitert und die Einbindung in D*DI verbessert.

Vorweg 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.

SQL-installation/-deinstallation und Update.

Ein Modul kann SQL-Statements mitbringen die von D*DI 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önne 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.

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 D*DI-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 Standart 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
- kappseln von Funktionen/Klassen
- Aufräumen der verwendeten Variablen
- Eindeutige Namensgebung
- einhalten von Konventionen
... dazu möchte ich in einem anderen Tread gerne mit euch diskutieren und das ganze abstimmen (kann auch jemand anderes starten!)

Pre-Konfiguration eines Moduls

Ein Modul kann vorkonfiguriert werden und so gewisse Einstelllungen des Moduls schon bei der installation übernommen werden.
In der Modulkonfiguration, zu erreichen unter Design->Module->Modul konfigurieren, kann das Modul einmal voreingestellt werden und die Einstellungen können 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 sammt allen Einstellungen mittels der modulname.dedimod Datei gespeichert und weitergegeben werden!
....................
Änderungen/Erweiterungen sind vorbehalten. Das ist nur eine vorläufige Dokumentation!
Die gesammte 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).

Gruss, STam