Real Application. Testing

Transkript

1 Einfache GUIs mit Python und QT >>> S. 50 Deutschland 6,50 Österreich 7,00 Schweiz sfr 13,40 Juli/August Juli/August Real Application Google Hacking Finden, was nicht gefunden werden soll Polyglot Persistence Ist SQL beziehungsfähig? Testing Professionelle Service- und Softwaretests Der agile Architekt Scrum für Softwarearchitekten istockphoto.com/tharrison SERIE GWT MVP und Activities and Places SERIE OpenGL Landschaftsdarstellung

2 GWT Web MVP Pattern und Activities and Places Framework GWT für Anspruchsvolle Die Anforderungen an komplexe User Interfaces in Webapplikationen werden höher und die Technologien zum Erzeugen derselben immer leistungsfähiger. Neben einer intuitiven Benutzerführung werden das Setzen von Bookmarks oder die Verwendung der Browserbuttons und des Browserverlaufs vorausgesetzt. Zur Bereitstellung dieser Funktionalitäten kann das in Google Web Toolkit (GWT) integrierte Activities and Places Framework verwendet werden. Strukturiertheit und Skalierbarkeit spielen auch bei der Entwicklung des Codes der Webapplikation eine wichtige Rolle und sollen nicht nur Eigenschaften der Webseite für den Endbenutzer sein. Die Versuchung ist oft groß, die darstellende Schicht einer Applikation und die Businesslogik nicht strikt zu trennen. Zur Lösung dieses Problems kann für die Entwicklung von User Interfaces mit GWT das Model-View-Presenter-(MVP-)Software-Pattern eingesetzt werden. von Raffaela Brodt Das Activities and Places Framework erlaubt das Management des Browserverlaufs und die damit verbundene Bedienung der Vor-, Zurück- und Refresh-Buttons, die jeder gängige Browser zur Verfügung stellt. Seit der Version 2.1. ist dieses Framework in GWT integriert [1]. Das Grundprinzip ist, dass jedem User Interface (UI) eine Activity und ein Place zugeordnet ist. Die Activity wird aufgerufen, wenn zu einer neuen Maske navigiert wird. Sie implementiert die Methoden oncancel(), onstop() und start(acceptsonewidget panel, EventBus eventbus). In der start-methode werden alle Daten geladen, die für die Darstellung notwendig sind. Am Ende der Methode wird die Darstellungskomponente gesetzt und ist dadurch sichtbar. Ein Place stellt einen Platz in der Applikation dar. Er ist über den ActivityMapper immer an eine Activity gebunden, und diese wird dadurch via URL erreichbar. Ein Place erweitert den gwt.app.place.place und implementiert einen PlaceTokenizer. Für jede Seite der Applikation wird also ein eindeutiges Token als String definiert, das beim Vor- und Zurücknavigieren in dem Browserverlauf wiederhergestellt werden kann [1]. Das MVP Pattern allgemein Das Model View Controller (MVC) Pattern, aus dem das MVP Pattern hervorgeht, ist die Grundlage für die Kapselung der darstellenden Komponente (View), der Businesslogik (Model) und einer steuernden Komponente (Controller/Presenter). Durch diese Aufteilung werden Codewiederholungen vermieden, die Testbarkeit und Wiederverwendbarkeit des Sourcecodes erhöht und damit die Fehleranfälligkeit und der Wartungsaufwand minimiert. Der Vorteil von MVP im Vergleich zu MVC ist, dass die Darstellung völlig vom Model entkoppelt wird, indem ein Presenter dazwischen geschaltet wird (Abb. 1). Für große Applikationen, die mit GWT umgesetzt werden, empfiehlt Google das MVP Pattern und nennt Abb. 1: MVP Pattern Entwickler Magazin

3 Web GWT dafür zwei Hauptgründe: Einerseits wird durch die Entkoppelung ermöglicht, dass viele Entwickler zeitgleich an der gleichen Codebasis arbeiten können. Andererseits wird die Anzahl der benötigten Testfälle minimiert [2]. Wenn Businesslogik sowohl in der View als auch im Model abgebildet wird, erhöht sich der Testaufwand erheblich, vor allem, wenn die View viele Abhängigkeiten vom Model besitzt. Durch die Implementierung der Logik im Presenter konzentriert sich der Testaufwand auf diese Klassen, und das Mocken wird erheblich erleichtert. Listing 1: View-Java-Klasse public class SomeUserClass extends Composite { private static SomeUserClass UiBinder uibinder = GWT.create(SomeUserClassUiBinder. class); private SomePresenter presenter; interface SomeUserClassUiBinder extends UiBinder<Widget, MdUserdata> Label lblfirstname, TextBox txtfirstname, Button btnok; public SomeUserClass() { initwidget(uibinder.createandbindui(this)); // Setting internationalized Strings into the Labels lblfirstname.settext(i18nuimessages.instance.firstname()); lbllastname.settext(i18nuimessages.instance.lastname()); // Setting styles to the TextBoxes txtlastname.setstylename(resources.instance.css().somestyle()); txtfirstname.setstylename(resources.instance.css().somestyle2()); // Setting WidgetIds for the selenium test cases ClientUtils.setWidgetId(txtFirstName, "txtfirstname", "SomeUserClass"); ClientUtils.setWidgetId(txtLastName, "txtname", "SomeUserClass "); btnok.addclickhandler(new ClickHandler() { public void onclick(clickevent event) { presenter.userokclicked(); ); // This method is called from the Activity within the start() method public void init(string first, String last) { txtfirstname.settext(first); txtlastname.settext(last); public void setpresenter(somepresenter presenter) { this.presenter = presenter; Die View In GWT kann die View aus einer Java-Klasse und einer XML-Datei bestehen. Letztere enthält die Struktur der Darstellung, während sich in der Java-Klasse die Methoden für das Verhalten des UI befinden. Beide Files werden mittels UI Binder aneinander gebunden. Grund für diese Trennung ist, dass ab GWT 2.0 die Darstellung an sich noch einmal separiert und gekapselt werden kann. Styles für Elemente sind in einer oder mehreren CSS Files definiert, die mittels Resource Bundle eingebunden sind und in der Java-Klasse gesetzt werden. Alle Texte sind internationalisiert in mehreren Property Files abgelegt, die ebenfalls in der Java-Klasse den jeweiligen Widgets zugewiesen werden. Ähnlich wie in Java AWT oder Swing stellt GWT Event Handler, wie zum Beispiel den FocusHandler, den ValueChangeHandler oder den Key- PressHandler, zur Verfügung. In unseren Applikationen enthält die Java-Klasse also zumeist einen ClickHandler, setzt die CSS Styles und den internationalisierten Text aus den Property Files und vergibt eindeutige Widget IDs, die für die Selenium-Testfälle benötigt werden. Jedes Event wird an den Presenter weitergereicht. Weder die Java-Klasse (Listing 1) noch das XML (Listing 2) enthalten Businesslogik. Diese wird vollständig im Presenter implementiert. Das Model Das Model enthält alle Entitäten und Daten der Applikation. Benötigt eine View Daten aus dem Model, Listing 2: View-XML-File <g:htmlpanel> <g:verticalpanel> <g:grid borderwidth="0" width="100%" height="100%"> <g:row> <g:label ui:field="lblfirstname"/> <g:textbox ui:field="txtfirstname"/> </g:row> <g:row> <g:label ui:field="lbllastname"/> <g:textbox ui:field="txtlastname"/> </g:row> </g:grid> <g:flowpanel> <g:button ui:field = "btnok"/> </g:flowpanel> </g:verticalpanel> </g:htmlpanel> 90 Entwickler Magazin

4 GWT Web holt sich der Presenter diese über die RequestFactory. Um Daten zwischen Server und Client hin und her zu senden, werden Proxies (DTOs) notwendig. Diese stellen Repräsentationen von Serverentitäten am Client dar. Sollen Daten durch Events im Client gespeichert werden (beispielsweise durch Neuanlage eines Benutzers), so ruft der Presenter ebenfalls über die RequestFactory die entsprechende Methode in der passenden Entity auf. Die RequestFactory ermöglicht objektorientierte Interaktion zwischen Presenter und Model. Über diese Factory können Methoden des Models aufgerufen und Rückgabewerte dieser Methoden empfangen werden. Der Datentransfer von View zu Model kann unter anderem mit dem Editor Framework realisiert werden [3]. Der Presenter Im Presenter vereinen sich das Activities und Places Framework sowie das MVP Pattern. Einen Teil des Presenters stellen Activities und Places dar. Der Presenter besteht in unseren Applikationen aus einer Activity und einem Place, die für jede UI-Maske vorhanden sind, sowie einer Presenter-Klasse. Die Presenter-Klasse wird nach Themengebieten und nicht pro View erstellt. Dort befindet sich die Businesslogik, die sich aus den Aktionen in der View (beispielsweise dem Sichern von Daten ins Model, der Validierung von Eingabedaten oder der Durch das MVP Pattern ist Entkoppelung möglich viele Entwickler können zeitgleich an derselben Codebasis arbeiten. Navigation zu einem andern Place in der Applikation) ergibt. Im Konstruktor jeder Activity in unseren Applikationen wird die entsprechende Instanz der Darstellungskomponente von der Klasse Client Factory geholt. Stattdessen könnte auch ein Dependency Injection Framework (GIN für GWT) verwendet werden [4]. Ferner holt sich die Activity ausschließlich jene Daten vom Model, die für die Darstellung, also den Start der View, notwendig sind. Die Activity implementiert außerdem die Logik, die für die Anzeige von UI-Feldern oder deren Befüllung verantwortlich ist. Werden beispielsweise Eingabefelder aufgrund von bestimmten Berechtigungen deaktiviert, wird diese deactivate-methode, die in der View implementiert ist, von der Acitivity nach der entsprechenden Prüfung aufgerufen. Die Activity ist auch für die Auflösung von eventuell auftretenden Race Conditions zuständig. Diese können durch die asynchrone Verarbeitung der Calls zum Model auftreten [5]. Ein Place enthält, wie bereits beschrieben, immer einen Tokenizer, der für den Aufbau des URLs verantwortlich ist. Es können auch diverse Attribute über Places hinweg transportiert werden. Das kann beispielsweise bei Maskenverläufen notwendig werden, wo Variablenwerte über mehrere Places hinweg benötigt werden, um zum Beispiel Objekte zu spezifizieren, die vom Server nachgeladen werden müssen. Listing 3: Activity public class SomeUserActivity extends AbstractActivity { private SomeUserClass view; public SomeUserActivity(ClientFactory clientfactory) { // get view instance from ClientFactory view = clientfactory.getsomeuserclass(); public void oncancel() { // do something when the start method has not yet replied to the // callback, but the user has lost interest[6]. public void onstop() { // do something when the Activity's widget has been removed from view. All // event handlers it registered will have been removed before this method is // called.[6] // Within this method, model requests are fired and view methods to manage UI // elements are called; public void start(acceptsonewidget panel, EventBus eventbus){ requests.someuserrequest().findsomeuser().fire(new Receiver<SomeUserProxy>(){ public void onsuccess(someuserproxy response) { // Set data into the view view.init(response.getfirstname(), response.getlastname()); public void onfailure(serverfailure error) { log.info("failed to load user!"); ); panel.setwidget(view); Entwickler Magazin

5 Web GWT Abb. 2: Funktionsweise des Activities and Places Frameworks mit MVP Funktionsweise in Kombination mit MVP Wenn im UI z. B. ein Button geklickt wird, wird von der View aus die entsprechende Presenter-Klasse aufgerufen. Im Presenter werden die Daten verarbeitet, die aus den Feldern der View übergeben werden. Außerdem wird die Navigation zu einem anderen Place veranlasst, sofern der Buttonklick einen Maskenwechsel mit sich bringen soll. Das geschieht mit der goto-methode Listing 4: Place public class SomeUserPlace extends Place { des PlaceControllers. Der PlaceController feuert anschließend ein PlaceChangeEvent, auf das PlacesHistoryHandler und ActivityManager gleichermaßen reagieren [1]. Der PlaceHistoryHandler updatet sich selbst mit dem aktuellen Place Token. Der ActivityManager ruft den entsprechenden ActivityMapper auf. Der ActivityMapper bestimmt die nächste Activity abhängig vom übergebenen Place. Anschließend wird die start-methode in der Activity aufgerufen. Die Activity holt sich vom Model alle Daten, die zur Anzeige der aufrufenden Darstellungskomponente notwendig sind, und setzt die View (Abb. 2). Die PresenterClass wäre nicht unbedingt nötig, denn diese könnte auch vollständig in den stop()- oder cancel()-methoden der Activities implementiert werden. Allerdings haben wir in unseren Applikationen diese zusätzliche Schicht eingezogen, um themenverwandte Aufrufe an einer Stelle und nicht in jeder Activity separat zu implementieren. Das Activities and Places Framework kann unabhängig von MVP verwendet werden, genauso wie nach MVP ohne Activities and Places Framework entwickelt werden kann. Durch die Integration des Activities and Places Frameworks in GWT kann allerdings empfohlen werden, dieses in Kombination mit dem MVP Pattern zu implementieren. Raffaela Brodt ist Project Manager bei Cenarion Information Systems GmbH. Kontakt: raffaela.brodt@cenarion.com public SomePlace() { // Tokenizer public static class Tokenizer implements PlaceTokenizer<SomeUserPlace> { private RequestFactory requests; public Tokenizer(RequestFactory requests) { this.requests = requests; public SomeUserPlace getplace(string token) { if("someuser".equals(token)) return new SomeUserPlace(); else return null; public String gettoken(someuserplace place) { return "someuser"; Links & Literatur [1] DevGuideMvpActivitiesAndPlaces: web-toolkit/doc/latest/devguidecodingbasicshistory [2] [3] Luipersbeck, Stefanie: GWT: Integration des GWT Editor Frameworks in eine MVP-Applikation, in Entwickler Magazin [4] DevGuideMvpActivitiesAndPlaces#ClientFactory [5] Blümelhuber, Elisabeth: GWT: Asynchrone Requests und Race Conditions, in Entwickler Magazin [6] google/gwt/activity/shared/abstractactivity.html 92 Entwickler Magazin

6 Jetzt abonnieren! entwickler 3 Jetzt 3 Top-Vorteile sichern! 1 Alle Printausgaben frei Haus erhalten Intellibook-ID kostenlos anfordern ( 2 Mit der Intellibook-ID kostenlos in der App anmelden und Zugriff auf alle Ausgaben des Entwickler Magazins erhalten (+ Bonusinhalte!) Zugriff auf das komplette PDF-Archiv mit der Intellibook-ID3