Hello World – Mein erstes OXID eShop Modul

Am Wochenede habe ich mich mal ein wenig mit OXID eShops beschäftigt. Mit OSCommerce, XTCommerce und Magento haben wir in der Agentur schon des öfteren Projekte umgesetzt, mit OXID leider noch nicht. Die Version 4.6 gibt es seit Anfang April in einer Beta3 Version, ich habe mich für den Einstieg aber für die Stable Version 4.5.9 entschieden – natürlich in der GPLv3 Community Edition.

So genug der schönen Worte, lasst uns ein Modul entwickeln. Der Nutzen sei erst mal zweitrangig, es geht darum, die grundsätzliche Funktionsweise der OXID Modulentwicklung zu betrachten und verstehen. OXID hat diese Aufgabenstellung ganz elegant gelöst. Eigene Module kann man durch das überschreiben der vorhandenen Core Klassen so programmieren, dass der Core unberührt bleibt und spätere Updates somit keine Problem machen. Um das erste Modul simple zu halten, beschränke ich mich auf die Manipulation der Ausgabe, genauer möchte ich gerne die Ersparnis bei einem reduzierten Artikel ausgeben. In weiteren Artikeln werde ich dann eventuell anspruchsvollere Aufgaben ergänzen.

Los gehts: Eigene Module gehören in den Ordner /modules/ und werden dort in eigenen Ordnern abgelegt. Da OXID noch keine Namespaces unterstützt, ist es sinnvoll bei eigenen Modulen einen Prefix zu benutzen, damit es keine Konflikte mit anderen Modulen gibt. Dementsprechend benenne ich meinen Ordner “udoPriceSaving”. Darein kommt nun die folgende udoPriceSaving.php Datei:

<?php
/**
 * PHP version 5.3.6
 *
 * @author      Udo Telaar <[email protected]>
 * @license     GPLv3
 * @copyright   Copyright (c) 2012 Udo Telaar
 * @link        http://www.udo-telaar.de
 * @version     $Id:$
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.

 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.

 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

/**
 * udoPriceSaving
 *
 * @author      Udo Telaar <[email protected]>
 */
class udoPriceSaving extends udoPriceSaving_parent
{
    /* @var $this oxArticle */

    public function getPriceSaving()
    {
        if ($this->getFTPrice() > $this->getFPrice()) {
            return $this->getFTPrice() - $this->getFPrice();
        }
    }
}

So, im Grunde sind wir jetzt schon fast fertig, aber wie soll das funktionieren – “extends udoPriceSaving_parent”? So eine Klasse gibt es doch gar nicht!? Und das ist der Clou an der Sache. Im OXID Backend kann man jetzt unter “Stammdaten -> Grundeinstellungen -> Module” angeben welche Core Klasse udoPriceSaving erweitern soll. udoPriceSaving_parent zeigt in unserem Fall quasi auf oxArticle

oxid_modul_programmieren_admin

Wenn diese Zeile dort eingetragen wurde, kann die zusätzliche Funktion “getPriceSaving” genauso genutzt werden, wie alle von oxArticle geerbten Funktionen. Das machen wir uns dann auch direkt im Produkt Template zu nutze. Dieses liegt unter /out/azure/tpl/page/details/inc/productmain.tpl und wir ergänzen dort die Zeilen 7-11.

[{oxhasrights ident="SHOWARTICLEPRICE"}]
    [{if $oDetailsProduct->getFTPrice() > $oDetailsProduct->getFPrice()}]
        <p class="oldPrice">
            <strong>[{oxmultilang ident="DETAILS_REDUCEDFROM"}] <del>[{$oDetailsProduct->getFTPrice()}] [{$currency->sign}]</del></strong>
        </p>
   [{/if}]
   [{if $oDetailsProduct->getPriceSaving()}]
       <span class="priceOld">
           [{ oxmultilang ident="DETAILS_PRICESAVING" }] [{ $oDetailsProduct->getPriceSaving()}] [{ $currency->sign}]
       </span>
   [{/if}]
[{/oxhasrights}]

Das fertige Ergebnis sollte dann wie folgt aussehen. Die linke Seite zeigt einen reduzierten Artikel mit der entsprechenden Berechnung (DETAILS_PRICESAVING muss hier noch übersetzt werden), die rechte einen nicht reduzierten Artikel:

oxid_modul_programmieren_product

Fazit:
Anpassungen können bei OXID recht einfach über die modulare Bauweise vorgenommen werden. Jetzt haben wir hier natürlich ein recht einfaches Beispiel genommen. Ob sich die Lage bei komplexeren Problemstellungen oder mehrfach überschriebenen Core Klassen nicht komplizierter darstellt, bleibt noch herauszufinden.

Moderne Programmiertechniken ala Dependency Injection und Aspect-oriented programming wie sie von modernen Frameworks wie Flow3 und Zend Framework 2 verwendet werden, findet man bei OXID leider nicht. Auch muss man auf die Features von PHP 5.3 verzichten. Bislang hat aber noch niemand eine Open Source Software veröffentlicht, die dieses alles erfüllt. Alles in allem erhält man aber eine übersichtliche Shopsoftware mit steiler Lernkurve, die es sicherlich verient hat noch weiter unter die Lupe genommen zu werden.



0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.