Diese Thematik bietet die Basis für die in meinem Workshop beschriebenen Schritte, um das OXID Framework (OF) auch für eigene Anwendungen – fern der Ecommerce-Welt – nutzen zu können.

Der Artikel im PHPmagazin nimmt Bezug auf meinen ursprünglich geplanten Vortrag bei den OXID Commons. Natürlich musste der Artikel schon im April abgegeben werden, als ich noch nicht ahnen konnte, dass ich meine Commons-Teilnahme krankheitsbedingt würde absagen müssen. Der Inhalt des dort ausgefallenen Vortrags ist ja nun hier im Blog verfügbar.

Fragen zum Artikel und/oder zum Workshop beantworte ich gerne hier im Blog. Nutzt die Kommentarfunktion.

Bzgl. des Projekterfassungs-Toos erhielt ich bereits gestern zwei Rückmeldungen von interessierten PHP-Entwicklern, die sich vorstellen können, daran mitzuarbeiten, dieses Projekt weiter auszubauen. Ich werde also versuchen, so schnell wie möglich dafür zu sorgen, dass das Ganze kollaborationsfähig als OXIDforge-Projekt zur Verfügung steht!

In diesem dritten und letzten Teil meines kleinen Workshops werde ich die Implementierung eigener Datenbanktabellen und damit verknüpfter core-Objekte demonstrieren. Dies bildet die Grundlage für die weitere Anwendungsentwicklung.

Am Ende des Beitrages steht dann der komplette Quellcode zum Download zur Verfügung.

oxid4project Projektdatenerfassung

Bisher hatten wir lediglich eine Login-Seite und eine noch ziemlich leere Startseite für das Projekterfassungs-Tool erstellt. Bevor wir das Ganze nun mit nützlicher Funktionalität füllen, wollen wir uns zunächst an die notwendigen core-Objekte machen.

Wie schon in Teil 1 beschrieben, benötigen wir folgende Objekte:

- Mitarbeiter / User: hier nutzen wir OXID Standardfunktionalität
- Projekte: dafür wird eine eigene core-Klasse benötigt
- Zeit- und Texterfassung: auch hierfür mache eine eigene core-Klasse Sinn
- Auswertungen: ebenfalls eine eigene core-Klasse

Um den Bereich “Mitarbeiter” kümmern wir uns im Moment überhaupt nicht – das erledigen wir komplett mit OXID-Standards. Für die Projektstammdaten sieht das anders aus:

Neues Objekt: Projekt(e) – Datenfelder

Um die Projektstammdaten zu erfassen, benötigen wir zunächst eine eigene Tabelle:

CREATE TABLE `azprojects` (
`OXID` varchar(32)  NOT NULL,
`AZTITLE` varchar(150) NOT NULL,
`AZPRICEPERHOUR` double NOT NULL,
PRIMARY KEY (`OXID`)
);

Wir beschränken uns hier auf eine eindeutige ID, einen Titel und den Stundensatz. Um nicht mit OXID-eigenen Konventionen in Konflikt zu geraten, sollten eigene Tabellen und Tabellenfelder grundsätzlich ein eigenes Prefix bekommen – ich nutze stets “AZ” dafür. Eine Ausnahme bildet in unserer neu angelegten Tabelle allerdings das Feld OXID.

Im OXID Framework (OF) hat die sog. OX-ID eine besondere Stellung. Diese ID ist in allen Tabellen der primary key und somit immer die eindeutige ID für jeden Datensatz. Anhand dieser ID laden die OF-Basisklassen Inhalte in die Objekte hinein. Damit wir diesen sehr komfortablen Mechanismus nutzen können, müssen wir unserer Tabelle ebenfalls eine OX-ID geben.

Nun brauchen wir noch die zugehörige core-Klasse, die als Minimalversion so aussieht:

class azproject extends oxI18n
{
    protected $_sCoreTbl = 'azprojects';
    protected $_sClassName = 'azprojcect';

    public function __construct()
    {
        parent::__construct();
        $this->init( 'azprojects' );
    }
}

Erläuterung:
Wir deklarieren die Klasse azproject als Extension von oxI18n. Diese Klasse wiederum ist Extension der Klasse oxBase – und die wiederum ist Extension von oxSuperCfg. Von dieser Vererbungskette profitieren wir in mehrfacher Hinsicht:

• oxSuperCfg: stellt uns mit Session- und Config-Objektgettern das Fundament des OF zur Verfügung
• oxBase: enthält alle Kernfunktionen für Datenobjekte, inkl. der notwendigen Methoden, um Daten aus Tabellen in Objekteigenschaften zu überführen und umgekehrt
• oxI18n: ist die sog. “Internationalization” Klasse, in der diverse Mechanismen hinterlegt sind, die es recht einfach machen, die Datenobjekte auch mehrsprachig zu pflegen. (Wir werden das im aktuellen Projekt nicht nutzen, aber um das Projekt möglichst universell nutzen zu können, macht es Sinn, diese Option hier zumindest mit einzubinden.)

Dieser OF-Komfort sorgt dafür, dass unsere eigene core-Klasse ziemlich bescheiden bleiben kann. Im Grunde definieren wir dort nur den Namen unseres Objektes ($_sClassName) und den Namen der Tabelle, aus der die Daten kommen ($_sCoreTbl). Das reicht bereits, um das grundlegende Handling unserer Projektstammdaten zu erledigen.

Wie das Ganze ins Template eingebunden wird, entnehmt ihr bitte dem Quellcode, der ja zum Download bereitliegt. Ich will hier nur kurz noch zeigen, wie nun das besagte Handling der Daten in die entsprechende View-Klasse azprojectsstart eingebunden wird.

Zuvor brauchen wir aber noch eine weitere core-Klasse – und zwar für ein Listenobjekt der Projektstammdaten. Warum das? – Nun, das OF enthält für nahezu alle Daten(core-)objekte jeweils eine Klasse für das Einzelobjekt und eine Klasse für das entsprechende Listenobjekt (z. B.: oxarticle / oxarticlelist, oxcategory / oxcategorylist, oxuser / oxuserlist etc.). Während die Klassen der Einzelobjekte wie oben beschrieben Extensions von oxBase oder oxI18n sind, sind die Listenklassen Extensions vonoxList. Die Klasse oxList implementiert einige vordefinierte Interfaces (ArrayAccess, Iterator, Countable) und bietet damit komfortable Möglichkeiten für den Umgang mit Objekten. Viel interessanter sind aber einige Standardmethoden dieser Klasse – wie z. B. selectString() – die einem das Leben extrem leicht machen können. Wir werden gleich sehen, was das konkret bedeutet. Zunächst aber legen wir unsere Listenklasse azprojectlist an wie folgt:

class azProjectList extends oxList
{
    public function __construct( $sObjectsInListName = 'azproject')
    {
        return parent::__construct( 'azproject');
    }
}

Core-Objekt für Projektstammdaten in View-Klasse nutzen

Auf der Startseite für unser Tool soll die komplette Datenerfassung erfolgen. Hier sollen auch neue Projekte mit ihrem aktuellen Stundensatz angelegt werden können. Die vorhandenen Projekte sollen über ein Dropdown-Menü ausgewählt werden können:

oxid4project - Projektdatenerfassung

Die Befüllung des Dropdown-Menüs erfolgt, indem wir in der View-Klasse azprojectsstart einen entsprechenden Getter implementieren:

public function getProjects()
{
  $oProjectList = oxNew("azprojectlist");
  $oProjectList->selectString("select oxid, aztitle from azprojects order by aztitle");

  return $oProjectList->getArray();
}

<select name="azdata[azjobs__azprojectid]">
  <option value=""> -- Projekt auswählen -- </option>
  [{foreach from=$oView->getProjects() item=oProject}]
    <option value="[{$oProject->azprojects__oxid->value}]"
      [{if $actProject == $oProject->azprojects__oxid->value}]selected[{/if}]>
      [{$oProject->azprojects__aztitle->value}]
    </option>
  [{/foreach}]
</select>

Auch hier eine kurze Erläuterung:
Der Getter azprojectstart::getProjects() instanziiert ein neues Objekt der Listeklasse azprojectlist. Dies erfolgt mittels der (Factory-)Funktion oxNew(). Auch hier steckt wieder viel Komfort und Know How des OF’s drin: Die Funktion oxNew() sorgt z. B. dafür, dass – falls vorhanden – Module für die instanziierten Klassen berücksichtigt werden.

Auf dem Listenklassenobjekt können wir nun die Methode selectString() ausführen, die als Parameter ein simples Datenbankquery bekommt. Diese Methode sorgt nun dafür, dass das Listenobjekt $oProjectList als protected property ein Array enthält, welches die Einzelobjekte sämtlicher Datensätze enthält, die über das Query gefunden wurden. Über die (public) Methode getArray() auf dem Listenobjekt können wir diese Liste nun abrufen und darüber iterieren (siehe Template).

Neue Stammdaten via Core-Objekt in der Datenbank speichern

Nun fehlt noch das Speichern von neuen Projektstammdaten in der Datenbank. Um auch das ohne viel Aufwand erledigen zu können, kommt es darauf an, die Daten in einer speziellen Struktur zu erfassen, die der OF-eigenen Struktur bei Datenobjekten entspricht:

[Objektname]->[Tabellenname]__[Feldname]->value

Dementsprechend erhält unsere View-Klasse azprojectsstart nun folgende (protected) Methode:

protected function _createNewProject($title, $dPricePerHour)
{
  $id = oxDb::getDb()->GetOne("select oxid from azprojects where aztitle = '$title'");
  if(!empty($id)) {
    $this->_aErrorMsg[] = "Projekt schon vorhanden!";
    return "error";
  }

  $oProject = oxNew("azproject");
  $oProject->azprojects__aztitle->value = $title;
  $oProject->azprojects__azpriceperhour->value = $dPricePerHour;
  $oProject->save();

  return $oProject->getId();
}

Zunächst überprüfen wir, ob evtl. schon ein Projekt mit demselben Namen existiert und übergeben ggf. eine entsprechende Fehlermeldung. Konnte das neue Projekt erfolgreich angelegt werden, so wird die (OX-)ID des neuen Datensatzes zurückgeliefert.

Die Erfassung der Projekt- bzw. “Job”-Daten

Wenn wir zuvor einige Beispielprojekte mit Stundensätzen angelegt haben, so können wir nun an die eigentliche Erfassung der Daten der einzelnen Jobs gehen. “Job” meint hier eine Arbeitseinheit eines Entwicklers an einem bestimmten Projekt.

Vom Grundprinzip her funktioniert das auf dieselbe Weise wie oben bei den Projektstammdaten beschrieben: Wir benötigen zwei core-Klassen azjob und azjoblist, dazu natürlich eine entsprechende Datenbanktabelle und noch die Einbindung in die View-Klasse azprojectsstart. Und da das Ganze hier ja ein Workshop sein soll (bzw. auf der Commons sein sollte …), kann das nun jeder für sich ausprobieren – oder aber sich im mitgelieferten Quellcode einfach anschauen, wie ich es gelöst habe.

Ein paar hilfreiche Hinweise zum Schluss

Da der gesamte Beitrag hier nun bereits deutlich länger geworden ist, als gedacht, möchte ich für den Rest der Anwendung auf den überlassenen Quellcode verweisen. Auf ein paar Dinge möchte ich aber noch hinweisen, weil sie ohne tiefergehende OXID-Kenntnis nicht sofort selbsterklärend sind:

functions.php
Innerhalb des modules-Verzeichnisses gibt es eine Datei functions.php, die standardmässig leer ist (abgesehen von einigen Kommentaren). Diese Datei ist dafür gedacht, eigene Funktionen anzulegen, die dann in allen übrigen PHP-Klassen genutzt werden können.
Kleiner Praxistipp: Es empfiehlt sich, die eigenen Funktionen in eine extra Datei auszulagern und in der Datei functions.php über includes einzubinden. Grund: Sollten einmal externe Module in die Anwendung eingebunden werden, die ebenfalls eigene Funktionen mitbringen, so müssen diese nicht jedes Mal in der functions.php zusammengeführt werden sondern es reicht dann das Hinzufügen einer weiteren include-Zeile.

Da es sich hier um Funktionen handelt und nicht um in Klassen gekapselte Methoden, sollten diese von vornherein eindeutig benannt werden, indem z. B. ein eindeutiges Prefix vorangestellt wird (in meinem Falle “az”).

Ich habe hier 2 Funktionen untergebracht, die für die Dropdowns Datum und Zeitaufwand benutzt werden, um hier sämtliche Daten der letzten 180 Tage sowie Zeitabschnitte in Viertelstundenschritten anzeigen zu lassen.

Für die restliche Funktionalität verzichte ich hier auf weitere Erläuterungen. Jeder kann sich diese anhand des mitglieferten Quellcodes selbst erschließen.

Abschließende Hinweise zu einer möglichen Weiterentwicklung des Projektes

Wer das Gesamtpaket einmal installiert und testet, wird schnell feststellen, dass hier noch etliche Wünsche offen bleiben. Speziell im Bereich der Auswertung könnte man sich noch viele nützliche Funktionen vorstellen. Gerade deshalb möchte ich das Projekt nun der Community zur Verfügung stellen, damit jeder, der Lust und Zeit hat, am Ausbau und an einer Verbesserung des Tools mitwirken kann. Wie schon gesagt werde ich versuchen, das Ganze schnellstmöglich als Projekt auf OXIDforge anzulegen, damit dann über diese Plattform eine gordnete Weiterentwicklung für Interessierte möglich wird.

Ein interessanter Aspekt der Weiterentwicklung könnte z. B. die Vereinfachung bei der Rechnungsstellung sein. Schließlich werkelt im Hintergrund ja ein Shop-Framework – es läge von daher nahe, aus abgerechneten Jobs Bestellungen zu generieren und hier dann entweder das Rechnungs-PDF des Shops zu nutzen oder aber die Daten über eine Schnittstelle in ein ERP-System zu überführen und dort dann automatisiert Rechnungen zu erstellen. Dafür müssten dann natürlich noch die Projektstammdaten mit Kundenstammdaten verknüpft werden, um einen vollständigen Bestelldatensatz generieren zu können. Das sollte sich aber durchaus machen lassen.

Jeder, der hier weiterführende Ideen beisteuern kann, ist herzlich eingeladen, sich an der Weiterentwicklung zu beteiligen! Sobald vorhanden, werde ich hier die entsprechenden Daten und Links bzgl. OXIDforge veröffentlichen.

Schlussbetrachtung im Kontext der zurückliegenden OXID Commons

Nachdem ich vorgestern den ersten Teil des Workshops hier veröffentlicht hatte, erhielt ich im Blick auf meine krankheitsbedingte Absage für die Commons kurz darauf einen Tweet von Roland Fesenmayr, den ich hier kurz zitieren möchte:

Wenn ich das lese, noch mehr schade, daß Du krank warst … hätte perfekt gepasst!

Tja, das habe ich auch mehrfach gedacht, als ich die Live-Streams der Commons aus dem Krankenbett heraus mitverfolgte. Da war ja mehrfach die Rede von einem “Ecommerce Betriebssystem” welches modular aufgebaut sein soll und bei dem sich der Shopbetreiber passend zu seinem individuellen Geschäftsmodell genau die Komponenten auswählen kann, die ihm hilfreich erscheinen.

Nun ist ein Projekterfassungs-Tool nicht gerade ein “Geschäftsmodell” im Rahmen des Ecommerce. Dennoch zeigt mein Beispiel, wozu das OXID-Framework prinzipiell bereits jetzt fähig ist. Wir haben hier eben kein total starres System, das ausschließlich auf fest definierte Ecommerce-Szenarien abgestellt ist – sondern wir haben hier bereits heute einen Baukasten vor uns, der – richtig genutzt – an so ziemlich jedes Geschäftsmodell angepasst werden kann.

Nicht erst seit der Commons ist klar, dass aktuell ein frischer Wind durch die Ecommerce-Landschaft bläst. Noch ist das eher ein laues Lüftchen, das aber – nicht zuletzt durch die Verbreitung des iPads – spürbar an Fahrt aufnimmt. Einkaufen im Internet ist nicht mehr bloß die Besorgung von Dingen, für die man früher in ein Ladengeschäft stiefelte – Einkaufen im Internet bekommt mehr und mehr eine eigenständige Erlebnisqualität. Während Onlineshops lange Zeit versuchten, das Einkaufen im Ladengeschäft möglichst originalgetreu nachzubilden, gibt es mehr und mehr Features, die dem Onlinekauf einen echten Mehrwert geben. Das sind so Dinge wie z. B. die Möglichkeit von Preisvergleichen, der Austausch in sozialen Netzwerken – das sind aber auch neue technische Möglichkeiten. Ich freue mich schon darauf, wenn ich zum ersten Mal ein Bild meines Wohnzimmers in mein (hoffentlich bald verfügbares) iPad einlesen kann und die Möbel aus dem Onlineshop mit den Fingern in meinem Wohnzimmer hin und herschieben kann.

Alles, was da auf uns zukommt, wird um so spannender werden, je flexibler die Softwarekomponenten sind, die zur Umsetzung der verschiedensten Ideen zur Verfügung stehen – und je offener die Schnittstellen dieser Komponenten untereinander sind. Möglicherweise läuft ein Onlineshop dann auf Basis von 10 verschiedenen Komponenten, die auf 10 verschiedenen Webservern (oder in 10 verschiedenen Clouds?) laufen.

Mit meinem Beispiel eines Projekterfassungs-Tools wollte ich demonstrieren, dass das OXID Framework m. E. schon jetzt die Flexibilität und Offenheit bietet, um darauf (fast) alles Mögliche zu bauen. Zumindest ist OXID hier auf einem guten Weg.

Hinweise zum Download

Der Download, der hier angeboten wird, ist ein Vorabangebot. Die Benutzung erfolgt komplett auf eigene Gefahr. Voraussetzung für die Nutzung der hier zur Verfügung gestellten Dateien ist eine frisch installierte OXID Community Edition 4.3.

oxid4project Sourcen

oxid4project Login Screen

Der Beitrag insgesamt verfolgt damit folgende Ziele:

1. einen generellen Einblick in das OXID Framework (OF) geben
2. zeigen, dass man damit nicht nur Onlineshops programmieren kann
3. hilfreiche Tipps geben für den Umgang mit dem OF, die auch im Rahmen von Shops sehr nützlich sind.

Am Anfang steht das Konzept: Welche Grundelemente werden benötigt?

Es macht so gut wie nie Sinn, einfach drauf los zu coden – vor allem dann nicht, wenn man ein vorhandenes Framework nutzen will. Um herauszufinden, welche Teile des Frameworks sich am sinnvollsten für die eigene Applikation nutzen lassen, sollte man zunächst die benötigten Grundelemente definieren. Diese Definition soll dabei so erfolgen, dass jedes der genannten Grundelemente sich nach Möglichkeit bereits als Objekt denken lässt. Oder anders gesagt: Wir suchen nach klar abgrenzbaren Sach- und Funktionsbereichen in unserer geplanten Anwendung, die sinnvoll im Rahmen einzelner Klassen gekapselt werden können.

Für unsere Projekterfassung benötigen wir folgende Bereiche / Elemente:

• Projekte: Projekt anlegen, löschen, editieren, auflisten …
• Mitarbeiter: anlegen, löschen, editieren, Login … => OXID Userverwaltung
• Erfassung von Arbeitseinheiten: Zeit- und Texterfassung, Bearbeitung von Einträgen, Löschen …
• Auswertungen: nur für Admin sicht- und nutzbar, über Frontend erreichbar (also nicht im Shop-Admin)

Aus dieser Definition ergibt sich ein Konzept für die benötigten Views und Templates sowie für sinnvolle Core-Objekte. Fangen wir pragmatisch mit den Views und Templates an:

Konzeption der Views und Templates

Die gesamte Anwendung soll im Endeffekt ja auf einem Webserver im Netz laufen, damit jeder Mitarbeiter das Tool nutzen kann, wo immer er sich auch gerade befindet. Also brauchen wir zunächst einmal einen Login-Bereich. Wie oben schon angedeutet, können wir hier komplett die OXID Standardfunktionalität der Benutzerverwaltung nutzen.
Als nächstes brauchen wir eine Zeit- und Texterfassungsmaske, in der die Mitarbeiter ein Projekt auswählen und eintragen können, wie lange sie daran gearbeitet haben und was genau sie in dieser Zeit gemacht haben.
Für die eigentliche Datenerfassung ist das schon alles. Allerdings will ich als Admin ja auch ein paar Auswertungsmöglichkeiten haben. Also fehlen noch folgende Views / Templates:

• Listenseite(n) für Auswertungen (z. B.: alle noch nicht abgerechneten Projekte im Monat “X” etc.)
• Detailseite für Auswertungen (z. B.: alle noch nicht abgerechneten Arbeitseinheiten von Projekt “Y” im Monat “X” etc.)
• Detailseite für Bearbeitung von Einzeleinträgen, z. B. wegen Korrekturen, Abzug von nicht abrechenbaren Zeiten etc.

Let’s code! – Login-Seite

Die Login-Seite ist im Grunde der einfachste Teil der gesamten Übung, weil wir hier zu nahezu 100% auf OXID Standardfunktionalität zurückgreifen können. Dennoch kann man bereits hier den ein oder anderen hilfreichen Tipp für den generellen Umgang mit dem OXID Framework unterbringen. Daher das Ganze nun etwas ausführlicher:

Wir brauchen eine View-Klasse und ein zugehöriges Template. Die View-Klasse gestaltet sich dabei ausgesprochen simpel:

class azprojectsLogin extends oxUbase
{
  /**
   * name of template file
   * @var str
   */
  protected $_sThisTemplate = "azprojectslogin.tpl";

  /**
   * calls parent (oxUbase) render and returns name of tpl file
   * @return str $this->_sThisTemplate
   *
   */
  public function render() {
    parent::render();

    return $this->_sThisTemplate;
  }
}

Jede View-Klasse im OF ist Extension der Klasse oxUbase. Wir verwenden diese Vererbung, um gewisse Grundmechanismen im OF automatisch mitnutzen zu können. Dabei ist zu beachten, dass eine View-Klasse dann auch immer eine public function render() besitzen muss, die a.) die parent::render() aufruft und b.) als return-Wert den Namen der Template-Datei zurückliefert.
Damit sind die Mindestanforderungen für eine eigene View-Klasse bereits erfüllt. Gesagt sei noch, dass der Dateiname der Klasse sinnvollerweise mit dem Klassennamen identisch sein – allerdings komplett in Kleinbuchstaben gehalten sein sollte. So vermeidet man Probleme beim Switch zwischen verschiedenen Betriebssystemen (z. B. Windows / Mac / BSD / Linux etc.).

Als nächstes machen wir uns nun an das Template heran. Dieses sollte am Ende in etwa so aussehen wie der Screenshot am Anfang dieses Beitrags (oxid4project Login-Screen).

Hier kommt es natürlich nicht auf das konkrete Layout an – das möge sich jeder so gestalten, wie es ihm gefällt. Ich möchte lediglich auf ein paar Grundzüge bei der Templategestaltung hinweisen.

Im OXID eShop besteht nahezu jede im Frontend sichtbare Seite aus mind. 6 Einzeltemplates, die in Form von includes eingebunden werden:

1. something.tpl – Die Template-Datei, die von der aktuell aufgerufenen View-Klasse als return-Wert der render() function zurückgeliefert wird. Name ist natürlich für jede Seite anders. Hier erscheint der eigentliche Content der jeweiligen Seite.
2. _header.tpl – Der Kopfbereich der Seite; wird innerhalb von something.tpl inkludiert.
3. _footer.tpl – Der Fußbereich der Seite; wird innerhalb von something.tpl inkludiert.
4. _path.tpl – Anzeige der Breadcrumb-Navigation.
5. _left.tpl – Navigationsbereich auf der linken Seite; wird innerhalb von _header.tpl inkludiert.
6. _right.tpl – Bereich für Aktionsboxen auf der rechten Seite; wird innerhalb von _header.tpl inkludiert.

Den größten Teil der Inhalte dieser OXID-Standardtemplatedateien benötigen wir für unser Projekt nicht. Also bauen wir uns stark vereinfachte eigene include-Dateien. Die generelle Nutzung des Grundschemas mit includes macht Sinn, da wir für unser kleines Tool ja auch eine ansprechende Optik wünschen und sich im Kopfbereich z. B. gut einige administrative Navigationspunkte unterbringen lassen, die damit dann automatisch auf jeder Seite sichtbar sind.

Einen speziellen Bereich auf der linken oder rechten Seite brauchen wir nicht, weshalb die entsprechenden includes komplett entfallen können. Dasselbe gilt für die Breadcrumb Navigation, die im Shop vor allem den Kategoriepfad nachbildet, den wir in unserer Anwendung überhaupt nicht benutzen.

Wie die Templates im einzelnen aussehen, kann sich jeder anhand der Beispieldateien selbst ansehen. (In Kürze möchte ich das Ganze als Projekt auf OXIDforge anlegen. Leider kann ich dort zur Zeit keinen Account erstellen … daher gibt’s die Dateien zunächst mal als Download hier im Blog. -> siehe Ende des Beitrags)

Hier sei nur erwähnt, dass ich mich für die aktuelle Anwendung entschieden habe, zwei eigene include-Dateien azprojectsheader.tpl und azprojectsfooter.tpl zu erstellen. In beiden Dateien ist nur das Nötigste enthalten. Auf ein paar Dinge möchte ich aber hinweisen:

dynamischer Seitentitel
Im Grunde soll jeder selbst entscheiden ob und welchen Seitentitel er für dieses Tool benutzen möchte. Ich habe mich daher dafür entschieden, den Shopnamen hier als dynamischen Wert einzusetzen, da dieser über den Shop-Adminbereich leicht änderbar ist. Die Einbindung sieht aus wie folgt:

Projekterfassung - [{$oxcmp_shop->oxshops__oxname->value}]

Einbindung von Bildern
Bilder, die im Rahmen des Layouts benötigt werden, liegen im OF immer im Verzeichnis /out/basic/img. Dieser Pfad ist innerhalb der Templates abrufbar mittels der Methode $oViewConf->getImageUrl(). Es empfiehlt sich, diese Systematik beizubehalten, weil so auch später das Verlagern der Grafiken in einen anderen Pfad oder auf einen anderen Server sehr einfach zu realisieren ist, ohne gleich alle Templates ändern zu müssen.

HomeLink
Auf dem Logo oben links liegt – wie gemeinhin üblich – der Link zur Startseite unserer Anwendung. Im OF gibt es auch dafür eine eigene Methode, die innerhalb der Templates genutzt werden kann: $oViewConf->getHomeLink().

Sonstige Links
In der Templatedatei azprojectsheader.tpl finden sich einige Navigationslinks, die weitere (eigene) View-Klassen aufrufen sollen. Dies erfolgt innerhalb des OF generell via:

<a href="[{ $oViewConf->getSelfLink() }]cl=myclassname">Linktext</a>

Navigation nur für eingloggte User anzeigen

Die Navigation im Kopfbereich (Erfassung, Auswertung, Logout) sollte natürlich nur für eingeloggte User zu sehen sein. Dies erreichen wir sehr einfach über die folgende Abfrage im Template /out/basic/tpl/azprojectsheader.tpl:

[{ if $oxcmp_user->oxuser__oxpassword->value }]
...
[{ /if }]

Login-Funktionalität

Für die eigentliche Login-Funktionalität nutzen wir zu 100% OXID-Bordmittel. Das Login / Logout-Formular können wir komplett aus dem include-Template /out/basic/tpl/inc/cmp_login.tpl übernehmen. Der Klassenparameter, der in diesem Formular als hidden field “cl” übergeben wird, wird hier dynamisch mit der aktuell aufgerufenen View-Klasse gefüllt. Außerdem finden wir in dem Formular noch ein hidden field mit name=”fnc” – dieses dient dazu, eine spezielle Methode auf der View-Klasse auszuführen. Der Name dieser Methode ist – je nach Zustand – login_noredirect oder logout.

In unserer View-Klasse azprojectslogin gibt es aber weder die eine noch die andere Methode. Das macht aber nichts – denn beide Methoden gehören zum Komponentenobjekt oxcmp_user und – wie oben schon erwähnt – stehen die Komponentenobjekte überall zur Verfügung. Und deshalb können wir auch die Methoden dieser Objekte an beliebiger Stelle aufrufen.

Umleitung der Startseite
Eine Kleinigkeit fehlt noch: Bisher bekommen wir noch immer die Startseite des Shops zu sehen, wenn wir unsere Anwendung ohne weitere Parameter aufrufen. Um das zu ändern legen wir ein kleines Modul der View-Klasse start an. Dazu erstellen wir eine Moduldatei mit dem Namen azstart.php mit folgendem Inhalt:

class azStart extends azStart_parent
{
  public function init()
    {
      header("location: index.php?cl=azprojectsstart");
    }

}

Die Grundlage ist geschaffen

Bis hierher haben wir nun also die Grundlage für das geplante Tool geschaffen. Es fehlt noch die eigentliche Funktionalität – die ich in Teil 3 dieses Workshops präsentieren möchte. Aber ich denke, man konnte bis hier her bereits eine Ahnung dafür entwickeln, dass das OF viele Möglichkeiten für eigene Entwicklungen bietet. Diesem Beitrag hängt nun auch der erste Teil des Quellcodes des Projektes an, so dass die oben beschriebenen Punkte direkt nachvollzogen werden können.

Mit dem dritten Teil werde ich dann den kompletten Quellcode des Projektes liefern – vielleicht dann ja schon als OXIDforge-Projekt. Hier schon einmal ein Vorab-Happen: oxid4project_source_part_1

Da ich die letzten 3 Tage zeitweise fiebernd überwiegend im Bett verbracht habe, war diese Entscheidung aber rückblickend wohl die richtige. Ich hätte den Donnerstag vermutlich nicht durchgestanden.

Ich bedanke mich auf diesem Wege für die vielen Genesungswünsche, die mich in den letzten Tagen speziell aus den Reihen der Commons erreicht haben. Mehrfach schrieb man mir: “Schade – ich hatte mich so auf deinen Workshop gefreut …”
Den Workshop an sich kann ich nun nicht wirklich nachliefern – aber ich möchte hier nun zumindest grob erläutern, worum es in dem Workshop gegangen wäre. Am Ende des letzten Teiles werde ich auch den entsprechenden Quellcode zur Verfügung stellen.

OXID eShop als Werkzeugkasten für eigene Anwendungen

OXID4ALL – Es muss ja nicht immer ein Shop sein …

Das OXID eShop Framework als Werzkeugkasten für eigene Anwendungen

Hauptziel des Workshops sollte sein, einmal an einem praktischen Beispiel zu zeigen, vie vielseitig man das OXID eShop Framework einsetzen kann – und dass es dabei eben nicht immer nur um Shop-Projekte gehen muss. “OXID4ALL” ist daher nicht nur gemeint im Sinne von: “OXID für alle!” – sondern eben auch im Sinne von: “OXID für alles?” – Das Fragezeichen ist hier bewusst gewählt, weil man die Art und Weise wie das OXID-Framework im folgenden Beispiel verwendet wird, sicher auch kritisch betrachten kann. Trotzdem denke ich, kann man auf diese Weise recht gut demonstrieren, wie viel Potential in diesem Framework steckt.

Wie alles begann: Auf der Suche nach einer einfachen Projekterfassungssoftware

Vor etwa 1 1/2 Jahren war ich auf der Suche nach einer Software, mit der unsere Entwickler schnell und einfach erfassen konnten, was sie an welchem Projekt gerade gearbeitet hatten. Die Software sollte preiswert sein, leicht zu handhaben, netzwerkfähig und nach eigenen Bedürfnissen anpassbar. Folgende Anforderungen stellte ich anfangs an die gesuchte Software:

• Login für Mitarbeiter
• Eintragen von Projekten mit jeweiligem Stundensatz
• Erfassung der Zeiten: wann wurde von wem wie lange an welchem Projekt was gearbeitet?
• Vereinfachung der monatlichen Rechnungsstellung
• Platz für interne Anmerkungen
• Möglichkeit von diversen Auswertungen

Nach einigen Tagen des Suchens und Ausprobierens stellte ich ernüchtert fest, dass alle Lösungen, die ich gefunden hatte

- zu komplex und/oder
- zu teuer und/oder
- zu unflexibel und nur schwierig oder gar nicht anpassbar und/oder
- zu unhandlich

waren. Da ich aber schnell eine Lösung benötigte und nicht länger weitersuchen wollte, bot sich als einzige Alternative: seber machen!

Ein Framework muss her!

Wenn man “mal eben schnell” eine kleine Applikation schreiben will, greift der PHP-Entwickler ja gemeinhin zum “Framework”. Da ich mich bis zu diesem Zeitpunkt noch nie so richtig intensiv mit dem ZEND-Framework (ZF) beschäftigt hatte, witterte ich die Chance, hier gleich 2 Fliegen mit einer Klappe zu erschlagen und dachte mir: Prima – nutze ich diesen Anlass, um mich da mal einzuarbeiten.

Nach rund zwei Tagen Kampf mit dem ZF musste ich allerdings feststellen: Wir zwei werden keine Freunde.
Vielleicht fehlte mir einfach die Zeit und die Ruhe, vielleicht auch die richtige Anleitung … – vielleicht bin ich auch einfach irgendwie inkompatibel mit dem ZF – jedenfalls erschien mir das alles extrem umständlich und langwierig. Und ich wollte ja schnell zum Ziel kommen.
Um ehrlich zu sein: ich habe in diesen 2 Tagen das ZF hassen gelernt. Das spricht nun nicht zwangsläufig gegen das ZF – vielleicht spricht es eher gegen mich. Jedenfalls scheint mir das ZF nichts für Ungeduldige zu sein, die gerne schnell ein Ergebnis sehen möchten.

Nachdem ich das Thema “Zend Framework” für mich zunächst abgehakt hatte, blieb nur noch der Weg, etwas komplett Eigenes zu versuchen. Ich hatte schon früher einmal ein eigenes kleines PHP-Framework erstellt, warum nicht das nutzen, ein bißchen Refactoring betreiben und es weiter ausbauen?
Als ich dann damit begann stellte ich irgendwann plötzlich fest: Das sieht verdammt noch mal sehr nach OXID aus …

Und genau da machte es “Klick” und ich fragte mich: Warum also nicht gleich OXID nehmen?!
Der OXID eShop bringt ja schon vieles mit, was ich mir für meine Projekterfassung wünschte:

• User-Login
• Session-Verwaltung
• Rechte-System (Admin / normaler User)
• und vieles mehr …

Ganz entscheidend war natürlich die Tatsache: Mit OXID kenne ich mich aus – damit kennen sich unsere Entwickler aus! Ein Ausbau und die Anpassung einer Anwendung auf OXID-Basis sollte für uns also ein Kinderspiel sein.

OXID statt Zend Framework??

Moooment! Kann das denn angehen? Eine Anwendung, die gar nichts mit einem Shop zu tun hat, soll auf Basis einer Shop-Software programmiert werden? Schließlich wird ja seit einiger Zeit werbewirksam (und konkurrenzorientiert) diskutiert, ob man den OXID eShop nicht stärker an das Zend Framework anbinden solle. Und nun kommt der Ziethen daher und will eine Anwendung statt auf dem ZF auf dem OXID Framework aufsetzen? – Heißt das nicht den Bock zum Gärtner machen?

Wie schon oben angedeutet: Das Ganze hier soll ein Anstoss sein – zum Nachdenken, zum Ausprobieren und zur eigenen Kreativität. Ich behaupte nicht, dass man nun sinnvollerweise alle möglichen Anwendungen auf OXID aufbauen könnte – aber ich möchte aufzeigen, was dieses Framework alles kann und von Haus aus mitbringt:

• MVC Architektur
• vollständige Objektorientierung
• gute Kapselung und Atomisierung der einzelnen Funktionen
• Exception-Handling
• Modul-Schnittstelle
• Komponenten-Modell
• Template-Engine
• Datenbankabstratktionslayer
• Benutzerverwaltung
• Session-Handling
• Config-Objekt
• Mehrsprachitkeit
• zahlreiche Utilities
• uvm.

Wenn man genau hinschaut, dann kann man im OXID-Framework einen sehr vielfältigen Werkzeugkasten sehen, der einem eine solide Basis für eigene Anwendungen bietet. Und wie das konkret aussehen kann, das werde ich im zweiten Teil dieses Beitrages an dem schon erwähnten Beispiel einer Projekterfassungssoftware demonstrieren.
Ich werde versuchen, den zweiten Teil noch an diesem Wochenende fertigzustellen.

Der GREYHOUND tritt an, um z. B. Outlook und andere Groupware-Produkte nicht nur abzulösen sondern weit hinter sich zu lassen. Papierloses Büro, Mail-Client mit umfassenden Teamfunktionen, Textverabeitung, Faxprogramm, Dokumentenmanagement, Terminplanung, Aufgabenverwaltung, Softphone, Notzisammlung und und und …. Es ist unmöglich, die Funktionsvielfalt dieses Meisterstücks auch nur ansatzweise in einem einzigen Blogbeitrag vorzustellen. Ich kann aber jedem, der nach einer effizienten Teamsoftware sucht, nur empfehlen, sich den GREYHOUND mal eine Weile genauer anzuschauen.

Wir nutzen wie gesagt seit Oktober letzten Jahres die Betaversion und haben uns inzwischen so an den Hund gewöhnt, dass wir dieses treue Haustier nicht mehr missen möchten. Ich will mal mit ein paar Beispielen versuchen, zumindest den Hauch einer Ahnung zu vermitteln, was der Hund so zu bieten hat:

Universale Elemente
Der GREYHOUND kümmert sich um Emails, Briefe, Faxe, Notizen, Aufgaben, Termine, Telefonanrufe, Telefonnotizen, Dokumente und Kontakte. Das ist eine ganze Menge. Aber das Besondere daran: hinter den Kulissen ist jeder Eintrag – egal ob Brief, ob Fax, ob Email, Aufgabe, Termin oder sontwas – einfach nur ein “Element”. Und alle diese Elemente sind vom Prinzip her gleich. Sie haben unterschiedliche Eigenschaften, aber das Grundmuster ist immer dasselbe. Der Vorteil: Alles kann in alles verwandelt werden. So kann man z. B. eine Email mit einem Mausklick als Aufgabe oder auch Termin duplizieren. Man kann auf eine Email auch per Fax oder Brief antworten. Klingt banal – ist in der Praxis aber genial.

Anmerkungen und Historien
Wenn man in leitender Funktion hin und wieder auch mal mit verärgerten Kunden zu tun hat, ist das Anmerkungsfeature von unschätzbarem Wert – vor allem in Verbindung mit der Historie. Wenn ich selbst keine Ahnung habe, was bei dem betreffenden Projekt zuletzt überhaupt Sache war, dann reicht ein Klick auf die Kundenhistorie und schon habe ich alle Vorgänge, die mit dem betroffenen Kunden zu tun haben, auf dem Schirm. Egal ob Telefonanrufe, Emails, Faxe – alles ist sofort einsehbar. Wenn nun die Mitarbeiter auch fleißig von der Kommentarfunktion Gebrauch gemacht haben, dann lese ich da z. B. zu einer Kundenmail: “Kunde wurde telefonisch darauf hingewiesen, dass die von ihm installierte Forensoftware veraltet ist und ein Sicherheitsrisiko bedeutet. Kunde hielt dieses Risiko für tragbar.”
Wenn mich nun der Kunde anruft, und mir erbost mitteilt, dass sein Server gehackt wurde, dann kann ich entsprechend reagieren und ihm mitteilen, dass das bedauerlich ist, dass er aber früh genug gewarnt wurde.
Bei uns hat mittlerweile jede zweite Mail solche Anmerkungen. Sie machen bestimmte Vorgänge besser nachvollziehbar und ermöglichen es jedem Teammitglied, schnell zu erfassen, was aktuell angesagt ist – auch wenn man selbst mit dem Vorgang bisher nicht befasst war.

Benutzerdefinierte Felder
Jedem Element lassen sich beliebig viele benutzerdefinierte Felder zuweisen. So kann man z. B. dem Element “Email” ein Feld “Aufwand” zuweisen. Support-Mitarbeiter können dann dort unmittelbar eintragen, wie lange die Bearbeitung des Problems gedauert hat. Solche Felder lassen sich problemlos über Regeln auswerten und über Filter als CSV-Datei exportieren. Einem Import in eine Warenwirtschaft, ein ERP-System oder sonstige Systeme steht somit nichts im Wege.

Ich will das mal an einem kleinen Beispiel deutlicher machen:
Wer selbständig und viel unterwegs ist, der kennt das Problem, am Monatsende eine Aufstellung anlegen zu müssen, in der die “Zeiten der Abwesenheit” aufgeführt sind für Buchhaltung und Steuer. Je nach Dauer der Abwesenheit können diverse Erstattungssätze geltend gemacht werden. Da sitzt man dann, durchforstet seinen Kalender und tippert mühsam in eine Excelliste: Datum von – Uhrzeit von – Datum bis – Uhrzeit bis – Ort – Zweck der Reise, ggf. Adresse des Kunden etc. Und man muss vor allem bei jedem Termin ausrechnen, wie viele Stunden man abwesend war.
Ich habe nun im GREYHOUND folgendes gemacht: Meine Termine, die diesbezüglich relevant sind, erhalten eine spezielle Kennzeichnung. Dann habe ich einen Filter angelegt, der mir alle Termine mit dieser Kennzeichnung als Liste anzeigt. Für die Termine habe ich außerdem ein benutzerdefiniertes Feld “Dauer” angelegt. Dann habe ich noch eine Regel definiert, die aus den Feldern “Datum von” und “Datum bis” die Dauer als Float-Wert mit 2 Kommastellen ermittelt (die Uhrzeit ist bei diesen Feldern inbegriffen). Außerdem habe ich einen Export definiert, der sich auf den genannten Filter bezieht und mir die Terminliste mit Datum von, Datum bis, Ort, Zweck, Projektname und Dauer exportiert.
Am Monatsende brauche ich nun nur noch diesen Export auszuführen – und schon habe ich meine gewünschte Liste.

Faxe bearbeiten und beantworten
Ich hatte mir ein Angebot für neue Rechner für’s Büro schicken lassen. Das Angebot kam als Email mit PDF-Anhang. Der Lieferant schrieb dazu: “Wenn Ihnen das Angebot zusagt, faxen Sie es mir bitte unterschrieben und gestempelt zurück.” – Früher hätte das bedeutet:
1. Emailanhang öffnen.
2. PDF ausdrucken.
3. Ausdruck stempeln und unterschreiben.
4. Ausdruck auf’s Fax legen und zurückschicken.

Heute sieht das so aus:
1. PDF öffnen und mittels gotomaxx PDF-Mailer and den GREYHOUND Briefeingang schicken.
2. Dokument im GH-Briefeingang öffnen und als Telefax beantworten.
3. Die Antwort bearbeiten und eingescannten Stempel und Unterschrift einfügen.
4.. Abschicken.

Der zweite beschriebene Weg benötigt einen Bruchteil der Zeit von Weg Nr. 1.

Alle Dokumente überall dabei und durchsuchbar
Seit 2 Wochen habe ich begonnen, alle möglichen Belege, Verträge uns sonstigen Schriftverkehr zu scannen und in den GREYHOUND zu schieben. Das geht super-einfach mittels des miteglieferten “Transporters”. Der Transporter überwacht eines oder mehrere frei definierbare lokale Verzeichnisse und schickt alles, was er darin findet in regelmäßigen Abständen an eine frei wählbare Email-Adresse. Wenn das eine als Briefeingang definierte Adresse im GH ist, so kommen diese Dokumente dort an wie ein Fax. Der Clou dabei: alles wird sofort OCR-texterkannt und ist somit auch Volltext-durchsuchbar.
Der Steuerberater will den Leasingvertrag für den Dienstwagen sehen? Kein Problem: Eine Suche nach “Opel Leasing” bringt in Sekundenbruchteilen den Leasing-Vertrag für den Dienstwagen auf den Schirm. Nun nur noch “weiterleiten als Fax”, die ersten Buchstaben des Namens des Steuerberaters eingetippt (die der GH automatisch vervollständigt) – abschicken – fertig.

Ich will’s für heute mal bei diesen Beispielen belassen. Vielleicht werde ich in der nächsten Zeit immer wieder mal kleine GREYHOUND-Bonbons hier präsentieren. Ich kann nur sagen: es macht nicht nur Spaß mit dieser Software (und mit der dahinterstehenden Firma) zu arbeiten – sondern es steigert auch enorm die Effektivität und bringt Ordnung in die oftmals so chaotische Büro-Kommunikation.
Abschließend sei noch gesagt, dass der GREYHOUND eine serverbasierte Software ist. Der GH-Server kann entweder lokal im Büro laufen und dann via VPN auch von außen zugänglich gemacht werden – oder aber man entscheidet sich für ein externes Hosting. Bezahlt wird monatlich je nach gebuchter Anzahl von gleichzeitigen Nutzern. Es gibt aber auch eine Kaufvariante.
Der Server ist über eine RPC-Schnittstelle von außen ansprechbar. Somit kann jede andere Software (Warenwirtschaft, Auftragssoftware, Projektmanagement, Onlineshop …) mit dem GH kommunizieren. Hier verbergen sich ungeahnte Möglichkeiten, die wir zur Zeit im Blick auf den Bereich Ecommerce ausloten und demnächst auch unseren Kunden zugänglich machen werden.

Ein starkes Stück haben die “digitalen gurus” da abgeliefert!

- Kein Kommentar -

——————————————————————————

Hallo liebe Hörerinnen
Hallo liebe Hörer – von Radio-Confusion,

es ist soweit ! – Am 17. Oktober 2009 findet die lange angekündigte 1. Hörerparty von Radio-Confusion statt.
Der Austragungsort des Treffens ist Dortmund, wo uns dank des Kollegen URBAN passende Räumlichkeiten zur Verfügung stehen.
Die Anbindung und die damit verbundene Erreichbarkeit durch Bahn, Auto oder Bus sind Dank der zentralen Lage von überall her gut zu erreichen.

Alle weiteren Informationen zu dieser Party findet Ihr im Laufe der nächsten Tage auf der Radio-Confusion-Homepage.

Wir freuen uns auf Euch !

Die Arbeitsgruppe Hörerparty

Natürlich wird auch – wie gewohnt – die Musik nicht zu kurz kommen. Und auch Musikwünsche werden wie immer ihren Platz haben.

Wer interaktiv dabei sein will, sollte sich bei Ximig (http://www.ximig.de) registrieren und dort den Chat aufrufen – und das “Land of Confusion” betreten. Dort sind die meisten Hörerinnen und Hörer so wie auch ich selbst während der Sendung anwesend. Ihr könnt dort auch Fragen an Toby stellen und/oder eure Musikwünsche äußern.

Also: klar machen zum ändern … – Radio Confusion einschalten!
Auf unserer Homepage www.radio-confusion.de findet ihr rechts oben die Links zum Abspielen des Streams in den jeweiligen Playern.

Sorry – aber den konnte ich mir nicht verkneifen nach dem Hype, der seit gestern abend durch’s Netz und durch die sonstigen Medien rauscht. Gibt’s echt keine wichtigeren Themen? Zensursula? Iran? Opel? Afghanistan?

Nur weil ein kranker Vollidiot, der den ein oder anderen wirklich guten Song rausgebracht hat – okay – nur weil der seinen Verrücktheiten erliegt müssen gleich alle verrückt spielen?

Irgendwie krank diese Welt …

Die Idee, im PHP-Bereich aus- und weiterbildend tätig zu werden, ergab sich bei mir hauptsächlich aus den Erfahrungen mit Bewerbern in den letzten Jahren. Zwei mal hatte ich Stellen für PHP-Entwickler ausgeschrieben – und zwei mal bekam ich jede Menge Bewerbungen auf den Tisch von Leuten, die zwar gewisse Grundkenntnisse in PHP mitbrachten, deren Kenntnisse aber eben nicht ausreichten, um sie im professionellen Umfeld einzusetzen. Und dann steht man vor der Entscheidung, ob man sich antut, jemanden im laufenden Betrieb auf eben dieses professionelle Level zu hieven – oder ob man einfach weitersucht …

Und wenn der tägliche Projekt-Stress es unmöglich erscheinen lässt, einem neuen Mitarbeiter so viel Einzelbetreuung zukommen zu lassen, dass er (vielleicht) irgendwann mal das Level erreicht, was man sich wünscht – und das man braucht – dann sehnt man sich nach einer Einrichtung, wo man solche Leute mal eben hinschickt und wo sie komprimiert und intensiv das lernen, was ihnen noch fehlt.

Aus dieser Not versuche ich nun eine Tugend zu machen und werde mich zunehmend in diesem Bereich engagieren. Die aktuellen Angebote der anzido Akademie sind erst der Anfang. Ich arbeite an der Konzeption eines regelrechten PHP-Ausbildungsgangs, der dann in Form eines Jahreskurses laufen könnte, bei dem die Teilnehmer(innen) 2 x pro Monat zu Kursen erscheinen, Input bekommen, kleine Zwischenprüfungen absolvieren – und am Ende eine Zertifizierung erlangen, die ihnen bescheinigt, dass sie für den professionellen Einsatz als PHP-Entwickler taugen.

Neben den allgemeinen PHP-Seminaren werden wir hier und da auch immer wieder Angebote zum Thema OXID eShop machen. Jetzt wo diese Software auch als kostenlose Open Source Version zur Verfügung steht, werden sicher mehr und mehr Entwickler und Shopbetreiber ausprobieren wollen, ob dieses Shop-System für ihre Zwecke das richtige ist. Eine konzentrierte und kompetente Einweisung sowohl in die Shop-Administration als auch in das OXID-Framework dürfte so manch einem hier viel Zeit sparen.

Ich bin gespannt, wie unser Angebot angenommen werden wird …..
(http://www.anzido-akademie.de)