RSS

Category Archives: Architektur

myWebGate Building Process – Dojo und Templates

Das Benutzerverzeichnis ist ein Kernteil des myWebGate Framworks. Um dem Benutzer ein besonderes Erlebnis bei der Bedienung zu bieten, ist das Benutzerverzeichnis als “OnePage” Applikation designet. D.h. wir präsentieren alle Inhalte dynamisch. Die Daten werden via REST API direkt vom Server gelesen und dann on the Fly gerendert.

JSON 2 HTML Renderer gibts wie Sand am Meer. Unser Ehrgeiz war aber, dass wir das Problem mittels DOJO lösen (naja auch einige Lizenzfragen sind dann einfach geklärt). Leider ist es mit DOJO so, wie mit manchem genialen Projekt. Irgendwie hat der Dokumentator frei gehabt. Erschwerend kommt dazu, dass im Gebrauch mit XPages noch ein paar Dinge zu beachten sind.

Also zuerst das Kleingedruckte (oder wie krieg ich so ein Design hin, wie es Rechts zu sehen ist).

  1. Wir haben das HTML Template als PAGE erfasst und dort den Contentype auf HTML gesetzt.
  2. Das HTML Template darf nur 1 Root Element haben, sonst hat DOJO ein Problem
  3. Das neue DOJO Modul muss mittels
    <xp:dojoModulePath url=”biz.webgate.mywebgate.person”
    prefix=”mywebgate.Person”>
            </xp:dojoModulePath>
    eingebunden werden.

Tja und dann ist alles ziemlich simpel. Wir erstellen eine Javascript Client -Library, die wir biz.webgate.mywebgate.person.js nenne und schreiben dort folgenden Code rein:

Mittels dojo.provide definieren wir, was dieses File liefert, dojo.require definiert was wir alles brauchen, hier ist dojox.dtl._Templated die Rendering Enginge, die auf django basiert. Im dojo.declare geschieht die Magie. Mittel der cache Anweisung lesen wir das HTML File ein und peron:null erweitert unser Widget um ein neues Objekt.

In der Funktion openPersonTab() fügen wir dann die Person ein. Dabei greifen wir auf ein Spezielles TAB Objekt zu, dass uns das dynamische generieren der Tabs erlaubt. Die Variable xhrArgs definiert den Zugriff auf unser REST Service und lädt von dort das Personen Objekt. Der effektive Aufruf geschicht dann mit dojo.xhrGet(…), aber im Objekt haben wir auch die Verarbeitung des Resultats definiert. load wird dann aufgerufen, wenn wir erfolgreich die Daten abgegriffen haben. Innerhalb dieser Funktion initalisieren wir ein neues Widget und geben die data (das ist das Person Objekt vom Rest Service) direkt an das Widget weiter. dojox.dtl._Template redert dann das Template. Und durch placeAt() hängen wir das Renderresulat an das richtige Ort.

Blicken wir noch in das HTML Template:

Der Zugriff erfolgt über die {{person.____ }} Anweisungen. Wie man aus dem Code erkennen kann sind sowohl IF abfragen, wie auch for Schleifen möglich. Der Sprachumfang von DJANGO wird hier detailiert beschrieben.

Der REST Service liefert übrigens folgenden Code zurück:

Dieses Konstrukt lässt es nun zu, dass wir ohne Rendering Aufgabe für den Server die verschiedensten Personen öffnen:

Der vollständige Code wird im Juni auf openNTF veröffentlicht und ist unter der Apache Lizenz verfügbar.

 

Warum FAST Prototyping nicht RAD (Rapid Application Development) ist… und warum wir lieber SCRUM einsetzen

Innerhalb der WebGate Consulting AG, meinem Arbeitgeber, sind wir es gewohnt, wichtige Themen kontrovers zu diskutieren. Dabei werden natürlich auch Argumente von Spezialisten ins Feld geführt. Eine solche Diskussion hat mich zu folgendem Video geführt:

Natürlich bin ich nicht mit allem Einverstanden, was Herr Goslin innerhalb dieses Videos sagt, aber vieles davon hat mich zum Nachdenken angeregt. Vorallem die Aussage, dass ein Prototyp weggeschmissen wird, und danach wird nochmals neu begonnen. Gemäss James Gossling ist das Ziel eines Prototyps zu sehen, ob etwas so funktionieren kann, während Entwicklung mit Architektur und Engineering zu tun hat.

Ich glaube, dass wir gerade in der Notes / Domino Welt bezüglich FAST Prototyping und RAD einen grossen Fehler gemacht hatten. Betrachtet man RAD nämlich unter der Lupe, so sind im RAD sehr viele Ähnlichkeiten zu SCRUM zu entdecken. Und dabei geht es NICHT darum einen Prototypen zu bauen, sonderen Elemente um Element wird lauffähige Software entwickelt. Auch wenn dem Endkunden in kurzen Zyklen jeweils ein lauffähiges Element seiner Software gezeigt wird, sollte bei RAD vom Endprodukt her entwickelt werden.

Nun wird aber schon in der Beschreibung von RAD das Wort Prototype verwendet, was nicht sehr förderlich ist. Das Problem beim Prototype ist, dass “Abkürzungen” gemacht werden. So werden zum Beispiel Schichten vermischt oder gar übersprungen. Error Handling wird nicht implementiert und noch vieles weiteres wird nicht korrekt umgesetzt. Das gleiche Problem ergibt sich auch den vielen CodeSnippets, die im Internet herumschwirren. Die Snippets zeigen eine isolierte Funktionsweise eines Elementes auf. Auch hier werden einfach starke Vereinfachungen gemacht.

Wer jetzt bereits bei SCRUM nachgeschaut hat, fragt sich sicher, was denn anderst ist als bei RAD. Nun für mich ist eines der signifikaten Elemente, dass der Fokus auf den Stories des Users liegt. In kurzen Sätzen (3 Zeiler) definiert der Kunde, was er will. Und er gewichtet, was er haben will. Der Architekt der Software hingegen ermittelt die Abhängigkeiten der Stories und kann so aufgrund der Kundengewichtung ermitteln, welche Stories wie miteinander zusammen hängen. Das iterationsbasierte Vorgehen liefert dem Kunden lauffähige Software mit abgeschlossenen Userstories. Und abgeschossen heisst eben: ABGESCHLOSSEN. Kein Prototype, sondern es ist für die Userstorie alles umgesetzt und es wurde (da auch hier der Scope auf dem Endzustand ist) eine saubere Architektur und korrekte Entwicklungsprinzipien umgesetzt.

Mit dem Fokus auf die Userstory wird automatisch auch der Fokus auf den Kundennutzen gelegt. Ich glaube dies hilft auch in der Offertphase. Die Frage ist dann nämlich ganz simpel, ist die Umsetzung der Userstories die Offerte wert? Ist mein Nutzen so gross, dass ich sehr gerne das Geld ausgebe?

 

Tags: , , , ,