Modulentwicklung
Aus DeDi-Help
| Version vom 09:09, 27. Jan. 2006 (bearbeiten) TXz (Diskussion | Beiträge) (→SQL-Installation/-Deinstallation und Update) ← Zum vorherigen Versionsunterschied |
Aktuelle Version (11:59, 6. Okt. 2009) (bearbeiten) (Entfernen) Eppi (Diskussion | Beiträge) |
||
| Zeile 1: | Zeile 1: | ||
| - | Module sind und bleiben das Herzstck von DeDi, dahingehend wurden Module um Einiges an Funktionalitt erweitert und die Einbindung in DeDi verbessert. | + | Module sind und bleiben das Herzstück von DeDi, dahingehend wurden Module um Einiges an Funktionalität erweitert und die Einbindung in DeDi verbessert. |
| Zeile 8: | Zeile 8: | ||
| - | Grundstzlich haben wir zwei Zustnde von Modulen: gespeichert und installiert, wobei ein installiertes Modul immer auch ein gespeichertes Modul ist. | + | Grundsätzlich haben wir zwei Zustände von Modulen: gespeichert und installiert, wobei ein installiertes Modul immer auch ein gespeichertes Modul ist. |
| - | Installierte Module knnen natrlich auch deinstalliert werden, was abhngig vom Speicherort einer Lschung gleichkommt! | + | 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). | 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 im Store sind nicht installiert sondern nur gespeichert. Module in einem Client sind immer installiert! | ||
| - | Module knnen vererben. Das bedeutet das ein Modul ein Parent ist sobald von ihm ein Modul abgeleitet (instanziert) wird (Child). | + | Module können vererben. Das bedeutet das ein Modul ein Parent ist sobald von ihm ein Modul abgeleitet (instanziert) wird (Child). |
| - | Module im Store knnen Parents und Child sein aber nicht Child einen Moduls aus einem Client, Module in einem Client knnen Parent sowie auch Child sein aber nicht Parent eines Moduls aus dem Store. | + | 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 Verhltnis um und das Modul im Store ist der Parent. | + | 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 Verhltnisses knnen Module geupdatet werden. Das heisst eine hhere Version eines Moduls bietet innerhalb dieser Beziehung ein Update an welches auf Knopfdruck durchgefhrt wird. | + | 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 knnen vom Child gelscht werden, so das ein Child Modul wieder eigenstndig wird. | + | Beziehungen der Module können vom Child gelöscht werden, so das ein Child Modul wieder eigenständig wird. |
| Zeile 31: | Zeile 31: | ||
| - | Module im Store knnen nur gelscht werden wenn es keine Verknpfungen zu Childs in Clients gibt. | + | 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 gelschtes Parent bergibt sein Verhltnis (wenn es mehrere Childs gibt) einfach an das nchste Child. | + | 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 Abhngigkeit nur einmal existieren! Eine jede Modulinstanz ist ein eigenstndiges Modul, welches auch so behandelt werden kann, nur im Rahmen der Abhngigkeiten werden Einschrnkungen getroffen die fr ein Modul als solches einmalig sein sollen und so nur fr ein Parent zugelassen sind! | + | 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 knnen. | + | Das hat den Vorteil das ein Modul auch innerhalb eines Clients vererben kann und so mehrere Versionen/Konfigurationen eines Moduls existieren können. |
| - | Diese Abhngigkeiten sind auch notwendig um das nchste Feature zu ermglichen. | + | Diese Abhängigkeiten sind auch notwendig um das nächste Feature zu ermöglichen. |
| Zeile 43: | Zeile 43: | ||
| == SQL-Installation/-Deinstallation und Update == | == SQL-Installation/-Deinstallation und Update == | ||
| - | Ein Modul kann SQL-Statements mitbringen die von DeDi zu bestimmten Aktionen ausgefhrt werden. | + | 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' ausgefhrt. | + | Beim Installieren eines Moduls oder Importieren in einen Client wird 'Install' ausgeführt. |
| - | Beim Lschen eines Moduls aus einem Client wird 'Uninstall' ausgefhrt. | + | 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 gendert) wird ein Update bei allen von diesem Modul direkt abhngigen Modulen angeboten indem eine 'gelbe Lampe' zu sehen ist! | + | 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 knnen in Design->Module->'Modul bearbeiten'->'Sql bearbeiten' gepflegt werden. | + | Diese SQL-Statements können in Design->Module->'Modul bearbeiten'->'Sql bearbeiten' gepflegt werden. |
| Ein Statement kann auch als Block mehrere Statements enthalten. | Ein Statement kann auch als Block mehrere Statements enthalten. | ||
| - | Eine Syntaxprfung ist angedacht aber nicht implementiert. | + | Eine Syntaxprüfung ist angedacht aber nicht implementiert. |
| Eine Erweiterung auf Scripting mit Php ist ebenfalls angedacht. | Eine Erweiterung auf Scripting mit Php ist ebenfalls angedacht. | ||
| - | Dieses Feature ist auf ein installiertes Parent Modul begrenzt, also nicht fr jedes Child erweiterbar! | + | 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 verfgung: | + | Einige Variablen stehen bei der Entwicklung der Statements zur Verfügung: |
| - | *{mod_client_prefix} <-> 'dedi_mod_x_' wird in beide Richtungen bersetzt | + | *{mod_client_prefix} <-> 'dedi_mod_x_' wird in beide Richtungen übersetzt |
| - | *{mod_prefix} <-> 'dedi_mod_' wird in beide Richtungen bersetzt | + | *{mod_prefix} <-> 'dedi_mod_' wird in beide Richtungen übersetzt |
| - | *{client_prefix} <-> 'client_x_' wird in beide Richtungen bersetzt | + | *{client_prefix} <-> 'client_x_' wird in beide Richtungen übersetzt |
| - | *{table_prefix} <-> 'dedi_' wird in beide Richtungen bersetzt | + | *{table_prefix} <-> 'dedi_' wird in beide Richtungen übersetzt |
| - | *{client_id} -> x wird nur in eine Richtung bersetzt | + | *{client_id} -> x wird nur in eine Richtung übersetzt |
| - | *{now} -> 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. | Sinn macht das ganze deshalb, weil es mit Sicherheit Module geben wird die eigene Tabellen/Langstrings oder Values mitbringen. | ||
| - | Um diese Funktionalitt aus dem eigentlichen Modulcode rauszuhalten ist dieses Feature gedacht. | + | Um diese Funktionalität aus dem eigentlichen Modulcode rauszuhalten ist dieses Feature gedacht. |
| - | == Syntaxprfung Modulcode == | + | == Syntaxprüfung Modulcode == |
| - | Beim abspeichern und whrend anderer Aktionen im Client wird ein Modul auf Funktion geprft. | + | 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 gefttert ($db, $perm, $catside usw.) bergabeparameter aus den GET/POST oder aus der Modulkonfiguration werden nicht weitergegeben. | + | 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. | 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!). | Vorhandene Syntaxfehler oder Fehlfunktionen werden erkannt und angezeigt (mit einer orangenen Hervorhebung!). | ||
| - | Wir wollen die User nicht gngeln, diese Feature dient einzig und allein dazu entsprechende Hilfestellung zu geben (dazu wird es noch weiter ausgebaut). | + | 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. | 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 Neuanfngern wollen wir das Ganze ja nicht zu sehr verbauen und auch nicht das Entwickeln neuer Module verhindern. | + | 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 wren: | + | Zu nennen wären: |
| *Eingangsverarbeitung/Aufbereitung | *Eingangsverarbeitung/Aufbereitung | ||
| *Kapseln von Funktionen/Klassen | *Kapseln von Funktionen/Klassen | ||
| - | *Aufrumen der verwendeten Variablen | + | *Aufräumen der verwendeten Variablen |
| *Eindeutige Namensgebung | *Eindeutige Namensgebung | ||
| *Einhalten von Konventionen | *Einhalten von Konventionen | ||
| Zeile 91: | Zeile 91: | ||
| *Funktionen und Klassen | *Funktionen und Klassen | ||
| Funktionen/Klassen sollte man Kapseln,<br> das heisst die jeweilige Funktion oder Klasse wird innerhalb von<br> if ( ! function_exists('FUNKTIONSNAME') ) { function FUNKTIONSNAME ...<br> eingeschlossen (Klassen mit class_exists()) | Funktionen/Klassen sollte man Kapseln,<br> das heisst die jeweilige Funktion oder Klasse wird innerhalb von<br> if ( ! function_exists('FUNKTIONSNAME') ) { function FUNKTIONSNAME ...<br> eingeschlossen (Klassen mit class_exists()) | ||
| - | *Variablen und Arrays | + | *Variablen und Arrays |
| - | Variablen/Array sind nicht immer vorhanden und schnell kommt es zu Fehlermeldungen<br> oder Fehlverhalten des Moduls.<br> Deswegen sollte das vorhandensein geprft werden bzw. immer davon ausgegangen werden<br> das diese nicht vorhanden sind.<br> '''Beispiel''':<br> if (is_array($array)) foreach ($array as $key => &val)... | + | Variablen/Array sind nicht immer vorhanden und schnell kommt es zu Fehlermeldungen<br> oder Fehlverhalten des Moduls.<br> Deswegen sollte das vorhandensein geprüft werden bzw. immer davon ausgegangen werden<br> das diese nicht vorhanden sind.<br> '''Beispiel''':<br> if (is_array($array)) foreach ($array as $key => &val)... |
| *Datenbankabfragen | *Datenbankabfragen | ||
| - | Datenbankabfragen sollten nur laufen wenn auch die dazugehrigen<br> Argumente (Variablen) vorhanden sind.<br> '''Beispiel''':<br> if (isset($eingang)) $sql = "SELECT * FROM tabelle WHERE beispiel = '" . $eingang . '""; | + | Datenbankabfragen sollten nur laufen wenn auch die dazugehörigen<br> Argumente (Variablen) vorhanden sind.<br> '''Beispiel''':<br> if (isset($eingang)) $sql = "SELECT * FROM tabelle WHERE beispiel = '" . $eingang . '""; |
| *Umgehung | *Umgehung | ||
| - | ab DeDi Version 1.01 ist eine Umgehung der Prfung einzelner Codeteile mglich.<br> Da einzelne Code-Implementationen in einem Modul nur Fehlerhaft getestet werden knnen kann ein Codeteil mit<br> if (!defined('__DEDIMODTEST')) {... ausgeklammert werden.<br> '''Achtung''':<br> Mit dieser Funktionalitt Bitte sorgsam umgehen, da das die ganze Modulberprfung sonst absurdum fhrt! | + | ab DeDi Version 1.01 ist eine Umgehung der Prüfung einzelner Codeteile möglich.<br> Da einzelne Code-Implementationen in einem Modul nur Fehlerhaft getestet werden können kann ein Codeteil mit<br> if (!defined('__DEDIMODTEST')) {... ausgeklammert werden.<br> '''Achtung''':<br> Mit dieser Funktionalität Bitte sorgsam umgehen, da das die ganze Modulüberprüfung sonst absurdum führt! |
| == Pre-Konfiguration eines Moduls == | == Pre-Konfiguration eines Moduls == | ||
| - | Ein Modul kann vorkonfiguriert werden und so gewisse Einstellungen des Moduls schon bei der Installation bernommen werden. | + | 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 knnen dann in jedem Container 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 Schraubenschlssels als Menpunkt wechselt die Farbe von schwarz auf Rot wenn ein Modul vorkonfiguriert ist. | + | Die Darstellung des Schraubenschlüssels als Menüpunkt wechselt die Farbe von schwarz auf Rot wenn ein Modul vorkonfiguriert ist. |
| Zeile 111: | Zeile 111: | ||
| - | nderungen/Erweiterungen sind vorbehalten. Das ist nur eine vorlufige Dokumentation! | + | Ä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! | 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 zugnglich (Stichwort: Online-Repository). | + | Einige Teilbereiche werden aber erst zur folgenden Beta/Final freigeschaltet und sind somit noch nicht zugänglich (Stichwort: Online-Repository). |
| [[Category:Entwicklung]] | [[Category:Entwicklung]] | ||
Aktuelle Version
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).
