Archives » Januar 2014



Promises in AngularJS ab Version 1.2

Ich habe gerade eine etwas ältere SAP von uns getestet und mir ist leider schmerzlich aufgefallen, dass manche asynchronen Logiken für AJAX-Requests und Web SQL-Callbacks nicht mehr richtig funktionieren. Ich fand die Art und Weise wie man damals mit Angular asynchrone Logiken in eigentlich synchrone Logiken einfügen konnte richtig bombe, um nicht zu sagen +1.
Im Tutorial für eigene AJAX/REST-Aufrufe wird dieser Eindruck immer noch impliziert. Um es kurz zu machen, anstatt das man irgendwelche Callbacks registriert, weist man einfach das Ergebnis von einem Promise einer Variablen zu und Angular macht den Rest, ohne den eigentlichen Programmierablauf durch einen Callback zu “unterbrechen”.

Ich habe mir die Finger wund gegoogelt und Treffer wie diesen gefunden: http://markdalgleish.com/2013/06/using-promises-in-angularjs-views/. Die meisten Suchtreffer erklären Promises immer noch genau so, wie ich sie angewendet habe. Nach einer Iteration unterschiedlichster Keywords bin ich dann doch zum Glück noch auf einen Eintrag beim stackoverflow gestoßen, der mich auf den Changelog von angular.js hinwies, und folgenden Punkt: Promises müssen seit Angular 1.2 händisch aufgelöst werden. Wir müssen also doch wieder irgendwie Callbacks einbauen.

Also, falls Ihr auch über dies Problem stoplert, vielleicht hilft euch der folgende Gist. Gemäß Angular müssen wir nun wieder ganz normal zu “then()” greifen:

Weitere PostProcessings im Fatchip Artikel Exporter

Ich gehöre in der Regel zu den OXID-Entwicklern, die eigentlich keine verschlüsselten Module einsetzen. Meine Shops sind meistens so stark angepasst, dass ein blindes Integrieren nicht in Frage kommt. Solange der Modulanbieter keinen Mist baut, interessiert mich nicht, wie der Quellcode qualitativ aussieht oder ob ich das Modul auch selbst hätte machen können. Ich möchte aber im Voraus wissen und/oder selbst kontrollieren können, welche Seiteneffekte es mit einem Modul geben könnte, wie das Modul angepasst werden kann und/oder gemergt werden muss. Und auch wenn ich Bugs vermute, möchte ich diese vorher sauber recherchieren, um Fehler bei mir auszuschließen und dass der Modulanbieter direkt ordentlich mit der Behebung starten kann.
Daher habe ich mich besonders gefreut, dass die Fatchip GmbH alle Module seit kurzem quelloffen vertreibt.

Passend zu dieser Source-Meldung hatte ich nämlich auch eine Nachfrage zu diesem Modul, und zwar wie weiteres Feld-Post Processing hinzugefügt werden kann. Dieses Post Processing sorgt dafür, dass bei einem Artikel-Export Feldwerte nachträglich noch geändert werden können. In der Dokumentation sind dafür leider keine Infos zu finden. Ich nutze aktuell die Version 1.12.7 des Moduls und hier gibt es nur zwei Callbacks zum Post-Processing, nämlich für eine URL-Encodierung und eine nachträgliche Umwandlung in UTF-8, sollte der Feldwert noch nicht so codiert sein.

Ich benötige aber noch einen Callback, um Smarty-Tags z.B. in der Langbeschreibung zu evaluieren, denn ein Marketplace kann mit diesen internen Smarty-Tags eigentlich nichts anfangen. Ich hoffe euch mit diesem Posting Hilfestellung für eigene Post Processings geben zu können.
(mehr …)