{"id":1031,"date":"2011-07-11T11:05:53","date_gmt":"2011-07-11T09:05:53","guid":{"rendered":"http:\/\/www.tutego.de\/blog\/javainsel\/2011\/07\/mein-umstieg-auf-uibinder-gwt\/"},"modified":"2011-07-11T11:05:53","modified_gmt":"2011-07-11T09:05:53","slug":"mein-umstieg-auf-uibinder-gwt","status":"publish","type":"post","link":"https:\/\/www.tutego.de\/blog\/javainsel\/2011\/07\/mein-umstieg-auf-uibinder-gwt\/","title":{"rendered":"Mein Umstieg auf UiBinder (GWT)"},"content":{"rendered":"

Das komplette Frontend f\u00fcr die tutego-Kunden\/Trainer\/Serminarverwaltung ist in GWT implementiert. Die Codebase ist auf dem Level von GWT 1.1 und bis zur letzten Version hat sich viel ge\u00e4ndert. \u00dcber Updates blogge ich regelm\u00e4\u00dfig. Es wurde Zeit neu zu betrachten, welche Teile meiner Software ich vielleicht umbauen kann. Viele Themen sind spannend, aber leider gibt im Netz kaum Dokus, und da meine L\u00f6sung l\u00e4uft, war die Motivation nicht sonderlich hoch, Stunden zum Rumspielen zu investieren.<\/p>\n

Eine der gro\u00dfen Neuerungen in GWT 2.0 ist die M\u00f6glichkeit, deklarativ Oberfl\u00e4chen aufzubauen. Im Mittelpunkt steht das UiBinder-Famework, was eine XML-Dateien zur Beschreibung eines Widget-Baum nutzt und in eine initialisierte GWT-Komponente \u00fcberf\u00fchrt. Das Feature ist relativ gut dokumentiert und die \u00c4nderungen im Code sind klein. Daher habe ich mir ein paar Stunden f\u00fcr die \u00dcberf\u00fchrung einer View genommen.<\/p>\n

F\u00fcr jede View gibt es bei mir eine Klasse, die von einer GWT-Klasse wie Composite abgeleitet ist. Sie wird vom Presenter aufgebaut. Die View-Klasse deklariert eine Reihe von Objektvariablen. Die werden sp\u00e4ter initialisiert. Vorher sahen meine Programme etwas so aus:<\/p>\n

\/\/ Contact person<\/p>\n

HTML contactPersonLabel = new HTML( "<b>AnsprechpartnerIn<\/b> (Name, EMail, Telefon)" );
contactPersonLabel.getElement().getStyle().setMarginTop( 0.5, Unit.EM );
panel.add( contactPersonLabel );
panel.add( contactPersonTextBox = new FormTextBox() );    <\/p>\n

\/\/ tutego rate per day <\/p>\n

HTML ratePerDayLabel = new HTML( "<b>tutego Tagessatz<\/b> (netto)" );
ratePerDayLabel.getElement().getStyle().setMarginTop( 0.5, Unit.EM );
panel.add( ratePerDayLabel );
panel.add( new HorizontalFlowPanel( ratePerDayTextField = new FormIntegerTextBox(), new HTML( " Euro" ) ) );
ratePerDayTextField.setWidth( "5em" ); <\/p>\n

Mit Styles arbeite ich auch, wobei ich dies nicht f\u00fcr das Mikrolayout verwende. Lokale Abst\u00e4nde initialisierte ich immer direkt.<\/p>\n

Der UiBinder externalisiert die Beschreibung des Objektgraphen in eine XML-Datei. Es ist wichtig zu verstehen, dass der UiBinder keinen Template-Engine ist, also die XML-Datei kein XHTML ist, wo man a) einfach HTML schreiben kann und b) so etwas wie Wiederholungen\/Fallunterscheidungen schreiben kann. Es ist \u201cnur\u201d eine Beschreibung des Objektgraphen und ausschlie\u00dflich GWT-Widgets werden dort referenziert. (Auch wenn das bei einem SpanElement mit <div><\/div> auf den ersten Blick nicht so aussieht.)<\/p>\n

Das GWT-Plugin f\u00fcr Eclipse erm\u00f6glicht gleich das Anlegen der XML-Datei und der Klasse, was f\u00fcr neue Views praktisch ist. Ich habe von Hand eine XML-Datei EditCustomerView.ui.xml<\/em> aufgebaut, die so aussieht:<\/p>\n

<!DOCTYPE ui:UiBinder SYSTEM "http:\/\/dl.google.com\/gwt\/DTD\/xhtml.ent"<\/a>>
<ui:UiBinder xmlns:ui=’urn:ui:com.google.gwt.uibinder‘
    xmlns:g=’urn:import:com.google.gwt.user.client.ui‘ xmlns:t=’urn:import:traida.client.web.util‘>
    <ui:with field=’res‘ type=’traida.client.resource.TraidaResources‘ \/>
    <ui:style>
       .bottomGap { margin-bottom: 1em; }
    <\/ui:style>
    <g:VerticalPanel>
        <g:Label styleName='{res.style.header1}‘ ui:field=’header‘<\/strong> \/> <\/p>\n

        <t:TitledPanel>
            <g:HTML>Adresse und Kontakt<\/g:HTML>
            <g:Anchor ui:field=’editContactAnchor‘>[Bearbeiten]<\/g:Anchor>
        <\/t:TitledPanel>
        <g:HTML styleName='{style.bottomGap}‘ ui:field=’businessCardHTML‘<\/strong> \/> <\/p>\n

        <t:TitledPanel>
            <g:HTML>Kurs(e)<\/g:HTML>
            <g:Anchor ui:field=’addNewTrainingAnchor‘<\/strong>>[+]<\/g:Anchor>
        <\/t:TitledPanel>
        <t:VerticalFlowPanel styleName='{style.bottomGap}‘ ui:field=’trainingsPanel‘<\/strong> \/> <\/p>\n

        <t:TitledPanel>
            <g:HTML>Vermerk und Logo<\/g:HTML>
        <\/t:TitledPanel> <\/p>\n

\u2026<\/p>\n

    <\/g:VerticalPanel> <\/p>\n

<\/ui:UiBinder><\/p>\n

Am Anfang werden zwei Namensr\u00e4ume g und t aufgebaut, einmal f\u00fcr die Google-Komponenten, einmal f\u00fcr eigene. Eigene Komponenten k\u00f6nnen einfach verwendet werden, auch die Tastaturvervollst\u00e4ndigung klappt, ist allerdings (nur bei mir?) ziemlich tr\u00e4ge.<\/p>\n

Wichtig sind die ui:field<\/strong>-Elemente. Sie entsprechen Variablen, die in einer Java-Klasse deklariert werden. Parallel zu der XML-Datei EditCustomerView.ui.xml <\/strong>gibt es eine andere zugeh\u00f6rige Java-Klasse EditCustomerView<\/strong>. Sie beginnt so:<\/p>\n

class EditCustomerView extends Composite
{
  interface EditCustomerViewUiBinder extends UiBinder<Widget, EditCustomerView<\/strong>> {}  \/\/ 2
  private static EditCustomerViewUiBinder uiBinder = GWT.create(EditCustomerViewUiBinder.class); <\/p>\n

  @UiField Label header;    \/\/ 1<\/strong><\/p>\n

  \u2026 <\/p>\n

  EditCustomerView()
  {
    initWidget( uiBinder.createAndBindUi( this )<\/strong> );  \/\/ 3
    setWidth( "800" ); 
     \u2026<\/p>\n

  }<\/p>\n

}<\/p>\n

Im Rumpf ist etwas Magie, und drei Details sind wichtig:<\/p>\n

    \n
  1. Die Klasse hat f\u00fcr alle in der XML-Datei deklarierten ui:field-Dinge eine Objektvariable mit der entsprechenden Annotation @UiField. Die Typen m\u00fcssen zusammenpassen, also Label zu <g:Label> usw. Der UiBinder instanziiert selbst\u00e4ndig die Typen durch den Standardkonstruktor. Ist keiner vorhanden, muss man tricksen und eine Factory einf\u00fchren. <\/li>\n
  2. Zu den Generics beim UiBinder: das erste Typargument (hier Widget) ist das, was sp\u00e4ter als Ergebnis \u201crauskommt\u201d. In der XML-Datei nutze ich ein VerticalPanel, sodass der Typ h\u00e4tte eigentlich auch spezieller sein k\u00f6nnen, doch den spezielleren Typ brauche ich nicht. Das zweite Typargument ist die Klasse, die die @UiField-Variablen deklariert, also die eigene Klasse selbst. <\/li>\n
  3. Der Aufruf createAndBindUi() baut den Objektbaum auf. Das Ergebnis der Methode ist vom Typ, der im ersten Generics zugewiesen wurde, also im Beispiel Widget. <\/li>\n<\/ol>\n

    Das zur Technik. Die Frage ist, ob sich die Umstellung gelohnt hat. Bisher habe ich eine View umgestellt, doch das Ergebnis sieht gut aus. Die hierarchische Gliederung ist \u00fcbersichtlich, wobei mir die XML-Ansicht reicht und ich den Designer nicht brauche. Allerdings f\u00e4nde ich es besser, das Layout einfacher ver\u00e4ndern zu k\u00f6nnen. Soll zum Beispiel der Abstand zur n\u00e4chsten Zeile erholt werden, so kann man nicht einfach beim Element selbst ein CSS-Syle setzen, sondern muss ein <style> Element einf\u00fchren, ihm einen Namen geben und dann zuweisen. Das ist mehr Schreibarbeit als n\u00f6tig. Die anderen Views werde ich nun auch umstellen.<\/p>\n

    Ob ich die UiBinder f\u00fcr jede View einsetzen werde wird sich zeigen, da einige Views viel st\u00e4ter aus HTML aufgebaut werden und die View im Prinzip nur einen Titel setzt und der Rest ist HTML.<\/p>\n

    Ein paar Links:<\/p>\n