Archives » Technik



OXID Update für AJAX-Listen

Wer bei OXID in der Vergangenheit versucht hat, die AJAX-Listen des Backends zu überschreiben, wird leider gemerkt haben, dass es doch mit mehr Arbeit als sonst bei OXID üblich verbunden ist.

Mit dem heute erschienen 4.6.2 Patch soll sich das nun erledigt haben.

Wo bisher mit globalen Variablen und Includes “außerhalb” des OXID-Frameworks gearbeitet wurde:

Wird nun ein imho deutlicherer sauberer Include mit oxNew ausgeführt:

Ich möchte sagen, endlich ;).

Auf der Entwickler-Mailingliste – die ich nur jedem empfehlen kann – hatten wir über einen Bug diskutiert, dass die neue Modullogik kein “Modul-Include” für diese Backendfunktionalität erlauben würde.  Wie man aus meinen Kommentaren zu dem Thread entnehmen kann, habe ich das in meiner Modulentwicklung eigentlich immer für gegeben hingenommen, daher war es für mich kein Bug. Aber die Entwickler von OXID haben das als schlechten Stil erkannt und sofort gefixt. Danke dafür!

Jetzt auf Github, Fortsetzung für den WBL Autoloader

Wer Module nicht wie bei OXID normalerweise üblich pflegen möchte:

Sondern lieber auf solch einen Stil steht:

der ist bei meinem Autoloader genau richtig. Ich persönlich finde, die bisherige Modulpflege verlangt leider einige Redundanzen die auf Grund der API-Sicherheit nun seit Jahren beibehalten werden.
Warum macht man das so? OXID bietet updatesichere dynamische Modulketten – oder besser, einen IoC-Container für Module der Core-Klassen – nämlich bereits seit Jahren an. Manch einer hatte dieses Konzept anfänglich nicht für sinnvoll erachtet doch ich finde es toll. Ich versuche euch mit meinem Autoloader eine Möglichkeit zu bieten, den OXID-Styleguide weiter an andere berühmte Styleguides, wie dem des Zend Frameworks mit Magento, anzugleichen und so eure Projekte intern weiter zu harmonisieren.

Da die Updates für OXID 4.6 abgeschlossen sind, ist der Autoloader nun auch ein OXID Projekt-Fork auf Github. Hier könnt Ihr es downloaden, einsehen oder auch mit mir weiterentwickeln.
(mehr …)

Datenbank-Master/Slave Vorbereitung in OXID 4.6.0

Lastverteilung ist bei großen Internetseiten ein sensitives Thema. Bei gut besuchten Shops natürlich sowieso, denn jeder von uns möchte in Geschäften an der Kasse nicht lange anstehen und sofort bedient werden. Aktuell ist für viele Shops eine Hochlastzeit, denn Muttertag steht vor der Tür und Muttertagsgrüße  möchten verschickt und Geschenke verteilt werden.

Bei typischen Webanwendungen gibt es mehrere Möglichkeiten und Schichten der Lastverteilung. Eine Schicht ist auf der Datenbankseite einer Webanwendung zu finden. Und mit OXID 4.6.0 hat sich hier anscheinend einiges getan.
(mehr …)

WBL Autoloader und OXID 4.6.0

Falsche Modulansicht

Falsche Modulansicht

Vor OXID 4.6.0 musste man sich seine Modulketten im Backend selbst zusammenstellen. Nun hilft einem das Backend dabei. Unser Autoloader durchkreuzte da ein bisschen die Pläne seitens OXID. Er funktionierte weiterhin wunderbar, aber die Aussage im Backend waren für den Benutzer nicht einleuchtend.

  • Module werden unter unserem Kürzel in der Liste gruppiert.
  • Warnmeldung im unteren Frame zur Deaktivierung.

Diese “Probleme” haben wir nun behoben:

  1. Wir haben die metadata.php für den WBL_Modules -Ordner angelegt.
  2. Das Modul WBL_Modules_ModuleList sorgt dafür, dass der Autoloader in der Liste als aktiv angezeigt wird und die “Entfernen”-Warnmeldung im unteren Frame nicht mehr erscheint. (Leider auf den ersten Blick n kleineren OXID-Bug gefunden.)
  3. Und die vendormetadata.php im WBL-Ordner sorgt dafür, dass der WBL-Ordner nicht mehr als direkter Modulordner verstanden wird. OXID schachtelt jetzt noch eine Ebene tiefer und versteht den WBL-Ordner nur noch als Hersteller-Ordner. Dies muss für alle “Hersteller”-Ordner gemacht werden, wobei die  vendormetadata.php dabei noch leer sein darf.
  4. Unittests sind auch aktualisiert worden. Unser Modul für die oxModuleList schließt natürlich auch mit 100% Codeabdeckung ab.
Moduldarstellung

Korrekte Moduldarstellung nach 4.6.0 Update

>> Unseren Autoloader downloaden

Datenbankverbindung beim Unittesting reloaded

Ich musste in meinem Posting Datenbankprobleme beim OXID-Unit-Testing ja bereits von kleinen Komplikationen mit meiner Testumgebung berichten. Bei OXID 4.6.0 ist es nach Tagen ohne Probleme hier plötzlich auch aufgetreten. Irgendwo verschluckt sich meine VMWare.

Mein alter oxDB::getDb() – Fix ist bei OXID 4.6.0 tot und führt zu einer Endlosschleife, daher sieht meine Empfehlung für OXID 4.6.0 diesmal so aus:

Beste Grüße
Björn

Facebook Shop Modul

Ich habe es in der Vorstellung angedroht, ab und zu kommt auch ein bißchen Werbung. Ich habe euch das Autoloader 4.6.0 Posting versprochen. Ja, der Autoloader wird gerade mit “oxModule” verknüpft und zwar im 4.6.0 Update unseres Facebook-Shop-Moduls, daher braucht das Posting noch ein bißchen.

Unser WBL Facebook Shop Modul ermöglicht euch die Implementierung eures Shops im Facebook-Kontext ohne weitere Schnittstelle. Das gleiche Backend, der gleiche Artikelbestand, die gleichen User-Daten und mit OXID 4.6.0 funktioniert hoffentlich der Facebook Connect auch wieder besser.

Unser OXID Autoloader

Jeder von uns Programmierern ist eigentlich bestrebt, wenig zu wiederholen und viel wiederzuverwenden. Wir überlegen uns meistens möglichst schöne Klassenstrukturen in denen wir unsere Logiken so kapseln, dass wir sie hoffentlich wiederverwenden können. In letzter Zeit springe ich zwischen einigen OXID Todos und stehe gefühlt jedes Mal vor dem Schritt bestehende Strukturen zu kombinieren oder Strukturen auf der grünen Wiese neu zu pflanzen. Und jedes Mal ist der OXID-Autoloader auch wieder ein Thema.

(mehr …)

Datenbankprobleme beim OXID-Unit-Testing

Mensch, eine Stunde verbraucht mit der Fehlersuche.

Ich stolpere grad über Datenbank-Probleme beim Unit-Testing einer aktuellen OXID-Version und bin auch mit einer ausgiebigen Google-Recherche und dem Wühlen in der OXID-Mailingliste nicht fündig geworden. Da die Testumgebung von OXID zur Modulzertifizierung leicht veraltet ist, teste ich meine Module gegen ein halbwegs aktuelles Debian 6 mit PHP 5.3 auf dem neuesten VMWare Player und irgendwann, wirklich irgendwann im Testlauf, ist plötzlich in der Connection-ID des Datenbankobjekts keine Resource mehr zu finden, sondern nur noch ein Integer-Wert. (mehr …)