Blog: Latest Entries (15):


Creditfair Vereinsprogramm

Das Creditfair Vereinsprogramm ist released worden. Es basiert auf einem Shopware 5.3 Shop, das mit verschiedenen eigenen und dafür geschriebenen Plugins erweitert wurde.

bbcode-image


Auf der Seite kann ein Sportverein sich registrieren und für jede Angebotsanfrage eines Mitglieds, die zu einem Vertrag führt, wird dem Verein eine entsprechende Menge an Punkten gut geschrieben, die der Verein dann in Prämien eintauschen kann.

Es gibt also zwei verschiedene Kunden-Arten. Die normalen Mitglieder der Vereine, die sich Informationen über die Leistungen von Creditfair auf der Seite einholen können und dann über ein Anfrage-Formular ein Angebot anfordern können.
Dann gibt es noch die Vereine, die die eigentliche Shop-Funktionen nutzen und ihr Bonuspunkte-Konto dort pflegen können.
Vereine können sich nicht direkt registrieren sondern werden von einem Administrator dort angelegt und freigeschaltet. Es ist hier also eher eine B2B Lösung in einem sehr kontrollierten Rahmen.

Um diese Funktionen abbilden zu können, kommen 3 Plugins zum Einsatz:

1. Das Bonuspunkte-Plugin
Hier erhält jeder Verein ein Budget von Bonuspunkten, die ihm auch im Account angezeigt werden. Das Eintragen der Punkte geschieht im Backend. Dawird nicht nur ein einzelner Punkte-Wert gepflegt, sondern es gibt einzelne Einzahlungen. Das sit wichtig, weil die Punkte eine Sperrzeit haben können. Wenn nun ein Vereinsmitglied einen Vertrag abschließt erhält der Verein direkt seine Punkte. Das Vereinsmitglied hat aber natürlich noch eine Zeitspanne in dem es vom Vertrag zurück treten kann. Erst wenn diese Zeit abgelaufen ist, können die Punkte auch verwendet werden.
Im Checkout wird eine Bestellung verhindert, wenn sie das Budget übersteigt und die ausgegebenen Punkte werden nach der erfolgreichen Bestellung verrechnet und abgezogen.
Punkte verfallen nach einem gewissen Zeitraum auch wieder, wenn man möchte.

bbcode-image


Dieses Plugin wurde allein für diese Seite geschrieben und deckt eine sehr spezielle Anforderung ab, die mit den vorhandenen Lösungen so nicht erreicht werden konnte.

2. Kunden/Vereins-Liste
Da man gerne damit werben wollte, welche Vereine schon an dem Programm teilnehmen, sollte eine Liste der Vereine mit Logo, Beschreibung und Suche ermöglicht werden. Hier kann jeder Kunde/Verein sein Profil selbst verwalten. Unter jedem Eintrag kann es einen Promotion-Link geben, der auf eine andere Seite verlinkt und den Vereinsnamen mitgibt (z.B. zum automatischen befüllen eines Formulars.. was momentan noch eher schlecht als recht funktioniert).

bbcode-image


Dieses Plugin dient also rein zur Eigenwerbung und der Präsentation der Kunden. Das sich die Kunden selbst noch mal präsentieren können, ist dabei eher nettes Beiwerk.

bbcode-image


3. Registrierungsanfrage mit eigenen Formular
Vereine sollen sich über ein Formular melden, damit ein Admin sie anlegen können. Dabei soll das normale Formular für die Registrierung durch ein eigenes ersetzt werden.

bbcode-image


bbcode-image


Hier kommt mein eigenes Plugin zum Einsatz, das unter anderen die Funktion bietet ein beliebiges Formular dort anzeigen zu können. Es sind keine speziellen Formulare, so dass diese ganz normal wie immer im Backend angelegt und bearbeitet werden können.

bbcode-image


Neben den Plugins waren die Einkaufswelten der zweite große Punkt bei der Realisierung. Man klickt diese nicht in paar Minuten zusammen. Auch sollte man davon ausgehen, dass man HTML + CSS schreiben muss. TinyMCE ist nett, kommt aber auch sehr schnell an seine Grenzen. Ein Duo aus Designer und Entwickler/Programmierer ist hier nötig, wenn nicht direkt beides in einer Person hat. Man kämpft viel mit dem Layout. Bilder suchen und finden kann auch ein größerer Unterfangen werden.
Mit 5.3 kann man Einkaufswelten exportieren. Damit gibt es Staging und man kann sich selbst Sicherheitskopien ziehen und Änderungen versionieren. Ohne ist es echt nervig, da man nicht einfach Undos für größere Bereiche hat.

bbcode-image


Und für Mobile-Ansichten muss man nochmal Hand anlegen. Das Grid ist gut, aber funktioniert eben auch anders als das von z.B. Bootstrap das sich besser anpasst. Auch die Skalierung der Bilder muss beachtet werden. Sie verhalten sie wie "cover" bei "background-size" in CSS. Also sind Bilder gut, die viel freie Fläche am Rand hab, die abgeschnitten werden kann und das Bild Trotzdem noch gut aussieht. Fotos funktionieren hier sehr viel besser als
Info-Grafiken.

Das Projekt wurde "nebenbei Abends" innerhalb von 3 Monaten Umgesetzt, was wohl 2 Wochen normaler Arbeitszeit entsprechen würden und war mein erstes echtes Shopware-Projekt. Es gab viel zu lernen aber auch viele positive Erkenntnisse wie einfach es ist mit Shopware zu arbeiten und zu entwickeln.

Oracle und Java EE

Wie man überall lesen kann will Oracle nun auch JEE gerne abgeben. Aber sie sichern zu weiterhin an Java festzuhalten.

In den meistens News klingt es so als wäre das ein Widerspruch in sich. Ich kann Oracle aber vollkommen verstehen. Der Java-Core ist so oder so OpenSource und JEE ist optional und kann durch andere Lösungen wie Spring ersetzt werden. Wie Standards wie JMS, EJB3 und so sind wirklich toll und funktionieren super. Sie werden auch viel genutzt, also kann man die auch nicht wirklich sterben lassen, gerade wenn man selbst damit viele Anwendungen gebaut hat.
Oracle auch wirklich viel mit Java gemacht und auch sehr gute Anwendungen damit entwickelt. Nur warum sollte man dafür im Besitz eine Standards sein? Als das alles noch bei Sun lag lief auch alles super und (jetzt folgt der wichtige Punkt) man musste sich nicht mit dem ganzen Drumherum rumärgern.
Als PHP Entwickler hat man ja auch nicht gleich Lust sich den PHP-Standard noch mit auf zu halsen.

Bei der Eclipse Foundation wäre JEE gut aufgehoben und Oracle kann weiterhin mit Java entwickeln und sich sogar einbringen ohne gleich für alles verantwortlich gemacht zu werden.

Ich bin jeden Fall gespannt wie es weiter geht und sehe da mehr Zuspruch in die Zukunft Javas von Oracles Seite als mögliches Abwenden von JEE oder gar Java an sich.

PS: Ich sehe es ähnlich wie dieser Artikel auf Heise-Developer

Shopware Kunden Registrierungsanfrage

Manchmal will man nicht, dass sich Kunden direkt registrieren können. Sie sollen dann ein Formular ausfüllen und werden dann vom Administrator des Shops anlegt.
Dafür muss natürlich deaktiviert sein, dass Gäste bestellen können, damit man es nicht einfach umgehen kann.

Ich werde mein Plugin dafür wohl versuchen in den Community-Store von Shopware zu bekommen, da es wirklich mal ein Plugin mit allgemeinen Nutzen ist und nicht nur für einen Kunden einen ganz bestimmten Fall abdeckt.

bbcode-image

Shopware... Standards und Plugins

Ich habe mich jetzt die letzten 2-3 Monate doch relativ ausführlich mit Shopware beschäftigt. Das erste Projekt das live ging war das Creditfair Fair-Vereinsprogramm. Dafür mussten 2 Plugins geschrieben und einige Theme-Anpassungen vorgenommen werden.

Die Plugin-API mit den Events ist wirklich einfach zu erlernen. Einzig die Suche nach dem passenden Event kann immer etwas länger dauern, wobei am Ende weniger die Frage ist, ob es das richtige Event ist, sondern ob es das beste Event ist. Events für jeden Fall gibt es mehr als genug, wobei die Unterschiede wirklich oft in Feinheiten zu suchen sind.

Nebenbei habe ich als Test ein kleines Plugin geschrieben, das das Kunden-Objekt (wenn denn ein Kunde eingeloggt) ist auch beim Versenden von Forms im Template verfügbar macht. Forms verwenden eine eigene kleine und sehr einfache Template Engine. Für die Erweiterung um den Kunden kommt aber dann Smarty3 zum Einsatz. Damit kann man bei Anfragen über Forms, die nur angemeldeten Kunden zur Verfügung stehen, die Kundendaten direkt zur Email hinzufügen, ohne dass der Kunde es selber tun muss.

Hier kann man es Downloaden

Insgesamt macht es viel Spass mit Shopware zu entwickeln.. nur.. nur eine Sache gibt.. die bereitet mir noch Kopfzerbrechen.

STAGING


Mit der 5.3 kann man wenigstens Einkaufwelten exportieren und wieder importieren. Das ist schon mal wirklich eine große Hilfe, da so Designer auf dem lokalen System arbeiten und testen können und man erst dann nach der Freigabe die Einkaufwelten auf das produktive System verschieben kann.

bbcode-image


bbcode-image


Themes kann auch relativ einfach kopieren. Plugins aus dem Community-Store sollte man so oder so nicht durch ein Staging laufen lassen, sondern auf dem produktiven Server neu installieren und konfigurieren.

Content-Seiten sind der Punkt, wo ich noch am Überlegen bin wie man damit umgehen soll. Hier fehlt eine vergleichbare Import/Export Funktion wie bei den Einkaufwelten.


Ein anderes Thema betrifft Shopware aber auch fast alle anderen Shop-Systeme. Das Problem beginnt damit Produkte, Hersteller, etc in das Shop-System zu bekommen. Denn wenn man keinen winzigen Shop mit 10-50 Artikeln hat, wird man sicher die Produkte aus einem Waren-Wirtschafts-System beziehen wollen. Die REST-API von Shopware ist toll und man kommt schnell zu Ergebnissen. Der CSV-Import ist auch nicht schlecht. Aber das Problem ist, dass man dann immer eine Lösung für Shopware baut. Bei anderen Shops eben für das jeweilige System.
Es gibt wohl kaum Shop-Systeme (oder ich konnte sie nicht finden), die Standard-Formate als Core-Feature lesen oder schreiben können.

Bei der Arbeit dürfte ich nun mit CSV, XML und IDocs aus SAP kämpfen. IDocs sind für den Datenaustausch wirklich nicht toll. Jedenfalls nicht, wenn man die SAP-Welt verlässt. In dem Artikel Warum Sie beim Datenaustausch im E-Commerce auf Standardformate setzen sollten von Daniel Peters trifft es sehr gut gut. Ich stimme da zu 100% zu und er trifft wirklich den Punkt, den ich schon seit Jahren nicht verstehe. Wenn ich ein neues System entwickle, dass mit anderen Systemen kommunizieren und Daten austauschen muss. Warum baue ich mir dann immer wieder ein eigenes Format und nehme mir nicht von Anfang an ein Standard-Format. Damit habe ich auch schon mal eine Art Blaupause, wie man mit dieser Art von Daten umgehen kann und sollte mal ein System ausgewechselt werden, muss ich hoffentlich nicht wieder ein neues proprietäres Format in eine Schnittstelle für mein System umwandeln.

Ich hatte mir ein kleines Plugin geschrieben, dass Bestellungen direkt nach dem Speichern als JSON auf dem Server abgelegt hat. Es war zuerst zur Kontrolle und zum Debuggen auf dem Live-Server da. Es hat nicht lange gedauert und ich hatte auch einen XML-Export und 2 Stunden später auch einen rudimentären [url=]OpenTrans[/url] 1.0 export. Auch wenn der Standard sicher noch nicht zu 100% korrekt umgesetzt ist, habe ich doch schon mal ein Export-Format für Bestellungen, das alles enthält was man braucht, strukturiert ist und auch einfach wieder gelesen werden kann.
Ich werde auf jeden Fall an dem Plugin noch mal weiter rumbauen und vielleicht nochmal OpenTrans 2.1 implementieren.

Ich glaube auch das man einfacher eine OpenTrans zu IDoc Lösung findet, ohne selbst was machen zu müssen, als eine Shopware-internes-Format zu IDoc.

Auch der Import der Produkte... warum kann ich nicht einfach OCI oder BMEcat verwenden, um meinen Shop mit Daten zu befüllen. WWS und andere ERP-Systeme können ja diese Format ausgeben. Die Formate, gerade OCI, sind ja auch sehr verbreitet. Warum kann der Shop diese also nicht nativ lesen und benötigt Zusatzsoftware oder Plugins?

Auf der Roadmap von Shopware-Enterprise steht bei B2B jetzt OCI in der "Unsere Visionen für die Zukunft". Richtiges Punchout muss ja nicht mal sein.
Aber die OCI-XML Daten importieren zu können wäre schon einfach toll und würde an vielen Stellen sehr viel Arbeit und Geld sparen.

bbcode-image


Das wohl gerade an einem Import für Kunden aus Drittsystemen gearbeitet wird kommt wohl für mich auch zu spät, aber ist schon mal eine tolle Sache.


bbcode-image


Momentan überlege ich einen kleines Plugin zu schreiben, dass BMEcat versteht. Nichts all umfassendes mit User-Data-Extensions und so. Ein einfaches kleines, dass nur dafür sorgt, dass Systeme die BMEcat ausgeben können, grundlegend den Shop mit Produkten befüllen können. Wenn ich dann mal wieder Daten aus einem System in Shopware importieren soll, würde ich einfach die Daten auf BMEcat umbiegen können (mit einer Middleware oder XSLT oder so) und müsste an Shopware nichts mehr ändern. Shopware hätte dann eine stabile Schnittstelle, die nicht nur für mich sondern allgemein genutzt werden kann und sogar ein sehr gut dokumentiertes Format nutzt.

Sich der Welt mit Standard-Formaten als Core-Feature zu öffnen, würde vielen Shop sehr gut tun. ... aber wohl auch einen Markt der sich nur auf das verschieben von Daten zwischen Systemen spezialisiert hat, empfindlich treffen können. Für den normalen Entwickler und seinen Shop wäre es aber wirklich ein großer Vorteil.



IP Security Cam

Jetzt mit dem Haus reicht es nicht mehr nur die Wohnungstür zu zuschliessen. Da viele Einbrüche über Garten und Terrassentür geschehen soll der Garten überwacht werden. Die Tür ist sicher und ein motorisierter Rollladen sichert nochmals ab. Also geht es mehr darum mögliche Einbruchsversuche zu dokumentieren.

Es ist ein ieGeek 720p IPCam für außen und mit LAN + WLAN. SD-Karte ist wohl auch möglich, ich will aber lieber FTP verwenden.

bbcode-image

bbcode-image

bbcode-image

bbcode-image

bbcode-image

bbcode-image


NAS mit FTP-Server kommt dann als nächstes und dann wird die Kamera installiert und kann benutzt werden. Die Bildqualität (720p) gefällt mir aber schon sehr gut.

Kotlin und Java: == oder equals()?

Nachdem ich mich jetzt einige Tage lang mit Kotlin beschäftigt habe, bin ich noch etwas zwiegespalten, ob Kotlin mit seinen Ansätzen, es wirklich besser oder einfach nur anders macht.
Einiges was da an Java kritisiert werde, halte ich in Java sogar für besser gelöst, wobei ich aber durch aus die Kritik verstehe. Zum Beispiel haben== und equals() schon genug Leute/Einsteiger verwirrt.

bbcode-image


Kotlin macht es anders. == und === sind wirklich logisch und nachvollziehbar. Es folgt der Umsetzung in PHP oder JavaScript. == vergleicht den Wert und === vergleicht die Referenz.
Aber ist == als Ersatz für equals() wirklich besser?


Date d = new Date();
MyDateImpl md = new MyDateImpl();

if(d.equals(md)){
System.out.println("equals 1");
}

if(md.equals(d)){
System.out.println("equals 2");
}


Es ist durchaus möglich das eine Klasse von mir sich mit sich mit einer standard
Java-Klasse vergleichen lässt, aber die standard Java-Klasse nicht mit meiner, da deren Existenz der standard Java-Klasse natürlich vollkommen unbekannt ist.


val d = Date()
val md = MyDate()

if(d == md){
println("== 1")
}

if(md == d){
println("== 1")
}


Ist das jetzt beides das selbe? Konnte ich auf die Schnelle nicht heraus finden.. werde ich wohl mal testen müssen.

Kotlin und Java: Exceptions und throws

Ist es falsch das Java einen zwingt eine Exception zu fangen, wenn explizit eine geworfen werden kann.
Also das Fehler dort behandelt werden, wo sie auftreten und man sie nicht immer bis ganz nach oben reichen sollte?


public class ThrowExample {

private void method1() throws Exception {
throw new Exception("test");
}

private void method2() throws Exception {
this.method1();
}

private void method3() throws Exception {
this.method2();
}

public void call() throws Exception {
this.method3();
}
}


Bei Java kann es so nie passieren, dass am Ende eine Exception auftaucht, von der man nie wusste, dass sie geworfen wurde. Weil sie entweder schon mit einem Try-Catch-Block gefangen wurde oder aber man über die Existenz dieses Exception mit Hilfe des "throws" an der Methode direkt informiert wird.

PHP hat mit Exception ab PHP 7.0 viel verbessert, aber um die Wahrheit zu sagen, ist das was ich noch gerne hätte ein "throws" damit ich weiß, dass in der Methode, die ich gerade verwende, das Werfen einer Exception implementiert wurde.

Fehler Behandlung ist schwer und Exceptions als brauchbare Fehlermeldungen an den Benutzer hoch zu reichen ist nicht einfach... aber einfach dann die Exceptions bis zum Benutzer durch laufen zu lassen ist doch eher der falsche Weg und ein gutes Exception-Handling Framework wäre die bessere Lösung gewesen.

Deswegen sehen ist den Verzicht auf den Zwang Exceptions fangen zu müssen in Kotlin eher negativ und nicht als Vorteil.Nur als einen Punkt nun dem Entwickler aufgehalst wird (er muss sich nun darum kümmern, dass Exceptions richtig behandelt werden), wo vorher der Compiler einen dabei unterstützt hat auch alle Exceptions richtig zu behandeln.

Mein-Online-Adventskalender und Shopware

Ich hatte bei der Entwicklung von mein-online-adventskalender.de schon sehr darauf geachtet, dass es sich leicht integrieren lässt. Aber bei meinem Test mit Shopware hat sich gezeigt, dass es auch wirklich gut klappt.

Ich hab es über ein Iframe-Element in einer Einkaufswelt eingebunden. Das Element sollte eine Höhe von 1350 haben auf dem Desktop.

bbcode-image


Vielleicht baue ich im Herbst ja noch mal ein richtiges Plugin dafür :-)




Shopware Plugins mit Eclipse PDT entwickeln

Momentan steht bei mir an ein Plugin für Shopware zu entwickeln.

Das erste Problem dabei ist nicht mal, wie das funktioniert, weil das ist im Internet mehrfach gut erklärt, sondern wie man seine Entwicklungsumgebung aufsetzt.
Shopware ist schnell installiert. Aber man will für ein Plugin ja nicht immer das gesamte Shopware mit im Projekt haben. Also wird nur das Verzeichnis aus custom/plugins/ als Projekt-Verzeichnis gewählt.
Bei Eclipse kann man Projektverzeichnisse außerhalb des Workspaces anlegen.

Nun hat man das Problem, dass einem die ganzen Klassen von Shopware fehlen und man so viele Warnings und keine Autovervollständigung hätte.

Über Properties > PHP > Source Paths > Build Path kann man externe Source-Verzeichnisse verlinken.

bbcode-image


ich habe das engine-Verzeichnis von Shopware gewählt und noch zusätzlich dessen vendor-Verzeichnis.

bbcode-image


Die PHPUnit Tests werfen dann zwar noch Fehler. Aber die Plugin-Klasse von Shopware wird schon einmal gefunden und damit ist der erste Schritt schon getan.

bbcode-image


Damit kann meine Arbeit an meinem ersten Shopware-Plugin jetzt anfangen.

Strom für unterwegs

Manchmal hat man das Problem, dass man vor Ort keinen Strom hat. Notebooks lösen das Problem. Doof nur wenn man auch zusätzliche Geräte wie RFID-Reader oder Netzwerk-Switches mit versorgen muss. Ich werde Samstag mal ein Akku-Pack testen. Eigenlicht ist es für mobile Blitzanlagen gedacht, aber mit etwas Glück funktioniert es auch für andere Geräte.

bbcode-image

Older posts: