RSS-Feed
Beiträge
Kommentare

Eigentlich hätte ich gestern im Rahmen der OXID Commons einen Workshop halten sollen. Ich hatte mich schon sehr darauf gefreut, aber bereits am Dienstagabend zeichnete sich ab, dass irgendein grippaler Infekt drauf und dran war, die Oberhand über meinen Körper zu gewinnen. Also sah ich mich gezwungen, meine Teilnahme an den Commons schweren Herzens abzusagen.

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

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.