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.

As I know a new community platform with several docs and a new forum is planed as well. Unfortunately today there’s only a sort of prototype of this new platform online …

This new open source edition now makes it possible for everyone to use, change and extend the software which is released unter GPL V3.

I think this was a brave decision and I am very curious about the consequences during the next months. Probably we should see some rapid development of all sorts of extensions and modifications. Exciting times for OXID …

It’s known quite some time and e. g. told here – or here, that OXID eSales AG has spent nearly two years of refactoring the code of their software. Together with that some new structures and workflows have been introduced for improved quality management.

The result of all that – in my opinion – is a great step forward (and as the bush drums tell, there might come up some even bigger steps soon …). The whole code has been extremely cleaned up, monster classes and methods have been cut down to small and handy pieces – obviously a result of the consequent use of unit testing.

There are some new features – which I did not sort out totally yet. Just to mention some:

• use of session cookies instead of session ids in urls
• very nice SEO URL concept
• free mapable SEO URLs (e. g. for content pages and so on)
• SEO optimized templates
• XHTML-valid templates (finally …)
• div-based layout without needless tables
• some web 2.0 stuff (tag clouds, social bookmarking …)
• redesign of admin interface
• …

But from a developers point of view the new features are not that important in this new version. The most important thing is the redesigned source code. Already a first look at the class tree shows you which enormous work has been done here.
Much of the functionality has been put into core classes now, there’s a strict concept of getters and setters now, corresponding to well structured public and protected properties and methods, even some interfaces have been implemented. As far as I could see you finally have consequent namings of classes, functions and variables now. Some very helpful static classes and methods do make live easier and … and … and …

Developers who worked with the OXID versions before will need some time to get used to the new source structure – but this time will be spent very well and I think at the end of the day they will love to work with the new version. And as you once understand the logic behind all the changes, your work will become much easier.

After the official release (and if I can take some time for that) I will explain some details of the source code here.
For this moment I am very much looking forward to the first release and from what I saw so far this will be much more stable then the last bigger release. In our company we have already started some new projects using the actual beta release cause I did not find any critical bugs so far.

More to come after the official release …

if(!isset($aParams['nameOfCheckboxField']))
    $aParams['nameOfCheckboxField'] = 0;

Writing a module for such simple stuff is a bit overhead. So what you can do instead in the according template is:

<input type="hidden" name="nameOfCheckboxField" value="0">
<input type="checkbox" name="nameOfCheckboxField" value="1">

Off course this might not be totally valid code. But in the backend I would not care about validation as much as about functionality.

Let’s say you want to add a field MY_FIELD to the oxarticles table and want to put a new form field into the main article menue to edit the content of the new table field.

First of course add the field to the database using phpMyAdmin or whatever tool you use for your db-administration. Now look for the template which has to be extended for adding the form field. If you don’t know how to find the right template, do the following:

Open the admin interface, open menue Administer Products -> Products and klick on an article of the list at the top of the page. Now, if you move your mouse over the tabs (Main, Extended, Inventory etc.) have a look at the status bar at the bottom of your browser. There you will see something like this: javascript:ChangeEditBar( ‘article_main’, 0); – which shows you the name of the PHP-class – and file – which is called by clicking on that tab. The templates are named the same. So if you see ‘article_main’ you cann be sure that a.) the used class is called article_main.php and the according template is called article_main.tpl (I assume that the locations of admin view classes and templates is known).

Well, so open the template article_main.tpl with an editor. If your new field is a text-field, look for a similar field in the already existend code. For example you could take the searchkeys-field:

<tr>
<td class="edittext">
[{ oxmultilang ident="ARTICLE_MAIN__OXARTICLES__OXSEARCHKEYS_RR" }]&nbsp;
</td>
<td class="edittext">
<input type="text" class="editinput" size="32" 
  maxlength="[{$edit->oxarticles__oxsearchkeys->fldmax_length}]" 
  name="editval[oxarticles__oxsearchkeys]" 
  value="[{$edit->oxarticles__oxsearchkeys->value}]">
</td>
</tr>

So now just copy that table-row an paste it to the end of the table before the section with the submit button. Afterwards changed the used variables to the names of your table field:

<tr>
<td class="edittext">
Title of my field
</td>
<td class="edittext">
<input type="text" class="editinput" size="32" 
  maxlength="[{$edit->oxarticles__my_field->fldmax_length}]" 
  name="editval[oxarticles__my_field]" 
  value="[{$edit->oxarticles__my_field->value}]">
</td>
</tr>

I hope that might be helpful for some people.