OXID – Modulentwicklung – Teil 1

In diesem Teil gehe ich darauf ein, was OXID kann. Welche Vor und Nachteile es hat, und wie die generelle Modulstruktur
aussieht. Ebenfalls gehe ich darauf ein, welche Konflikte zwischen Modulen auftreten können.
Da ich aktuell aufgrund von beruflichen Projekten recht wenig Zeit finde, aber euch auch natürlich keine Informationen vorenthalten
möchte, fällt dieser Artikel relativ gering aus und möglicherweise in einer geringen Qualität.

Allgemein

OXID ist eine E-Commerce Lösung für online Shops, ähnlich wie Magento oder openCart.
Sie findet allerdings mehr Halt im deutsprachigen Bereich, insbesondere dadurch dass sie sehr mächtig ist
und damit einen großen Teil an Funktionen abdeckt, die sich insbesondere größere Unternehmen wünschen, wie z.B.
Deutsche Post AG, Lekkerland, Magura, JUWEL Aquarium GmbH oder BREE Collection GmbH & Co. KG.

OXID gibt es in drei Varianten:

– CE (Community Edition)
– PE (Professional Edition)
– EE (Enterprise Edition)

Für alle drei der Varianten von OXID gibt es die Möglichkeit der modularen Erweiterung, durch eine recht flexible
Lösung die ähnlich wie das Entwurfsmuster HMVC ist.

In erster Linie ist OXID wie bereits erwähnt modular aufgebaut. Es beruht hauptsächlich auf dem Entwurfmuster MVC.
Im Prinzip ist OXID ein Fullstack-Framework, sowie auch in geringfügigen Teilen ein Glue-Framework.

Vorteile und Nachteile

OXID hat seine Vor- und Nachteile. Wie eigentlich jede CMS, Shopsoftware, eigenentwickelte E-Commerce Lösung.
In erster Linie ist OXID eigentlich eher eine closed-Sourcelösung für den E-Commerce Bereich. Unabhängig davon dass
OXID ebenfalls eine Community-Version die Opensource ist pflegt. Dokumentiert ist OXID eigentlich gar nicht.
Die einzige Möglichkeit die es gibt ist, sich in ihrem Forum Informationen einzuholen.

Aber kommen wir einmal tatsächlich zu einer Auflistung der Vor- und Nachteile von OXID:

Vorteile

– Modulare Entwicklung möglich
– Mandantenfähigkeit
– Überladen von Klassen und Methoden möglich
– Kann Produktbilder die via FTP-hochgeladen wurden erkennen und nutzen
– Community-Version (kostenfrei) erhältlich
– ERP-Schnittstelle für OXID verfügbar
– Schulungen zur Entwicklung für OXID verfübar

Nachteile

– Modulare Entwicklung wird bei komplexen Projekten bzgl. der Updatefähigkeit recht problematisch
– ERP-Erweiterung von OXID lässt sich simple mit Plugins oder Modulen aufrüsten/erweitern.
– Keine Dokumentation vorhanden (Noch nicht einmal nach unterschriebener NDA)
– Antworten vom techn. Support sind mager und helfen einem nicht weiter (Hilflosigkeit)
– Schulungen kosten recht viel (bestehen aber aus 3 Tagen Unterrichtsmateiral inkl. Verpflegung)

[AdSense-A]

Neben den Punkten muss ich aus persönlicher Erfahrung sagen, dass die Schulungen durchaus recht kritisch verlaufen können.
Aus meiner persönlichen Erfahrung, habe ich mit einem Projektmanager von OXID Erfahrung gemacht, der von der Entwicklung nichts verstanden hat.
Im Prinzip muss ein Projektmanager nichts von einer Software verstehen, jedoch wenn er Schulungen unterrichtet, sollte er doch wenigstens die basics
für eine Software bzgl. der Entwicklung beherrschen. Daher ist das aus meiner Sicht ein großes Manko bei OXID. Natürlicherweise kann ich nicht beurteilen
ob dies denn immer der Fall ist, aber aus meiner Schulung für die Enterprise-Version kann ich dies auf jedenfall einmal so hier festhalten.

Entwicklung

OXID bietet ein Verzeichnis mit dem Namen “modules” an.
In diesem Verzeichnis lassen sich eigene Module hinterlegen, dabei kann man unterscheiden zwischen einzelnen Modulen und Vendor-Modulen.
Vendor-Module werden in eigenen Verzeichnissen innerhalb des Modules-Ordner hinterlegt.

Dieses Schema kann an der Stelle wie folgt aussehen:

Auch für OXID gibt es quasi eine Mapping-File, diese nennt sich “metadata.php”. Darin werden alle Dateien dem Autoloader von OXID
bekannt gemacht. Die dann wiederrum via die Funktion “oxNew” als Instanzen erzeugt werden können.

Diese Mapping-File sieht wie folgt aus:

<?php

/*
 * @author         N3X
 * @copyright      Copyright (c) 2014, Ilya Beliaev
 * @since          Version 1.0
 */

/**
 * Metadata version
 */
$sMetadataVersion = '1.1';

/**
 * Module information
 */
$aModule = array(
    'id'           => 'n3x_xml_api',
    'title'        => 'XML-API',
    'description'  => array(
        'de' => 'Verbinden Sie OXID mit anderen Systemen',
        'en' => 'Wire OXID with other Systems'
    ),
    'version'      => '1.0',
    'author'       => 'Ilya Beliaev',
    'url'          => 'http://php-dev.info',
    'email'        => 'info@php-dev.info',
	'extends' => array( // definiert Klassen welche erweitert werden sollen
		'oxviewconfig' => 'n3x/n3x_xml_api/core/n3x_xml_api_oxviewconfig',
	);
    'files'        => array( // Eigene Klassen
        //Controllers
        'n3x_xml_api'       => 'n3x/n3x_xml_api/application/controllers/n3x_xml_api.php',
        //Models
        //Core
        'xmlbase' => 'n3x/n3x_xml_api/core/xml/xmlbase.php',
    ),
    'templates' => array( // Definiert die Templates welche geladen werden sollen, wenn ein Attribut für Template definiert wurde
        'index.tpl' => 'n3x/n3x_xml_api/views/index.tpl',
    ),
    'settings'    => array( // definiert die Einstellungen für das Modul
        array(
            "group" => "webservice", //Gruppenname von OXID (Überschrift im Backend /Gruppe im Backend)
            "name" => "sIPAddresses", // Variablenname der via $this->getConfig()->getVariable("sIPAddresses"); geholt werden kann
            "type" => "str", // Datentyp
            "value" => "localhost", // Placeholder
        ),
    ),
);

Im Prinzip ist es immer wichtig, für die eigenen Klassen einen Prefix zu setzen. Im besten Fall ist der Prefix der Modulname.
Warum das so ist? Nun OXID nimmt ein Mapping anhand des Filesystems vor. Dementsprechend wenn es zwei Module gibt, in dem eine Klasse
den gleichen Namen hat wie in einem anderen Modul kommt es zu einem Konflikt, da dort unter umständen der Autoloader gar nicht weiß, welche Klasse
er zu laden hat. Dieser Fall tritt immer dann in Kraft, wenn es zwei gleichnamige Klassen, wo aus einem Modul versucht wird eine der beiden Klassen
via “oxNew” zu laden. Das führt im Endeffekt dann dazu, dass beide Klassen aus unabhänigen Modulen nicht geladen werden können.

Gleichnamige Methodennamen sollten ebenfalls vermieden werden. OXID basiert für das gesamte Frontend auf passiven MVC.
Dabei werden Controller-Methoden dort mittels $oView->Methode() aufgerufen und oxviewconfig-Erweiterungen mittels
$oViewConf->methodenname().

Aus diesem Grund sollten grundsätzlich gleichnamige Namen klassenunabhängig berücksichtigt werden. In dem Fall gilt es zu vermeiden,
dass es gleiche Methodennamen gibt innerhalb von verschiedenen Modulen.

Lesen Sie hier Teil 2 der Modulentwicklung