Posted on

Sinnvolle Namespaces in PHP

Eine übliche Konvention für Namespaces in PHP ist es, mit Vendor\Package zu beginnen, groß geschrieben (CamelCase StudlyCaps) mit “vendor” und “package” analog zum Composer Package Namen.

Es gibt allerdings eine schlechte Angewohnheit, die ich häufig sehe, vermutlich aus alten ZF1 und Pear Tagen, wo jedes Wort im Klassennamen ein neuer Sub-Namespace ist (und ein neues Unterverzeichnis), oder Kind-Klassen in einen Namespace mit dem Namen der Elternklasse platziert werden. All das führt zu tief geschachtelten Namespaces und Klassennamen, die keine Bedeutung ohne ihren Namespace haben.

Beispiele aus Zend Framework 1 (Pseudo Namespaces):

  • Zend_Db_Table_Row_Abstract ist eine abstrakte Basis-Klasse für Zend_Db_Table_Row, und repräsentiert eine Zeile in einer Datenbanktabelle. Es gibt auch noch Zend_Db_Table und Zend_Db.
  • Zend_Pdf_FileParser_Font_OpenType_TrueType ist ein Parser für True Type Schriftdateien. Die Klasse erbt von Zend_Pdf_FileParser_Font_OpenType, die wiederum von Zend_Pdf_FileParser_Font erbt, die von Zend_Pdf_FileParser erbt.

Und ein aktuelles Beispiel aus Magento 2:

  • Magento\Catalog\Model\Product\Option\Type\File\Validator – Ein Validator für Produkt-Optionen vom Typ “File”

Continue reading “Sinnvolle Namespaces in PHP”

Posted on

Usability für Programmierer – UX ist nicht nur Frontend!

Dieser Tweet Anfang 2015 hat mir die Augen geöffnet. Ich hatte ein wenig über das Design interaktiver Systeme und die Psychologie dahinter gelernt, so dass ich ihn direkt nachempfinden konnte. Er hat mich zu einem Vortrag “Usability für Programmierer” bei der WebCon Aachen inspiriert, der leider nie öffentlich wurde, weil das Event abgesagt wurde. Ich warte noch immer auf eine passende Gelegenheit, ihn zu präsentieren.

Ich finde das Thema allerdings zu interessant, um länger damit hinterm Berg zu halten, also ist hier nun ein Blog Post!

Weiterlesen auf Englisch (Folien auf deutsch am Ende des Beitrags)

Posted on

Meine Checkliste bei der Analyse von Magento Shops

Der erste Schritt vor der Arbeit an einer bestehenden und mir unbekannten Magento Installation, ist bei mir immer eine Shop Analyse, nicht nur um die Anforderungen und Prozesse des Händlers besser zu verstehen, sondern auch und vor allen Dingen, um die Qualität einzuschätzen und mögliche Probleme frühzeitig zu erkennen. Denn leider sind viele Shops ohne Kenntnis von Konventionen und Best Practices “zusammengebastelt”, was dazu führt, dass:

  1. Die Performance leidet
  2. Sicherheitslücken entstehen
  3. Updates unmöglich werden
  4. Der Code nicht wartbar ist

Punkt 1 und 2 können den Händler ganz direkt schmerzhaft treffen, Punkt 3 und 4 führen mit der Zeit dazu, dass Bugs sich anhäufen, neue Änderungen häufig zu neuen Fehlern an anderer Stelle führen, die immer schwerer zu lösen sind.

Das ist dann häufig der Punkt, an dem eine neue Agentur oder ein neuer Entwickler gesucht wird, also ist es kein Zufall, dass Shops meist in solch degeneriertem Zustand auf meinem Tisch landen. Umso wichtiger ist die Analyse als erster Schritt, noch vor einem Angebot für Weiterentwicklungen, um nicht blind in die selbe Falle zu laufen wie die Vorgänger, und von Vorneherein für Klarheit auf beiden Seiten zu sorgen.

Continue reading “Meine Checkliste bei der Analyse von Magento Shops”

Posted on

Magento Theme Refactoring

Ein sehr häufiges Problem in 2014 war „Ich habe auf Magento 1.8 aktualisiert und jetzt funktioniert das (Login|Warenkorb)-Formular nicht mehr“. Der Grund war, dass seit Magento 1.8 der form key in mehr Formularen genutzt wird, als Security Feature (verhindert CSRF-Angriffe). Aber in jedem Theme, das eine eigene Version der jeweiligen Templates enthielt, fehlte der Form Key, so dass die serverseitige Validierung fehlschlug, leider ohne jede Fehlermeldung.

Natürlich gibt es Themes, deren Markup so verschieden vom Default Theme ist, dass die meisten Templates aus gutem Grund überschrieben wurden. Aber ich sehe mindestens genauso viele Themes, insbesondere Eigenentwicklungen, bei denen erst einmal alle Templates aus base/default kopiert und dann angepasst wurden. Für das Überschreiben von Layout-XML-Dateien gibt es fast keine Entschuldigung, das Layout kann man in allen erdenklichen Möglichkeiten mit einer Theme-spezifischen local.xml Datei anpassen.

Das obengenannte Problem ist ein gutes Beispiel für die Gründe des „Achte auf Updatefähigkeit“ Mantras. Die Fehler hätten vermieden werden können, wenn nur Dateien kopiert worden wären, die wirklich Anpassung benötigten.

In diesem Artikel möchte ich meinen Prozess zum Theme Refactoring darlegen (nur den strukturellen Teil, der HTML-Quelltext wird anschließend exakt gleich aussehen wie vorher, abgesehen von Änderungen durch neuere Versionen der Default-Templates).

Weiterlesen auf integer-net.de →