[AdSense-A]
Einleitung
In Pimcore 4 kommen viele neue Features hinzu, die es bislang bei Pimcore 3 nicht gab. Mit dem neuen Release fragt man sich, ob Pimcore 4 nun wirklich, statt wie bislang beschrieben in der Enterprise-Szene mitspielt. Das Team von Pimcore selbst bezeichnet das freie PIM-System als enterprisefähig.
Technologie
Pimcore 4 basiert nach wie vor auf dem Zend-Framework 1, bringt jedoch Namespacing und andere Features mit, die mehr in Richtung von PHP 7 gehen. Mittlerweile ist es sogar möglich, Klassendefinitionen sowie Class-Rebuilds über die CLI-Tools von Pimcore durchzuführen, diese eignen sich hervorragend für ein automatisiertes Deployment mittels eines Continuous Integration-Servers (Continuous Delivery). Auch ist Pimcore 4 nun auf EXT 4 umgestiegen. Für alle denen EXT 4 keine äußert Große Erkenntnis bringt, dies ist das Frontend Javascript Framework von Pimcore.
Meine Erfahrungen mit Pimcore 4
Als jemand der mit dem Zend-Framework 2 und 3 gearbeitet hat, ist aus meiner Sicht vieles im Pimcore 4 verbesserungswürdig! Enterprise-PIM hin oder her, die technologischen Bedingungen unter welchen verpflichtend gearbeitet werden muss sind größtenteils in-transparent, die Dokumentation zum Pimcore 4 ist wie die zum Zend-Framework 1; nicht ausreichend.
Wichtige Entwurfsmuster fehlen in Pimcore völlig. Nicht alle PHP-Klassen lassen sich von einem Backend-Entwickler erweitern, da in bestimmten Szenarien entsprechende Events fehlen. Pimcore versucht zwar den Ruf eines eventbasierten Frameworks zu wahren, trifft dies allerdings nicht in den heutigen nötigen Normen. Vieles ist in Pimcore 4 nach wie vor in-transparent.
Das Schema bzgl. der Suche von bestehenden Objekten sollte ebenso überdacht werden, denn diese liefert zum Teil false-positive Resultate, welche dann beim Speichern durch das fehlende Management innerhalb von Objekten zur Folge hat, dass Exceptions geworfen werden, während ein Objekt gespeichert wird. Dies hängt damit zusammen, dass Pimcore 4 einen Insert- oder einen Update-Befehl nicht anhand eines geladenen Objektes unterscheiden kann, sondern beim Aufruf der Save-Methode immer davon ausgeht, dass das Objekt neu ist. In diesem Falle wird es nötig eigene Business-Logik zu implementieren, um eine Differenzierung zwischen Update und Insert zu treffen. Dies ist auch zwingend notwendig, wenn man nicht auf Exceptions treffen möchte.
Ebenso hat Pimcore 4 zu viele Abhängigkeiten über Composer. Viele der Abhängigkeiten werden regelmäßig geupdated, es besteht jederzeit die Möglichkeit bei einem Update der Dependencies über Composer auf einen Full-Crash.
Fazit
[AdSense-A]
Pimcore 4 ist meiner Ansicht nach kein Enterprise-Framework, dafür hat es zu viele Abhängigkeiten zu Fremd-Libraries, für Zwecke die längst, vor Jahren, von anderen opensource Frameworks gelöst sind.
Dass, das Pimcore 4 nach wie vor auf das ZF1 setzt ist mir rätselhaft. ZF1 genügt den heutigen Anforderungen, aus meiner Sicht, nicht mehr. Dafür bietet es nicht das Maß an Flexibilität und Dynamik was heutigen Kundenwünschen entspricht.
Es bietet in allem zu wenig Flexibilität und durch die Notwendigkeit eines Erfahrenen JS-Entwicklers sinkt die Bereitschaft an Pimcore zu entwickeln. Denn für Pimcore 4 ist zwingend ein Full-Stack-Entwickler erforderlich, der sich einerseits mit den Geringfügigkeiten, der fehlenden Features von Modernen Frameworks rumschlagen muss, als auch der kompletten Frontend-Basis, die auf einem fast völlig unbekannten Javascript-Framework beruht.
