OXID – Modulentwicklung – Teil 2

[AdSense-A]

OXID

OXID – Modulentwicklung

OXID ist ein Shopsystem welches weit verbreitet ist. Auf diese Thematik war ich bereits im Vorfeld vor einer längeren Zeit bereits eingegangen.

In diesem Beitrag gehe ich darauf ein, wie sich einzelne Klassen ob nun Controller, Models oder Komponenten von OXID überladen lassen und wie einzelne neue Komponenten, Controller oder Models in OXID implementiert werden können, um den Standardumfang von OXID zu erweitern.

Was kann oder kann nicht erweitert werden?

OXID sieht im Grunde genommen vor, dass sich fast alle Klassen erweitern lassen. In einigen Fällen, wo die Erfahrung mit OXID fehlt, möchte man gerne bestimmte Klassen erweitern. Manchmal ist dies allerdings nicht möglich. Da OXID auch Klassen bietet, die sich in Ihrer Form nicht erweitern lassen. Es gibt drei Kategorien in denen sich Klassen nicht überladen lassen. Diese drei Kategorien sind folgende:

  • Admin-Bereich
  • Frontend-Controller
  • Core

Es gibt aber durch aus auch OXID Klassen die zwar überladen werden können, aber wo das Überladen der Klassen nur mit vorsichtig zu genießen ist, da sonst einige Neben-Auswirkungen entstehen können.

Admin-Bereich

Folgende OXID Klassen können nicht oder nur eingeschränkt überladen werden:

  • oxAdminDetails
  • oxAdminList
  • oxAdminView
  • dyn_interface
  • Dynscreen
  • DynExportBase
  • Article_List
  • GenImport_Main
  • Efire
  • Object_Seo
  • Order_List
  • Shop_Config
  • User_List

 

OXID Frontend-Controller

Auch zu den Frontend-Controllern gehören einige Klassen die entweder nicht überladen werden können, oder das Überladen der OXID Klassen mit vorsicht zu genießen ist. Dazu gehören folgende Klassen die nicht überladen werden können:

  •  oxView
  • oxStart
  • oxUBase
  • Account
  • GuestBook
  • User

Klassen die zwar überladen werden können, aber wo das Überladen wirklich nur mit vorsicht zu genießen ist sind folgende:

  • aList
  • Details

Diese beiden Klassen können zwar überladen werden, allerdings gibt es von diesen beiden Klassen auch erbende Klassen. Daher sollte ein gut überlegtes Konzept bestehen, bevor diese beiden Klassen überladen werden.

 

OXID Core-Klassen

Zum Schluss kommen wir einmal zu den Klassen die im Core zu finden sind und nicht überladen werden können:

  • oxBase
  • oxDb
  • oxLegacyDb
  • oxConnectionException
  • oxDynImgGenerator
  • oxErpBase
  • oxErpCsv
  • oxErpGenImport
  • oxExceptionToDisplay
  • oxField
  • oxI18n
  • oxLdap
  • oxList
  • oxOpenIdDb
  • oxOpenIdHTTPFetcher
  • oxSeoEncoder
  • oxSuperCfg
  • oxStdClass
  • oxSystemComponentException
  • oxSysRequirements
  • oxUtilsObject
  • oxConfigFile
  • oxRegistry

 

[AdSense-A]

Dabei ist zu beachten, dass die jeweiligen oxERP-Klassen nur dann vorhanden sind, wenn Sie das ERP-Modul von OXID verwenden.

Dazu finden Sie auch weitere Details auf dieser Seite.

 OXID Klassen überladen

Das Überladen von OXID-Klassen kann auf einem einfachen Weg geschehen. Den Punkt den Sie dabei einhalten müssen, ist die Konvention von OXID im Rahmen der Überladung einhalten.

Beim Überladen darf nicht von der Klasse geerbt werden, welche Sie überladen wollen.  Sondern muss von Ihrem Klassennamen erben mit dem Suffix “_parent”.

 

Beispiel:

 

<?php
class MyPrefix_oxBasket extends MyPrefix_oxBasket_parent{

}

In diesem Beispiel möchte ich das Model “oxBasket” überladen, welches sich im Verzeichnis “application/models” findet. Der Klassenname besteht aus einem Prefix. In meinem Falle dem Prefix “MyPRefix_” danach folgt der Klassenname der Klasse die ich überladen möchte “oxBasket”, diese Klasse hat die Basisklasse “MyPrefix_oxBasket_parent”. Das “_parent” ist nur wichtig beim Überladen von Klassen. Wenn Sie neue neue Controller Models oder andere Komponenten implementieren möchten, und nicht die Standardklassen erweitern wollen, so nehmen Sie dann die jeweiligen anderen Klassennamen als Basisklassen, nur beim Überladen kommt diese Konvention zum Einsatz.

Anschließend muss die neue Klasse in der metadata.php registriert werden. Erst wenn diese Klasse registriert ist, weiß OXID welche Klasse Sie überladen möchten.

Die Registration erfolgt im Array-Key “extend”.

 

<?php
$aModule = array(
	'extend' => array(
		'oxbasket' => 'MyModule/application/models/MyPrefix_oxBasket',
	),
);

In Diesem Fall liegt die obige Klasse im Modulverzeichnis MyModule/application/models und heißt MyPrefix_oxBasket.php .
Der File-Extension Typ wird beim Überladen von Klassen nicht angegeben. Wenn Sie OXID erweitern möchten, müssen sie diesen allerdings angeben. Dann allerdings registrieren Sie die Klasse nicht im Key “extend” sondern “files”.

Anschließend können Sie aus dieser Klasse auf alle Attribute oder Methoden der Klasse “oxBasket” zugreifen, oder diese Klasse um weitere Methoden oder Attribute erweitern.

 Nachladen von Klassen

Das Nachladen von Klassen können Sie einfach realisieren. Dazu gehe ich auf unsere bisherige Klasse ein, allerdings ohne einen Zusammenhang zu der OXID Basket-Klasse.

 

 

<?php

class MyPrefix_oxBasket extends MyPrefix_oxBasket_parent{

	public function getMyAddress($sOXID){
		$oAddress = oxNew("oxAddress");
		$oAddress->load($sOXID);
		return $oAddress;
	}
}

Mittels oxNew laden Sie eine Klasse nach und erzeugen ein Objekt dieser Klasse. Im Grunde genommen jedes Model in OXID hat eine Load Methode, welches den Primärschlüssel der jeweiligen Tabelle benötigt auf dessen Daten Sie zugreifen möchten. Dieser Primärschlüssel nennt sich “OxID”.

Views global Methoden bereitstellen

Wenn Sie gewisse Methoden im OXID-Shop zentral an jeder Stelle bereitstellen wollen (fast jeder Stelle), dann gibt es auch dazu eine Klasse die Sie dann erweitern sollten.

Die Klasse “oxviewconfig” ist in jedem View zu erreichen. Diese Klasse können Sie überladen um dem View jeweilige Methoden bereitzustellen.

Anschließend kann auf die Methoden via folgendes zugegriffen werden:

 

{[$oViewConf->myMethod()]}

An dieser Stelle hoffe ich, dass Sie einen tieferen Einblick in OXID bekommen konnten. Ein weiterer Artikel zu OXID folgt.

No Responses

Leave a Reply