Modul erstellen

Module sind der primäre Weg, um die Funktionalität von NexoPOS zu erweitern. Sie ermöglichen Entwicklern, neue Funktionen einzuführen, vorhandenes Verhalten anzupassen oder externe Dienste zu integrieren, ohne die Kernanwendung zu ändern.

Jedes Modul arbeitet als eigenständige Einheit mit eigener Logik, eigenen Ressourcen und eigener Konfiguration. Diese modulare Architektur stellt sicher, dass individuelle Entwicklungen isoliert bleiben und mit zukünftigen Updates von NexoPOS kompatibel sind.

Per Design behandelt NexoPOS Module als erstklassige Komponenten des Systems und ermöglicht so ein flexibles und skalierbares Ökosystem.

Architektur

Ein Modul ist als eigenständige Komponente innerhalb der Anwendung strukturiert. Es umfasst typischerweise:

• Controllers: Handle application logic and user interactions
• Views: Define the user interface rendered within the dashboard
• Routes: Register accessible endpoints and navigation paths
• Assets: Provide JavaScript, CSS, or other frontend resources
• Configuration: Store module-specific settings and metadata

Alle Module werden im Verzeichnis „modules“ gespeichert und folgen einer standardisierten Struktur, um die Konsistenz im gesamten System sicherzustellen.

Modulgenerierung

NexoPOS enthält einen integrierten Artisan-Befehl, der dabei hilft, ein neues Modul mit der erwarteten Struktur zu erstellen. Dies ist der empfohlene Weg, um ein Modul zu starten, da er die Basisdateien und Verzeichnisse vorbereitet, die vom System benötigt werden.

Um ein Modul zu erstellen, öffnen Sie ein Terminal vom Stammverzeichnis Ihrer NexoPOS-Installation aus und führen Sie den folgenden Befehl aus:

php artisan make:module

Sobald der Befehl ausgeführt wurde, startet NexoPOS einen interaktiven Prozess und fordert eine Reihe von Details an.

Der erste Wert, der angegeben werden muss, ist der Modulnamespace. Dies ist der interne Bezeichner des Moduls und wird normalerweise in einem kompakten Format wie „FooBar“ geschrieben. Dieser Namespace wird verwendet, um das Modulverzeichnis zu erstellen und das Modul intern zu identifizieren.

.

Danach fragt NexoPOS nach dem Modulnamen. Im Gegensatz zum Namespace handelt es sich hierbei um den für Menschen lesbaren Namen, der Benutzern angezeigt werden kann. Beispielsweise kann ein Namespace wie „FooBar“ einen Namen wie „The FooBar Module“ verwenden.

Der nächste Prompt fordert den Namen des Autors an. Dieser wird verwendet, um zu identifizieren, wer das Modul erstellt hat, und wird in den Modulmetadaten gespeichert.

NexoPOS fordert anschließend eine kurze Beschreibung an. Diese Beschreibung erläutert kurz den Zweck des Moduls und hilft dabei, seine Rolle zu identifizieren.

Bevor die Dateien generiert werden, zeigt der Befehl eine Zusammenfassungstabelle mit den bereitgestellten Informationen an, einschließlich des Namespaces, des Namens, des Autors, der Beschreibung und der Version. In diesem Stadium ist eine Bestätigung erforderlich. Durch das Bestätigen der Informationen kann NexoPOS mit der Generierung fortfahren.

Sobald dies bestätigt ist, erstellt das System einen neuen Ordner im Verzeichnis „modules“ mithilfe des bereitgestellten Namespace. Wenn der Namespace beispielsweise „FooBar“ lautet, wird das generierte Modul unter „modules/FooBar“ erstellt.

Die generierte Struktur umfasst mehrere Verzeichnisse und Dateien, die das Modul für die weitere Entwicklung vorbereiten. Dazu gehören Ordner für Konfiguration, CRUD-Logik, Events, Facades, Felder, HTTP-Klassen, Mails, Migrations, Modelle, Provider, öffentliche Assets, Ressourcen, Routen und Services. Das Modul enthält außerdem zentrale Dateien wie config.xml und die Hauptmoduldatei.

Diese generierte Struktur bildet die Grundlage, um mit dem Aufbau von Funktionen zu beginnen und das Modul gleichzeitig gemäß den NexoPOS-Standards organisiert zu halten.

Empfehlung

Um die Kompatibilität und Wartbarkeit sicherzustellen, sollten Module stets mit dem integrierten Generator von NexoPOS erstellt werden.

Dies gewährleistet die Übereinstimmung mit den Systemstandards und verringert das Risiko von strukturellen oder Integrationsproblemen.