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

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)