insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 25 mars 2011

Retour d'expérience d'un projet GWT : 8 Internationalisation (8/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

Dans le cadre du projet, nous avons mis en place l'internationalisation de l'application. Voici la documentation officielle de Google :

Nous avons ajouté le module I18N dans le module GWT "Module.gwt.xml" :

<inherits name="com.google.gwt.i18n.I18N"/>


Internationalisation en JAVA

Nous avons créé 3 classes :

  • /src/main/java/bws/i18n/ModuleConstants.java de type Constants
  • /src/main/java/bws/i18n/ModuleConstantsWithLookup.java de type ConstantsWithLookup
  • /src/main/java/bws/i18n/ModuleMessages.java de type Messages

Ainsi que les fichiers properties suivant qui correspondent à la traduction par défaut :

  • /src/main/resources/bws/i18n/ModuleConstants.properties
  • /src/main/resources/bws/i18n/ModuleConstantsWithLookup.properties
  • /src/main/resources/bws/i18n/ModuleMessages.properties

Et pour la traduction en français :

  • /src/main/resources/bws/i18n/ModuleConstants_fr.properties
  • /src/main/resources/bws/i18n/ModuleConstantsWithLookup_fr.properties
  • /src/main/resources/bws/i18n/ModuleMessages_fr.properties

Les fichiers ".properties" doivent être au format UTF-8, et les apostrophe (') doivent être dédoublé pour les interfaces étendant l'interface Messages (pas pour les Constants)

Par exemple pour afficher un message internationalisé depuis du code java d'une classe cliente (GWT) vous devez respecter la procédure suivante :

1/ Créer une méthode dans ModuleConstants.java, par exemple :

String warnCloseWindow();

2/ Ajouter une entrée dans les fichiers ModuleConstants*.properties avec la traduction correspondante:

warnCloseWindow=Are you sure you want to close this window?

3/ Utiliser cette clé dans votre classe java :

Window.alert(ModuleConstants.CONSTANTS.warnCloseWindow());

Pour la classe ModuleConstantsWithLookup, cela fonctionne de la même façon (méthode + clé correspondante) mais il est également possible de récupérer la valeur d'une clé à partir de la clé et sans appelé la méthode directement. Comme dans le code suivant ou on cherche à récupérer la valeur pour la clé "theKey":

ModuleConstantsWithLookup.CONSTANTS.getString("theKey");

Pour la classe ModuleMessages, il est possible de donner des paramètres aux méthodes qui seront intégrer dans la traduction. Un texte ne se place pas forcement au même endroit en fonction de la traduction (au début ou à la fin).

On met le numéro du paramètre (en commençant à 0) entre accolades (ex {0}), il est ensuite possible d'appliquer un formatage ({1,number} ou {0,date,medium} : en utilisant le formatage de la langue courante). On peux aussi gérer les formes singuliers et pluriels :

String cartItems(@PluralCount int itemCount);

et dans le fichier ".properties" :

cartItems = There are {0,number} items in your cart.
cartItems[one] = There is 1 item in your cart.
cartItems[none] = There is no item in your cart.


Internationalisation avec UiBinder

Pour traduire les libellés contenus dans des écrans UiBinder*.ui.xml vous devez encadrer la chaîne de caractère avec des balises spécifiques. Il vous faut tout d'abord ajouter ceci à votre fichier *.ui.xml dans la balise ui:UiBinder: ui:generateFormat='com.google.gwt.i18n.rebind.format.PropertiesFormat' ui:generateKeys="com.google.gwt.i18n.rebind.keygen.MD5KeyGenerator" ui:generateLocales="default"

Pour avoir au final:

<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"    
 ui:generateFormat='com.google.gwt.i18n.rebind.format.PropertiesFormat'
 ui:generateKeys="com.google.gwt.i18n.rebind.keygen.MD5KeyGenerator"   
 ui:generateLocales="default"
 xmlns:g="urn:import:com.google.gwt.user.client.ui">
...
</ui:UiBinder>

Par exemple, pour traduire : "where you can build your own workspace with widget" Il faut remplacer la chaine par :

<ui:msg description="FourthSentence">where you can build your own workspace with widgets.</ui:msg>

Et ce va automatiquement créer une nouvelle clé pour ce libellé. Vous trouverez les fichier properties générés dans target/extra/module

Ils sont nommés avec le full qualified name du fichier java concaténé avec le nom du fichier ui.xml puis suffixés avant l'extension par GenMessages... Simplissime non ? Merci Google (Cela évoluera très prochainement dans les futures release de GWT pour être simplifié)

Par exemple:
module.client.homepage.HomePageMenuHomePageMenuUiBinderImplGenMessages.properties

Ensuite nous positionnons un fichier dans le répertoire ou se trouve le fichier ui.xml à internationaliser, par exemple pour HomePageMenu.ui.xml :

/src/main/java/module/client/homepage/HomePageMenuHomePageMenuUiBinderImplGenMessages.properties

et évidemment :
/src/main/java/module/client/homepage/HomePageMenuHomePageMenuUiBinderImplGenMessages_fr.properties


Utilisation simplifiée

Une autre technique consiste à utiliser une petite ruse de Google : Si le compilateur, ne trouve pas le fichier de properties selon le nom donnée, il va chercher dans le fichier :
/src/main/ressources/com/google/gwt/i18n/client/LocalizableResource.properties

ou pour la version française :
/src/main/ressources/com/google/gwt/i18n/client/LocalizableResource_fr.properties

Il est ainsi possible de mettre toutes les traductions des fichiers UiBinder dans ce fichier et avoir un gestion simplifier de toutes les traductions. Pour créer ce fichier, un développeur a créé un petit script Python pour scanner tous les fichiers "*.properties" générées par le compilateur et les ajouter dans ce fichier. Il fait ensuite un mixte avec les clés de langues déjà existantes, et indique dans un commentaire, les textes à traduire, et surtout ceux dont la description a changé et qu'il faut peut être revoir la traduction.

Le script python mergelocales.py est disponible ici

Il suffit de le lancer avec :

mergelocale.py target/extra/module src/main/ressources/com/google/gwt/i18n/client/

mardi 22 mars 2011

Retour d'expérience d'un projet GWT : 7 Mise en place de Gin sur le projet (7/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

Définitions de GIN/GUICE

Définition de Gin# : “GIN (GWT INjection) brings automatic dependency injection (DI) to Google Web Toolkit client-side code. GIN is built on top of Guice and uses (a subset of) Guice's binding language. (See GuiceCompatibility for details.) By using GWT's compile-time Generator support, GIN has little-to-no runtime overhead compared to manual DI.”

Définition de Guice# : “Guice is a dependency injection (DI) container”

Pour résumer, Gin est une librairie permettant de faire de l’injection de dépendance par paramètrage sur des projets GWT. Le but de l’injection de dépendance est de se passer du code permettant de relier les différents modules de l’application entre eux en le centralisant, ce qui améliore la lisibilité du code. Pour cela, il suffit de créer une factory ainsi que la configuration du binding des différents modules.

Configuration de Gin

Ajout de Gin en dépendance du projet (Maven / Classpath)

Il faut que les librairies Gin et Guice soient dans les dépendances Maven / Classpath du projet. Pour cela, il faut ajouter dans le pom.xml les dépendances suivantes :

     <dependency>
          <groupId>com.googlecode.gwt.inject</groupId>
          <artifactId>gin</artifactId>
          <version>1.0</version>
          <scope>provided</scope>
      </dependency>
      <dependency>
          <groupId>com.google.inject</groupId>
          <artifactId>guice</artifactId>
          <version>2.0</version>
          <scope>provided</scope>
      </dependency>

Le scope provided est utilisé pour que ces librairies ne soient pas embarquées dans le war généré par le projet qui les utilise.

Ajout de Gin en dépendance du projet (GWT)

Il faut que les librairies Gin et Guice soient dans les dépendances GWT du projet. Pour cela, il faut ajouter dans le Module.gwt.xml la dépendance suivante :

<module>
...
<inherits name="com.google.gwt.inject.Inject"/>
...
</module>

Création d’un injecteur de dépendances Gin

Pour pouvoir récupérer les modules dont les dépendances sont gérées par Gin, il suffit de créer une interface annotée dans laquelle on défini pour chacun des modules de l’application une méthode permettant de le récupérer.

@GinModules(ModuleInjectorModule.class)
public interface ModuleGInjector extends Ginjector {
  AppPresenter getAppPresenter();
  FooterPresenter getFooterPresenter();
  DisplayFactory getDisplayFactory();
  GlobalLayout getGlobalLayout();
}

Par exemple, dans notre cas, nous avons besoin de Gin pour gérer les dépendances du Presenter AppPresenter, nous avons donc défini une méthode getAppPresenter qui retourne un AppPresenter. En appelant cette méthode, Gin va s’occuper d’instancier automatiquement le Presenter en lui injectant les dépendances telles qu’elles sont configurées dans le module de configuration du binding Gin.

L’interface est annotée avec l’annotation @GinModules qui prend en paramètre la class du module de configuration du binding Gin.

Création du module configuration du binding Gin

Gin a besoin de connaitre la configuration du binding des modules de l’application. Pour cela, il faut créer une classe dans laquelle les liaisons entre les modules sont définies.

public class ModuleInjectorModule extends AbstractGinModule {
  @Override
  protected void configure() {
      //Say to GIN to bind the Display to the FooterView and
      //use a Singleton scope for the application
      //This singleton view will be injected to the MainLayout
      bind(FooterPresenter.Display.class).to(FooterView.class).in(Singleton.class);
      bind(GlobalLayout.class).in(Singleton.class);
      bind(AppPresenter.Display.class).to(GlobalLayout.class).in(Singleton.class);
  }

  /**
   * This Provider is used by GIN to inject all HandlerManager field
   * Use the legacy GlobalEventBus.get()
   */
  @Provides
  HandlerManager getGlobalEventBus() {
      return GlobalEventBus.get();
  }
}

Par exemple, dans notre cas, le FooterPresenter définie sa vue via l’inner classe Display qui est implémentée par la FooterView et cette classe n’a qu’une seule instance dans l’application. Ce qui se traduit par la ligne suivante :

bind(FooterPresenter.Display.class).to(FooterView.class)
                                  .in(Singleton.class);

Il est également possible de fournir a Gin des classes dont il ne gère pas le cycle de vie. Par exemple, dans notre cas, comme nous avons progressivement migré vers Gin, et pendant cette phase de migration, certaines classes devaient être a la fois utilisée par Gin et également être utilisée par le système d’injection de dépendance manuel utilisé précédemment.

C’est le cas pour notre Bus d'évènement par exemple, c’est pourquoi nous avons ajouté cette méthode :

  @Provides
  HandlerManager getGlobalEventBus() {
      return GlobalEventBus.get();
  }

Instancier le Gin Injector dans l’application et l’utiliser

Pour utiliser l’injecteur de dépendance Gin, il suffit d’ajouter dans le Module GWT de l’application un attribut static puis de l’utiliser comme suit:

public class Module implements EntryPoint {
   private final ModuleGInjector injector =  GWT.create(ModuleGInjector.class); 
   public void onModuleLoad() {
      ...
      MyPresenter myPresenter = injector.getMyPresenter();
      ...
   }
}

Il est nécessaire de faire ce GWT.create une fois dans l'application pour que GIN puisse être appeler au moins une fois.

Aller plus loin avec Gin

Gin permet de binder les classes GWT utilisant le deferred binding comme les interfaces des constantes et messages pour l'internationalisation, ce qui facilite leur utilisation car c’est Gin qui s’occupera de les instanciers pour nous.

Gin permet également de binder les services RPC GWT pour faciliter leur utilisation.

Gin permet d’utiliser des fonctionnalités de Guice dans GWT mais toutes ne sont pas accessibles à cause des limitations de GWT.

Voir le tableau récapitulatif des fonctionnailités disponibles

Voir la documentation de Guice pour plus d’informations

mardi 1 mars 2011

Retour d'expérience d'un projet GWT : 6 Ecrire des tests unitaires avec Mockito (6/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

Tester une application GWT avec une architecture MVP permet de pouvoir écrire des tests JUnit en java pure sans utiliser l'implémentation GWT de JUnit qui démarre un serveur web et un navigateur pour lancer les tests unitaires. Ce qui prend du temps si l'on doit exécuter ses tests à chaque modification de l'application.

Pour qu'il soit possible d'écrire des tests en Java pure, il faut que le Présenter ne possède aucune référence à des classes du package Ui de GWT. C'est à dire toutes les classes qui étendent Widget et qui permettent d'afficher des informations, ce qui logiquement doivent être définie dans la vue. Il faut ainsi écrire un contrat entre le présenteur et la vue sous la forme d'une interface Display. Ce contrat ne doit posséder que des paramètres et valeurs de retour définie par une interface ou pouvant être utiliser par Java (pas de TextBox getLogin() mais un HasValues<String> getLogin() ou toute autre classe faisant référence à des Widget GWT)

De même, il n'est pas possible d'utiliser GWT.create() autrement dit, pour instancier les services RPC, les classes de Constantes pour l'internationalisation, etc ...

Il est donc nécessaire de faire ses instanciations en dehors du Presenter, et ne prendre en paramètre que l'interface de ceux-ci. Il deviens ainsi possible de créer une version spécifique pour les tests, en règle générale, on va écrire des classes qui implémentent les interfaces avec du code minimal pour réaliser nos tests (getter, setter, hash maps pour enregistrer les données, calcule simple ...). Ces classes doivent être maintenue lors que l'on modifie l'application, et peuvent avoir des bugs qui empêche le test de fonctionner correctement.

C'est là que Mockito prend toute sa puissance, en implémentant automatiquement ses interfaces et en ajoutant le comportement de ceux-ci.

Il faut ajouter la dépendance à Mockito à Maven :

     <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>4.8.1</version>
         <scope>test</scope>
     </dependency>
     <dependency>
         <groupId>org.mockito</groupId>
         <artifactId>mockito-all</artifactId>
         <version>1.8.5</version>
         <scope>test</scope>
     </dependency>

Les tests doivent être écrit avec JUnit 4 et être exécutés par le Runner spécifique de Mockito (si on veux utiliser les annotations automatique permettant de créer les mock et les arguments captor)


Mockito

Mockito est un générateur automatique de doublures. Il fonctionne sur le mode de l'espion :

  • On crée les mocks;
  • On décrit leur comportement
  • Ensuite, à l'exécution, toutes les interactions avec les mocks sont mémorisés ;
  • à la fin du test, on interroge les mocks pour savoir comment ils ont étés utilisés.

Toutes les méthodes de mockito sont des méthodes static de la classe Mockito, il est donc nécessaire d'importer statiquement ses méthodes pour simplifier l'écriture :

import static org.mockito.Mockito.*;

On crée un mock soit avec la méthode mock :

MonInterface mock = mock(MonInterface.class);

soit en utilisant l’annotation @Mock:

@Mock
MonInterface mock;

Il n'est pas nécessaire que MonInterface soit une interface, il est possible de mocker une classe (mock(Widget.class) permet d'utiliser une classe GWT dans le test dans que cela pose de problème, une version vide ayant les mêmes méthodes publique est créé par mockito)

On décrit ensuite le comportement attendu de notre mock :

when(mock.maMethode()).thenReturn(42);

On appelle les tests, qui font des interactions avec notre mock, et enfin on vérifie ses interactions

verify(mock).maMethode();

Cette dernière ligne vérifie que la méthode maMethode() a bien été appelé durant le test.


Définir le comportement d'un mock

Pour définir, le comportement d'un mock, on utilise when() auquel on passe en paramètre l'appel que l'on veux définir, c'est à dire l'appel de la méthode avec les paramètres que l'on doit répondre :

interface Add {
    public int add(int a, int b);
}

Si on veux émuler le comportement de notre méthode add qui additionne les deux paramètres, on va donner les résultats pour des paramètres données :

Add mockAdd = mock(Add.class);
when(mockAdd.add(1, 1)).thenReturn(2);
when(mockAdd.add(5, 7)).thenReturn(12);

Ainsi si dans notre test, on appelle mock.add(1, 1), le retour sera 2.

On peux donner plusieurs valeurs de retour qui seront retourné dans l'ordre :

Par exemple, si on veux simulé les retours de la methode random, on fera :

when(randMock.random()).thenReturn(5, 18, 86, 42);

Ainsi le premier appel de random() retournera 5, et le quatrième appel retournera 42 (ainsi que tous les suivants).

On peux aussi simuler l'envoie d'une exception avec la method thenTrow() :

when(mock.div(anyIn(),0)).thenTrow(new Exception("Division par zéro));

Qui lancera alors une exception lors que le deuxième paramètre est un zéro.


Vérifier les appels aux mock

La méthode verify() qui prend en parametre permet de vérifier qu'une méthode à bien été appeler :

verify(mock).mustCall(1)

Cette ligne permet de vérifier que la méthode mustCall a bien été appelé lors du test, et de plus permet de vérifier que le paramètre est bien 1.

On peux tester le nombre de fois où la methode a été appellé :

verify(mock, times(5)).add(anyString());

On vérifie ici que la méthode add a été appellé 5 fois avec une chaînes de caractères en paramètre.

Si on veux tester plus de choses sur les arguments, il est possible de les capter (les enregistrer) pour ainsi faire des tests plus poussé dessus :

ArgumentCaptor<User> captor = ArgumentCaptor.forClass(User.class);
verify(userservice).login(captor.capture());
assertEquals("login", captor.getValue().getLogin());

On peux aussi vérifier qu'il n'y a pas eu d'interaction avec un mock

verifyZeroInteractions(mock);


Utilisation avec GWT

Si on veux tester qu'un événements a bien été envoyé par GWT, on utilise les mock et les ArgumentCaptor :

@Captor
ArgumentCaptor<ValueChangeEvent<String>> valueChangeEventCaptor;

@Mock
ValueChangeEventHandler<String> handler;

@Test
void testValueChangeEventHandler() {
    TestClassWithValueChangeHandlers test = new TestClassWithValueChangeHandlers();
    //On s'enregistre dans l'eventBus à l'évènement click
    test.addValueChangeHandler(handler);
    //On appelle la methode à tester qui envois notre évènement ValueChange();
    test.setValue("newValue");
    //On vérifie que celui-ci a bien été appellé
    verify(handler).onValueChange(valueChangeEventCaptor.capture());
    //On test que la nouvelle valeur est bien danc l'object event :
    assertEquals("newValue",             valueChangeEventCaptor.getValue().getValue());
}

Références Documentation de Mockito

jeudi 10 février 2011

Retour d'expérience d'un projet GWT : 5 Implémentation Modèle-Vue-Présenteur (5/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

Voyons maintenant comment créer une architecture Model-View-Presenter.

Le présenteur doit étendre la classe Presenter qui fournit des fonctionnalités de base à notre application. Comme l'accès au global event bus et à la factory de vue.

public class TestPresenter extends Presenter {

    /**
     * Interface represents the test view
     */
    public interface Display extends DisplayView {
        public void setUserName(String username);

        public HasClickHandlers getUserNameClickHandler();
    }
   
    // fields
    /** View */
    Display display;
   
    // constructor
    public TestPresenter(Display display, HandlerManager globalEventBus, DisplayFactory factory) {
        super(globalEventBus, factory);
        this.display = display;
       
        bind();
    }
   
    // Bind all event
    private void bind(){
                getGlobalEventBus().addHandler(
            OnUserLoggedEvent.getType(),
            new  OnUserLoggedEvent.Handler() {
            @Override
            public void onUserLogged(OnUserLoggedEvent event) {
                display.setUserName(event.getUser()
                        .getLogin());
            }
        });
        display.getUserNameClickHandler().addClickHandler(
            new ClickHandler() {
                public void onClick(ClickEvent event) {
                    getGlobalEventBus().fireEvent(
                        new OnUserLogout());
            }
        }       
    }

    public void go(Placer panel) {
        panel.setView(display);
    }
}

Nous avons ici l'architecture de base d'un presenter :

  • Le constructeur prend en paramètre toutes les interfaces qu'il va utiliser :
    • sa vue interfacé par l'interface interne au presenter : Display
    • le global event bus (Bus d'évènement global à l'application pour la communication entre les presenter)
    • la factory de vue (utilisée pour instancier les vues des sous-presenters)
    • Éventuellement des services RPC
  • la méthode bind() qui s'occupe d'enregistrer le présenteur aux évènements globaux de l'application (ici le login de l'utilisateur) et aux évènements de la vue (ici le click sur le label affichant le login de l'utilisateur).
  • la méthode go(), qui permet au présenteur de s'afficher
    • la classe Placer est une abstraction d'un Panel GWT, pour être complètement indépendant de GWT, cette interface possède une simple méthode setView qui prend en paramètre un DisplayView. L'interface DisplayView qui doit être étendu par toutes les vues demande juste d'implémenter la méthode asWidget() qui permet de retourner la vue (this) en tant que Widget GWT.

Créons maintenant la vue, en utilisant UiBinder :

public class TestView extends Composite implements TestPresenter.Display {

    private static TestViewUiBinder uiBinder = GWT
            .create(TestViewUiBinder.class);

    interface TestViewUiBinder extends
        UiBinder<Widget, TestView> {}

    @UiField Label label;
   
    public TestView() {
        initWidget(uiBinder.createAndBindUi(this));
    }

    @Override
    public HasClickHandlers getUserNameClickHandler() {
        return label;
    }

    @Override
    public void setUserName(String username) {
        label.setText(username);
    }

    @Override
    public Widget asWidget() {
        return this;
    }
}

Avec le fichier TestView.ui.xml associé :

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
    xmlns:g="urn:import:com.google.gwt.user.client.ui">
    <g:Label ui:field="label" />
</ui:UiBinder>

Cette classe étend donc notre Display du présenteur et accède aux composant GWT.

On peux ainsi tester facilement le code de notre présenteur car il ne possède aucune adhérence à GWT.

Nous avons choisi dans un premier temps de se passer de ces framework et d’appliquer les pattern MVP en suivant uniquement les pratiques conseillées par Google. Maintenant que nous avons une première expérience avec le développement MVP, nous pouvons penser à utiliser un de ces framework pour bénéficier de leurs utilitaires comme la gestion de l’historique, du pattern action etc. Si nous devions en choisir un à ce jour, ce serait gwt-platform qui est issu de gwt-presenter et gwt-dispatch.

lundi 24 janvier 2011

Retour d'expérience d'un projet GWT : 4 Architecture Modèle-Vue-Presenteur (4/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

Le MVP ou modèle vue présenteur est un modèle de conception qui a les objectifs suivants:

  • Découplage : le découpage en couche permet de construire des applications modulaires compatibles avec les contraintes de dépendances du chargement à la demande
  • Testabilité : Chaque classe destinée a être testée out-of-the-box possède une interface qui permettra de bouchonner certains comportements.
  • Optimisation des appels de service
  • Centralisation des erreurs
  • Gestion de l'historique
  • Anticipation, sur les évolutions du web comme HTML5...

Les 3 concepts du MVP sont :

  • Le modèle, les données de l'application, souvent issues de la base de données, il est destiné à être manipulé par l'UI. Il n'a pas d'adhérence avec les autres classes MVP, il est isolé.
  • La vue, la partie de la page web affichée dans l'interface utilisateur, qui se compose des widgets et des conteneurs de widgets.
  • Le présenteur, le controleur du pattern MVC sauf qu'il rend totalement étanche les échanges entre la vue et le modèle (alors que MVC permet à la vue de référencer directement ses modèles). Il porte leur le comportement de l'application.

MVP

La vue est passive et c'est le présenteur qui s'occupe des traitements et de la logique évenementielle. La vue et le présenteur partagent un contrat grâce à une interface. Pour que le contrôleur puisse être correctement tester avec JUnit sans utiliser la version de GWT qui utilise HtmlUnit pour lancer les tests, il faut que le contrôleur ne possède que du code Java hors code GWT (composant GWT, GWT.create(), Internationalisation ...).

Le MVP s'appuie sur plusieurs briques dont certaines sont facultatives :

  • Un gestionnaire d'évènement ou EventBus qui a pour but de découpler les différentes couches qui communiquent par l'émission d'évènements.
  • Un moteur d'IOC pour faciliter la création et la liaison des différents object. (facultatif)
  • Le pattern action pour simplifier les appels de services et offrir une meilleur testabilité. (facultatif)

Pour comprendre au mieux, le fonctionnement concret du modèle de conception MVP, il faut lire les 2 articles de Google suivants :

Un projet d'exemple est proposé par Google

Schéma de fonctionnement de GWT avec MVP sans UiBinder:

MVP ss UiBinder

Schéma de fonctionnement de GWT avec MVP avec UiBinder:

MVP avec UiBinder

Il existe également d'autres articles expliquant le fonctionnement de MVP :

Il existe un projet d'exemple illustrant le fonctionnement du MVP : http://code.google.com/p/gwt-mvp-sa...

Dans le livre "la programmation GWT2" de Sami Jaber, un article détaille le fonctionnement de MVP en s'appuyant sur une framework existant : http://code.google.com/p/gwt-presenter/

Il existe de nombreux framework MVP pour GWT comme gwt-presenter, gwt-platform ou mvp4g.

Dans GWT 2.1, GWT a introduit un framework MVP, cependant celui-ci décrit le principe.

lundi 3 janvier 2011

Retour d'expérience d'un projet GWT : 3 Intégration facile de maquette Html en GWT 2 (3/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

Exemple d'intégration d'un composant d'une page Web dans un projet GWT 2:

Nous devons intégrer un nouveau composant qui nous est livré sous la forme de maquette HTML qui se compose de fichiers HTML, d'image et éventuellement de fichier CSS.

Voici le fichier HTML fourni, il contient le code HTML et le style CSS utilisé:

<style>
<!--

* {
    font-family:calibri;
    font-size:12px;
}

.menu {
    padding: 0px;
    background: url('bgmenu.gif') repeat-y right top white;
    display:block;
    color:#1783c4;
    width:250px;
    height:100%;
}

.menu h2{
    font-family:calibri;
    font-size:18px;
    background: url('menutop.gif') no-repeat bottom left;
    width:250px;
    padding-bottom:10px;
    margin:0px;
}

.menu .close{
    float:right;
    margin:4px;
    margin-right:7px;
}

.menu textarea {
    width:240px;
    min-height:300px;
    border:1px solid #dddddd;
    background: #f6f6f6;
    margin-top:20px;
    margin-bottom:5px;
}

.pages{
    padding:3px 7px 7px 7px;
}

.pages.selected{
     background: url('menubottom.gif') no-repeat bottom left #f5f5f5;
}

.pages .close{
    float:right;
}

.pages a.element{
    color:black;
    font-size:13px;
    font-weight:bold;
    margin-bottom:3px;
    text-decoration:none;
    display:block;
}

.pages a.element:hover{
    text-decoration:underline;
    background:url('croixnoire.gif') 223px 3px no-repeat;
}

.pages .close{
    float:right;
    width:13px;
    height:11px;
}

.right {float:right;}

a.bouton {
    color:white;
    font-size:12px;
    font-weight:bold;
    text-transform:uppercase;
    margin-right:10px;
    padding:2px 5px;
    text-decoration:none;
    font-family:calibri;
    border:1px solid #909090;
    text-align:center;
}

a.bouton.bleu {
    background:#0099cb;
}

a.bouton.bleu:hover {
    background:#0fb3e9;
}

a.bouton.vert {
    background:#4ba600;
}

a.bouton.vert:hover {
    background:#5cc803;
}
-->
</style>
<div class="menu">
      <div class="close"><a href="#"><img src="croix.gif" border="0"></a></div>
     <h2>Jean-Pierre Dupont</h2>   
     <div class="pages selected">
       <a href="#" class="element"><img src="1ptrans.gif" border="0" class="close">Ma page personnel (0)</a>
      </div>
     <div class="pages">
        <a href="#" class="element"><img src="1ptrans.gif" border="0" class="close">Autre page (0)</a>
     </div>
    <br/>
     <a href="#" class="bouton bleu">Créer une nouvelle page</a>
     <textarea>
     Ici je peux mettre des notes
     </textarea>
     <a href="#" class="bouton vert right">Enregistrement</a>
</div>

Nous créons un nouvel élément UiBinder que nous appelons HomePageMenu :

UIBinder create

On modifie le fichier HomePageMenu.gwt.xml comme suit:

  • On ajoute les entêtes nécessaires pour UiBinder
  • On modifie la balise <style /> en <ui:style />
  • On remplace la div principale par une balise <g:HTMLPanel />
  • Les libellés que l’on souhaite rendre dynamiques sont remplacés par des balises <g:InlineLabel />, les liens <a /> par des <g:Anchor /> et les <textarea /> par des <g:TextArea />
  • Les nom des styles utilisés sont modifiés, en lieu et place de “monStyle” on utilise "{style.monStyle}"
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
     xmlns:g="urn:import:com.google.gwt.user.client.ui">
     <ui:style>
        * {
            font-family: calibri;
               font-size: 12px;
        }
       
        .menu {
               padding: 0px;
            display: block;
             color: #1783c4;
            width: 250px;
            height: 100%;
        }
       
        .menu h2 {
            font-family: calibri;
            font-size: 18px;
            background: url('module/images/homepage/menutop.gif')
                 no-repeat bottom left;
            width: 250px;
             padding-bottom: 10px;
            margin: 0px;
        }
      
        .menu .close {
            float: right;
             margin: 4px;
            margin-right: 7px;
        }
        
        .menu textarea {
            width: 240px;
                min-height: 300px;
            border: 1px solid #dddddd;
               background: #f6f6f6;
            margin-top: 20px;
             margin-bottom: 5px;
        }
       
        .pages {
               padding: 3px 7px 7px 7px;
        }
       
         .pages.selected {
            background: url('module/images/homepage/menubottom.gif')
                 no-repeat bottom left #f5f5f5;
        }
       
         .pages .close {
            float: right;
        }
       
        .pages a.element {
            color: black;
            font-size: 13px;
            font-weight: bold;
            margin-bottom: 3px;
            text-decoration: none;
             display: block;
        }
       
        .pages a.element:hover {
            text-decoration: underline;
             background: url('module/images/homepage/croixnoire.gif') 223px
                3px no-repeat;
        }
       
         .pages .close {
            float: right;
            width: 13px;
            height: 11px;
        }
       
         .right {
            float: right;
        }
       
         a.bouton {
            color: white;
            font-size: 12px;
            font-weight: bold;
            text-transform: uppercase;
            margin-right: 10px;
            padding: 2px 5px;
            text-decoration: none;
            font-family: calibri;
            border: 1px solid #909090;
             text-align: center;
        }
       
         a.bouton.bleu {
            background: #0099cb;
        }
        
        a.bouton.bleu:hover {
            background: #0fb3e9;
        }
       
        a.bouton.vert {
             background: #4ba600;
        }
       
         a.bouton.vert:hover {
            background: #5cc803;
        }
    </ui:style>
    <g:HTMLPanel styleName="{style.menu}">
       <div class="{style.close}">
            <a href="#">
               <img src="module/images/homepage/croix.gif" border="0" />
            </a>
        </div>
       <h2><g:InlineLabel  ui:field="userLabel">Jean-Pierre Dupont</g:InlineLabel></h2>
        <div class="{style.pages} {style.selected}">
            <a href="#" class="{style.element}">
                <img src="module/images/homepage/1ptrans.gif" border="0"
                    class="{style.close}" />
                Ma page personnel(0)
            </a>
        </div>
         <div class="{style.pages}">
            <a href="#" class="{style.element}">
                <img src="module/images/homepage/1ptrans.gif" border="0"
                    class="{style.close}" />
                Autre page (0)
            </a>
        </div>
        <br />
        <g:Anchor ui:field="newButton" href="#" styleName="{style.bouton} {style.bleu}">
            Créer une nouvelle page
        </g:Anchor>
         <g:TextArea ui:field="noteTextArea">
            Ici je peux mettre des notes
         </g:TextArea>

        <g:Anchor ui:field="saveNoteButton" href="#" styleName="{style.bouton} {style.vert} {style.right}">
            Enregistrer
        </g:Anchor>
     </g:HTMLPanel>
</ui:UiBinder>


Puis on modifie la classe associée de la manière suivante:
/**
*
*/
package module.client.homepage.menu;

import com.google.gwt.core.client.GWT;
import com.google.gwt.uibinder.client.UiBinder;
import com.google.gwt.user.client.ui.Composite;
import com.google.gwt.user.client.ui.Widget;

/**
*
*
*/
public class HomePageMenu extends Composite {

    private static HomePageMenuUiBinder uiBinder = GWT
             .create(HomePageMenuUiBinder.class);

    interface HomePageMenuUiBinder extends UiBinder<Widget, HomePageMenu> {
    }

    //Composant GWT que l'on veux utiliser lié avec l'attribut ui:field=""
    @UiField InlineLabel userLabel;
    @UiField Anchor newButton;
    @UiField TextArea noteTextArea;
    @UiField Anchor saveNoteButton;

    public HomePageMenu() {
         initWidget(uiBinder.createAndBindUi(this));
    }

    @UiHandler("newButton")
    public void onNewClick(ClickEvent event){
        //Création d'une nouvelle page
    }
   
    @UiHandler("saveNoteButton")
    public void onNewClick(ClickEvent event){
        saveNote(noteTextArea.getText());
    }

    public void setUserName(String userName){
        userLabel.setText(userName);
    }

}

Comme on a pu le voir, il est très simple d’intégrer des maquettes HTML/CSS en GWT abec UiBinder, ce qui n’était pas le cas avant la version 2 de GWT. Cela permet d’améliorer la collaboration entre le Web Designer et le développeur puisqu’ils utilisent un langage commun le XML/HTML pour réaliser les écrans. Cela permet également au Web Designer, après une rapide prise en main des outils type SVN/Eclipse, de pouvoir intervenir sur le design de l’application directement sans aucune aide du développeur.

Dans notre cas, on a eu l’agréable surprise de voir notre Web Designer créer des écrans GWT lui même, les modifier et même coder en java pour interagir avec l’IHM; modifier un style programmatiquement ou déclencher une action simple.

mercredi 15 décembre 2010

gwt-table-to-excel

Présentation d’un nouveau projet Open Source.

Lire la suite...

mercredi 24 novembre 2010

"Innovation Web", la conférence qui monte (16 décembre)





L'association GET
 (G-EFREI Technologies) organise sa conférence pour la troisième année consécutive. 
Celle-ci se tiendra le 16 décembre prochain à l'EFREI.




Pour avoir une description détaillée de l'évenement vous pouvez vous rendre directement sur le site de l'association, dans la section conférence.

En cette journée du 16 décembre, vont se regrouper professionnels et étudiants qui partagent tous la même passion pour les technologies web et les outils de Google. 

Les portes sont ouvertes à tous, gratuitement, dans la limite des places disponibles (≈ 300) et sous condition d'être inscrit sur le formulaire : conf.g-e-t.fr.

Les thèmes & intervenants

  • Android et son avenir par Cyril MOTTIER, Créateur de GreenDroid

  • GWT 2.1 et mobilité par Salvador DIAZ, Développeur GWT chez SFEIR

  • Cloud computing et la monétisation par Didier GIRARD, Directeur Technique de SFEIR

Après la conférence, venez discuter et échanger autour d’un verre lors du cocktail organisé par GET.

Ateliers Android

Deux ateliers Android sont prévus après la conférence aux alentours de 18h, avec notamment Julien Del Rio de Frandroid, Stéphane Guérin, créateur de Appoke et toujours Cyril Mottier. 
Un atelier sera organisé pour les débutants et un autre pour les développeurs confirmés.

Pour plus d’infos : www.g-e-t.fr

Infos pratiques

  • Lieu : EFREI, 30-32 avenue de la république 94800 Villejuif

  • Métro : Villejuif Louis Aragon Ligne 7 (Terminus)

  • Début de la conférence : 13h30

  • Début des ateliers : 18h

  • Inscription gratuite et obligatoire : conf.g-e-t.fr

  • http://www.g-e-t.fr

lundi 8 novembre 2010

Retour d'expérience d'un projet GWT : 2 UiBinder, enfin une forte collaboration entre le designer et le développeur (2/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

UiBinder, enfin une forte collaboration entre le designer et le développeur

Dans la version 2 de GWT, Google propose aux développeurs de choisir comment coder les écrans, soit en Java uniquement comme c'était le cas jusqu'à présent soit en utilisant une nouvelle fonctionnalité UiBinder, qui permet de coder les écrans en XML, très proche du HTML.

UiBinder permet d'écrire les interfaces graphiques avec un formalisme XML un peu comme on peut le faire avec JSF, Flex, Silverlight ou encore en HTML. Jusque-là, la création d'interface en GWT se faisait en manipulant du code java à la façon native de Swing ou SWT/JFace. On va maintenant pouvoir les écrire en XML et les lier (les binder) avec une classe java qui contiendra le code de notre vue. Le code en sera d'autant plus lisible, maintenable et plus rapide à développer. Cette évolution va permettre également la multiplication d'outils puissants, comme les éditeurs d'interfaces GWT, plus simples à créer, comme GWTDesigner d'Instantiations, qui a été acheté par Google et qui est maintenant disponible gratuitement: http://code.google.com/intl/fr/webtoolkit/tools/download-gwtdesigner.html

Cette nouvelle organisation, sépare la partie présentation (l'écran) de la partie contrôle (le code java). On écrit un fichier XML contenant nos widgets graphiques, puis on les associe avec les objets dans notre classe java où l'on ajoute aussi les évènements de l'IHM. Il est également possible d'écrire notre interface en HTML en y incorporant nos widgets HTML. Le CSS peut se trouver directement dans le fichier d'interface ou dans un ClientBunddle (système GWT2 de gestion des ressources type CSS en java qui sera détaillé ci-dessous).

Prenons une classe Miniature.java, qui permet d'afficher une image et son titre, pour utiliser UIBinder. Commençons par créer le fichier xml :

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:gwt='urn:import:com.google.gwt.user.client.ui'>
<ui:style>
   .mini {
    float : left;
    margin: 20px;
    height: 150px;
    width: 150px;
   }
</ui:style>
   <gwt:VerticalPanel styleName="{style.mini}">
        <gwt:Image ui:field="miniature" />
       <gwt:Label ui:field="label"/>
   </gwt:VerticalPanel>
</ui:UiBinder>

Nous voyons ici, que la racine du XML, ui:UiBinder permet de configurer les namespaces pour utiliser les composants, le namespace "ui" contient les configurations du UiBinder, tandis que le namespace "gwt" permet d'utiliser les composants de base de GWT. La balise <ui:Style> permet d'insérer le CSS utilisé par notre composant. Dans la suite du fichier, on peut accéder à la classe CSS en utilisant la syntaxe {style.nomClasse}. Nous voyons ensuite que le composant GWT racine est le VerticalPanel qui contient une Image et un Label. Pour les composants Image et Label, on a ajouté un attribut ui:field associé à un nom de paramètre, ce qui nous permettra d'accéder au composant depuis notre classe Java.

Voyons maintenant la classe Java associée :

public class Miniature extends Composite {
    interface Binder extends UiBinder<Widget, Miniature> { }

    private static final Binder binder = GWT.create(Binder.class);
    @UiField Image miniature;
    @UiField Label label;
    private String destination;

    public Miniature(String url, String titre, String destination) {
        this.destination = destination;
        initWidget(binder.createAndBindUi(this));
        miniature.setUrl(url);
        label.setText(titre);
    }

    @UiHandler("miniature")
    public void onClick(ClickEvent event) {
        Window.open(destination, "Image", "width=200, height=100");
    }
}

L'interface Binder étend UiBinder qui prend deux paramètres de type, le composant de base de notre interface (VerticalPanel dans notre cas, mais nous utilisons une super classe), et la classe qui va contenir les composants reliés (La classe actuel). Nous créons ensuite, en variable static, une instance de cette interface en utilisant GWT.create(); C'est le compilateur de GWT qui s'occupera d'implémenter cette classe en utilisant les informations du fichier XML.

Puis nous ajoutons les champs de notre interface en utilisant l'annotation @UiField pour indiquer à GWT qu'il faut relier ces champs avec les composants GWT définis dans le fichier XML. Le nom du champ doit être celui donné dans l'attribut ui:field. Dans notre constructeur, nous appelons la methode createAndBindUi sur notre interface Binder, qui va alors créer et relier les composants GWT à notre classe. Enfin, la methode onClick, appelée lors du clic sur l'image, est reliée à notre composant miniature grâce à l'annotation @UiHandler("miniature").

UiBinder permet aussi de créer une interface en HTML et d'y intégrer nos composants GWT sans passer par les traditionnels composants Panel de GWT (VerticalPanel, Grid, ...), tout simplement en utilisant le composant HTMLPanel. Utilisons ce procédé pour refaire le formulaire de recherche :

<?xml version="1.0" encoding="UTF-8"?>
<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:gwt='urn:import:com.google.gwt.user.client.ui'>
    <ui:style>
        .label {
            float: left;
            width: 50px;
            clear: both;
        }
        .element {
            float: left;
            width: 250px;
        }
</ui:style>
    <gwt:HTMLPanel>
        <dl>
            <dt class='{style.label}'>
                <ui:msg>Topic :</ui:msg>
            </dt>
            <dd class='{style.element}'>
                <gwt:TextBox ui:field="saisieSujet" />
            </dd>
            <dt class='{style.label}'>
            </dt>
            <dd class='{style.element}'>
                <gwt:Button ui:field="boutonAjouter">
                    <ui:msg>Search</ui:msg>
                </gwt:Button>
            </dd>
        </dl>
    </gwt:HTMLPanel>
</ui:UiBinder>

Ici, la classe Java est sensiblement équivalente à la classe Miniature.java :

public class FormulaireRecherche extends DialogBox {
    interface Binder extends UiBinder<Widget, FormulaireRecherche> {}
    private static final Binder binder = GWT.create(Binder.class);

    @UiField Button boutonAjouter;
    @UiField TextBox saisieSujet;

    public FormulaireRecherche() {
        super(true);
        add(binder.createAndBindUi(this));
        center();
    }

    @UiHandler("boutonAjouter")
    public void onClick(ClickEvent event) {
        hide();
    }
}

Références :

lundi 25 octobre 2010

Retour d'expérience d'un projet GWT : 1 Nouveautés de GWT 2.0 (1/8)

Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

  1. Nouveautés de GWT 2.0
  2. UiBinder, enfin une forte collaboration entre le designer et le développeur
  3. Intégration facile de maquette Html en GWT 2
  4. Architecture Modèle-Vue-Presenteur
  5. Implémentation Modèle-Vue-Présenteur
  6. Ecrire des tests unitaires avec Mockito
  7. Mise en place de Gin sur le projet
  8. Internationalisation

1 Nouveautés de GWT 2.0

Development Mode (anciennement OOPHM : "Out Of Process Hosted Mode")

GWT 2.0 apporte une nouvelle approche du développement des applications GWT en permettant de débugguer le code java et de voir le résultat directement dans les navigateurs sans passer par un navigateur spécifique, anciennement via le HostedMode qui utilisait son propre Navigateur différent selon le système d'exploitation. On assiste ainsi à un changement de terminologies puisqu'il ne faut plus parler de "hosted mode", qui portait souvent à confusion, mais de "development mode". Et pour la même raison on parle maintenant de "production mode" au lieu de "web mode", pour parler du script compilé.

On peut ainsi utiliser les outils du navigateur pour développer comme par exemple firebug sans devoir recompiler en permanence toute l'application. Pour utiliser ce mode, il suffira de copier/coller l'url qui est donnée par GWT lors du démarrage du server dans le navigateur, par exemple: "http://localhost:8080/Tutoriel.html?gwt.hosted=X.X.X.X:NNNN", où les X représentent l'adresse IP de votre ordinateur et les N le port utilisé par GWT.

Le development mode a été pour nous un facteur de gain de productivité important par rapport au hosted mode car grace à cette fonctionnalité il est possible de tester directement l’application dans les navigateurs cibles. On regrettera simplement que cette fonctionnalité ne soit pas disponible dans Chromium, le projet open-source de Google Chrome sur Linux. Layout

La notion de Layout permet d'avoir des composants génériques pour gérer la disposition des widgets. Ces layouts utilisent des panels déjà existant mais uniformisent leur utilisations. De plus, ces layouts se redimensionnent automatiquement en réorganisant plus précisément les widgets. Le rendu a été amélioré pour s'afficher plus rapidement et le redimensionnement peut être animé. A la différences des anciens panels de GWT qui utilisent massivement les tableaux pour afficher les widgets, les nouveaux layouts utilisent uniquement le CSS. Il existe par exemple le StackLayoutPanel, le TabLayoutPanel ou le DockLayoutPanel qui permettent d'avoir un contenu principal (Center) et d'ajouter des contenus au Nord, au Sud, à l'Ouest et à l'Est autour de celui-ci.

Nous avons utilisé ces Layout dans l’application très simplement et notre Web Designer a été particulièrement content de voir le rendu HTML/CSS généré s’améliorer en les utilisant, ce qui a faciliter son travail.

RPC (Remote Precedure Call)

Le système de service distant a été refondu pour gagner en performance et permettre l'ajout de nouvelles fonctionnalités. Pour le développeur, le principe de fonctionnement ne change pas. Il suffit d'ajouter dans le fichier Tutoriel.gwt.xml la ligne <inherits name='com.google.gwt.rpc.RPC' /> et de changer l'interface RemoteService par RpcService ainsi que la classe RemoteServiceServlet par RpcServlet. Cependant, cette fonctionnalité n'est pas, pour l'instant, compatible avec Google App Engine.

ClientBundle

On avait vu que GWT dans ses versions précédantes était capable de réunir plusieurs images en une seule, GWT 2.0 va encore plus loin car il est maintenant capable de réunir différents types de ressources (Images, Texte, Css, Données, etc...) en même temps. Toutes les ressources sont intégrées dans un même bundle encodé en base 64. Rappelons ainsi l'avantage de ce concept: un seul fichier à télécharger, donc, moins de requêtes HTTP et un temps de chargement de la page plus rapide.

Code splitting

Tout le code javascript est compilé en un seul fichier, téléchargé au chargement de la page. Dans le cas de très grosses applications, la taille de celui-ci peut considérablement devenir très importante et ralentir, de ce fait, le temps de chargement de l'application au démarrage. Pour pallier à ce problème, GWT 2.0 offre maintenant la possibilité de couper notre application en plusieurs fichiers qui seront téléchargés quand ceux-ci seront nécessaires. Par exemple, si une partie du code est utilisé uniquement lors du déclenchement d'un événement, son téléchargement n'est pas forcément essentiel lors du premier chargement de l'application. Par ailleurs l'utilisation est très simple:

GWT.runAsync(new RunAsyncCallback() {
    @Override
    public void onSuccess() {
        //Tout le code qui est ici, sera téléchargé plus tard.
    }

    @Override
    public void onFailure(Throwable reason) {
        //Si le téléchargement du nouveau code a échouée
    }
});

Mais attention, si le code, qui se trouve dans le onSuccess, est aussi utilisé par l'application dès son lancement, il sera téléchargé au début. C'est pourquoi GWT génère, tout de même, un rapport qui donne toutes les informations de compilation, informations que l'on peut analyser pour optimiser son application.

De plus, il est important de prévenir l'utilisateur du chargement par une barre de progression, ou par une icône de préchargement, car le changement n'est pas forcement immédiat et peut influer sur l'utilisabilité de l'application. Pour utiliser cette fonctionnalité, ajoutez "-compileReport" dans les paramètres avancés du compilateur GWT. Les rapports de compilation sont alors générés dans le répertoire extras/[moduleName]/soycReport/compileReport/.

Nous avons utilisé cette fonctionnalité pour charger à la demande les écrans principaux de l’application. Nous avons constater que la taille globale des fichiers javascript générés a sensiblement augmentée suite a la mise en place du Code Splitting. Il faut noter que l’utilisation de cette fonctionnalité sur 12 permutations a nécessité dans notre cas d’augmenter la partition /tmp utilisée pour compiler l’application (4Go ne suffisait pas).

mercredi 29 septembre 2010

Code Konami en GWT

Connaissez vous le code Konami ?
Il s'agit d'un code spécial utilisé dans de nombreux jeux de l'éditeur de jeux video Konami. Pour accéder à des options secrètes, il fallait effectuer la séquence suivante sur sa manette : haut, haut, bas, bas, gauche, droite, gauche, droite, b, a. Pour plus d'infos, je vous laisse lire l'article wikipedia.
Vous ne voyez pas le rapport avec GWT ? J'y viens... Certains développeurs web ayant été bercé par ces jeux dans leur enfance ont eu l'idée d'incoporer ce code dans leur site. C'est ainsi que nous les retrouvons sur certains sites que vous connaissez : free.fr, Google Reader, JQuery, ... (essayez, vous verrez) Parmis eux on retrouve bien sûr http://konamicodesites.com où l'execution de ce code est indispensable pour accéder à son contenu.
Pour déctecter l'exécution de ce code, il faut donc surveiller quelles sont les touches appuyées. C'est en javascript que celà se fait. Nous y voilà, personnellement, je préfère l'utilisation de gwt à celle de javascript. Je vous propose de voir comment nous pourrions l'implémenter. Lorsque l'utilisateur va effectuer la séquence de touches, une action devra être déclenchées. C'est le principe d'un handler. Nous aurons donc une interface de ce type :



Ensuite on va devoir surveiller les touches au niveau de la plage. Le principal problème est qu'il n'existe pas de de handler à rattacher au niveau de la page. comme on peut On en trouver sur un TextBox. On va donc s'intéresser aux évènements natifs du navigateur, les NativePreviewEvent. Pour cela, nous allons implémenter l'interface NativePreviewHandler. Celle ci, va réagir à l'ensemble des événements navigateur : aussi bien les touches clavier et la souris, mais aussi tous les évènements comme le onload, onblur, onchange, ... D'autre part, nous allons devoir si les dernières appuyées pressées correspondent à la séquence. Pour celà, nous allons enregister les dernières saisies sous forme de chaine ascii, la comparer à la séquence voulue et si elle est bonne appeler la méthode de notre handler. Ce qui nous donne : 


Il ne nous reste plus qu'à l'appeler dans depuis où vous voulez dans votre projet gwt en faisant par exemple : 
Bien sûr, cette action n'est pas du tout évoluée, c'est à vous de libérer votre imagination.
Je vous propose cette implémentation avec konami-gwt. Si vous souhaitez l'utiliser dans votre projet gwt, il vous suffit de déclarer son module dans votre fichier *.gwt.xml.

samedi 18 septembre 2010

Mvp avec mvp4g

Depuis la conférence Google I/O 2009, le pattern architectural MVP fait parler de lui à un point où un grand nombre de framework open source s’est répandu, chacun proposant son implémentation plus ou moins élaborée. Tous contiennent au moins la gestion du présenteur et ensuite on y trouve ou non un event bus, une gestion de l’historique, injection de dépendances, pattern action, ....

C’est sur google code que j’ai découvert Mvp4g  qui couvre une bonne partie de ses fonctionnalités.

Pour vous le faire découvrir, nous allons reprendre le code de l’application de gestion de contacts de l’article de google sur le mvp : http://code.google.com/intl/fr/webtoolkit/articles/mvp-architecture.html

Pour cet exercice, nous prendrons la dernière version de mvp4g qui vient l’être releasée ainsi que de ses dépendances :

  • mvp4g-1.2.0

  • commons-lang 2.4

  • commons-configuration 1.6

  • gin 1.0

  • guice 2.0

  • aop-alliance.

Comme pour n’importe quel bibliothèque gwt, il faut la déclarer dans notre fichier gwt.xml :


<inherits name='com.mvp4g.Mvp4gModule' />


Maintenant, faisons un tour d’horizon des modifications que nous allons devoir apporter :

  • La partie Model ne changera pas : Mvp4g ne couvrant pas l’Action pattern, nous ferons appel au méthodes exposée en rpc tout comme dans le code original.

  • La partie Presenter, elle sera une des parties qui changera le plus : nous devrons étendre une classe du framework et répondre à son contrat.

  • La partie View ne changera que très peu : nous n’aurons qu’à changer l’interface implémentée.

  • L’Event Bus : un des autres gros changement. Mvp4g propose en effet son propre modèle avec un système d’évènements haut niveau assez souple.

  • La gestion de l’historique, là aussi tout est à refaire.

  • L’Entry Point : Avec mvp4g, nous n’avons pas forcément besoin d’en écrire un ...

A cela, nous rajouterons une injection de dépendances via gin qui n’est pas dans le code original. C’est aussi dans cet esprit que se configure mvp4g. Que ce soit pour lier les différents composants ou spécifier le comportement dus bus ou de l’historique. Elle peut être soit réalisée en xml ou par annotations. J’ai préféré l’utilisation des annotations.

J’imagine que le point sur l’entry point, vous a laissé perplexe mais attention ce n’est pas parce que nous n’allons pas en écrire un que nous n’en aurons pas. C’est justement parce que l’application s’assemble en fonction des annotations que cette partie peut devenir générique. Nous utiliserons donc celui que nous propose mvp4g en incluant cette ligne dans le gwt.xml :


<entry-point class='com.mvp4g.client.Mvp4gEntryPoint' />


Pour les plus curieux, voici le code qui y correspond :


Mvp4gModule module = (Mvp4gModule)GWT.create( Mvp4gModule.class );

module.createAndStartModule();

RootPanel.get().add( (Widget)module.getStartView() );

Et c’est tout. Le code étant assez simple, il se comprend de lui même. Tant que nous n’aurons qu’un seul module gwt, il nous sera suffisant.

Passons maintenant au centre névralgique de notre application : le bus évènementiel. Dans une application mvp4g, il est indispensable. C’est bien sûr par lui va passer la distribution des événements haut niveau mais aussi quelques autres notions liées comme la gestion de l’historique et surtout l’action “start”.

A 3ème ligne de l’entry point, vous aviez sans doute remarque le getStartView. Il n’y a rien de magique, c’est par la configuration du bus que nous la connaîtrons.

Allez, mettons nous en route , pour coder notre bus. En fait, nous n’aurions rien à implémenter puisqu’il s’agit d’une interface. Elle devra néanmoins étendre l’interface EventBus de mvp4g et être annotée :


@Events( startView = RootView.class)

public interface   ContactsEventBus extends EventBus {

}


C’est sur l’annotation @Events que nous définissons RootView en tant que vue chargée s’affichant au démarrage. Fidèle à son nom, elle sera notre vue racine. Mvp4g conseille de disposer d’une telle vue qui servira de container aux autres vues. Comme toute vue dans un modèle MPV, elle sera statique et sera associée à un présenteur. L’interface qui servira de contart avec le présenteur sera celle ci :

public interface RootViewInterface {

     Panel getBody();

}

et l’implémentation sera la suivante :


public class RootView extends  Composite  implements  RootViewInterface {

private  SimplePanel body = new SimplePanel();

      public RootView() {

            VerticalPanel mainPanel = new VerticalPanel();

            mainPanel.add(body);

            initWidget(mainPanel);

      }

      @Override

      public Panel getBody() {

            return body;

      }

}


Le présenteur quant à lui sera de la forme suivante :


@Presenter( view = RootView.class )

public class RootPresenter  extends  BasePresenter<RootViewInterface, ContactsEventBus>


Là encore, nous avons du code assez simple à comprendre . Nous annotons le présenteur pour qu’il puisse être détecté par mvp4g et étendons la classe BasePresenter<V, E extends EventBus> pour nous permettre d’interagir avec la vue mais aussi avec notre bus. De la même manière, nous aurons : un ContactsPresenter et un EditContactPresenter avec des vue telle qu’on les a dans le code original.

Nous avons déjà la base de notre application mais pour l’instant, elle ne fait rien. Dans notre cas, nous voudrions qu’au lancement, la liste des contacts soit affiché. Tiens, nous tenons un évènement haut niveau et nous voudrions qu’il soit lancé au lancement... C’est encore une fois le bus qui va s’en occuper, encore un fois par une simple annotation.

Puisque nous voulons lister, nous allons créer un évènement “list” tout simplement. A la différence du mvp proposé par google dans l’article, nous n’aurons pas à créer une classe héritant de GwtEvent et de lui associer une handler. Nous allons seulement ajouter une méthode qui porte le nom de cet évènement à l’interface de notre bus :


@Start

@Event(handlers = ContactsPresenter.class)

void list();


C’est grâce à l’annotation @Start que l’évènement sera lancé au lancement client de l’application et sera délégué à notre ContactPresenter. A noter que dans notre cas, nous n’avons qu’un seul handler. Il aurait été tout à fait possible d’en avoir plusieurs en les séparant par une virgule.

Il nous reste à implémenter la réaction du présenteur face à cet évènement. Le modèle évènementiel de mvp4g repose sur une convention simple : pour un méthode XXX du bus, le présenteur devra implémenter une méthode onXXX tout simplement. Bien qu’il ne soit pas possible à s’assurer de la concordance entre l’évènement est sa méthode réceptrice lors de la compilation java, ce contrôle est réalisé lors de la phase de compilation gwt.

Revenons à notre cas, nous aurons donc une méthode onList() dans notre ContactsPresenter :


public void  onList(){

      contactsService.getContactDetails(newAsyncCallback<ArrayList<ContactDetails>>() {

            @Override

            public void  onSuccess(ArrayList<ContactDetails> result) {

                  doList(result);

            }

            @Override

            public void  onFailure(Throwable caught) {

                  eventBus.errorMessage(ErrorMessages.RPC_CALL_FAILED);

            }

      });

      eventBus.changeBody(view.asWidget());

}

Pour déclencher un évènement haut niveau, il suffit d’appeler la méthode associée du bus.C’est ce que nous faisons par exemple avec le changeBody qui permet à la vue ContactView de devenir active.

Nous pouvons aussi transmettre une valeur ou plusieurs valeurs lors du déclenchement de l’évènement. Nous rencontrons ce cas pour l’édition :


@Event(handlers = EditContactPresenter.class)

void  edit(String id);

Vous avez aussi sûrement remarqué, l’appel au service rpc. Sa déclaration est très simple, nous utiliserons l’injection GIN par une simple annotation sur son setter :


@Inject

public void setContactsService(ContactsServiceAsync contactsService) {

      this.contactsService = contactsService;

}

Quant à la phase de binding des événements bas niveau par les présenteurs, elle est est analogue à celle du code original : nous n’aurons qu’à implémenter la méthode bind().

Nous aurons par exemple :


view.getAddButton().addClickHandler(new ClickHandler() {

      public void  onClick(ClickEvent event) {

            eventBus.add();

      }

});

Si vous avez peur de ne pas savoir où vont vos évènements, l’annotation @Debug sur le bus vous aidera en loggant en console ce qui se passe autour du bus. Il existe 2 modes de LogLevel : SIMPLE et DETAILLED, par défaut ce sera la première valeur. Regardons ce qui se passe dans les 2 modes sur un évènement edit .

Tout d’abord en mode simple :

16:47:05.355 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: edit || param(s): 18

16:47:06.551 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: changeBody || param(s): [...plein de html...]

et en mode détaillé :

16:50:53.187 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: edit || param(s): 18

16:50:53.751 [INFO] [contactsmvp4g] com.sfeir.contacts.client.presenter.EditContactPresenter@640782 handles edit

16:50:54.052 [INFO] [contactsmvp4g] Module: Mvp4gModule || event: changeBody || param(s): [...plein de html...]

16:50:54.058 [INFO] [contactsmvp4g] com.sfeir.contacts.client.presenter.RootPresenter@16e4f00 handles changeBody

Intéressons nous maintenant à l’historique. Mvp4g utilise la notion de convertisseur d’historique. Ce qui signifie que nous devrons implémenter la façon dont les évènements seront convertis en url et vice et versa. Nous allons devoir implémenter l’interface HistoryConverter<E extends EventBus> et comme toujours l’annoter. Notre application étant relativement simple, nous n’en aurons qu’un seul mais sachez qu’il est tout à faire possible d’en avoir plusieurs. Pour répondre à son contrat, nous devrons implémenter les 2 méthodes suivantes :

  • convertFromToken( String eventType, String param, E eventBus ) : réaction lors d’une url tokenisée.
  • isCrawlable() : indique si le l’url sera crawlable en renvoyant un booléen.

La gestion de l’historique viendra se greffer sur le bus événementiel. Pour gérer l’historique, nous rajouterons :


@Events( startView = RootView.class, historyOnStart = true)


Réfléchissons d’abord un peu. Sur quoi aimerions nous avoir une historique avec des urls identifiables ? J’en vois 3 :

  • La liste des contact

  • Ajout d’un contact

  • Edition d’un contact. Idéalement, il serait intéressant d’avoir un paramètre permettant d’identifier le contact que nous éditons.

Le modèle d’historique de mvp4g utilise un token situé après un "#" dans l’url. Ce token correspond tout simplement au nom de l’évènement. Nous avons aussi la possibilité d’assigner un valeur à ce dernière en le placant derrière un "?".

Exemple : #token?value

Cette solution convient à notre exigeance de mieux marquer l’url lors de l’édition d’un contact. Pour lier, un évènement à notre convertisseur d’historique, il suffit de lui assigner sur le bus :


@Start

@InitHistory

@Event(handlers = ContactsPresenter.class, historyConverter=ContactHistoryConverter.class)

void  list();


L’annotation @InitHistory sert à marquer quand l’historique doit être initialisé. Celle est obligatoire si vous voulez utiliser l’historique. Revenons à notre convertisseur :


@History

public class  ContactHistoryConverter implements HistoryConverter<ContactsEventBus> {

      @Override

      public void convertFromToken(String  eventType, String param, ContactsEventBus eventBus) {

            if(“edit”.equals(eventType)){

                  eventBus.edit(param);

            } else if(“add”.ADD.equals(eventType)){

                  eventBus.add();

            } else if(“list”.equals(eventType)){

                  eventBus.list();

            }

      }

      @Override

      public boolean isCrawlable() {

            return  true;

      }

}


La première méthode est assez claire : nous appelons la méthode correspondante au token avec une particularité pour edit où nous nous servirons de la valeur en paramètre du token comme paramètre edit.

Même si l’IDE ne signale aucune erreur, la compilation gwt en provoquera. Il nous faut la réciproque de la méthode convertFromToken : c’est à dire indiquer quelle sera la valeur du paramètre d’un token. Ainsi, pour chaque évènement XXX historisé,il nous faudra une méthode onXXX qui renvoi une valeur sous forme de chaîne de caractères. Nous aurons ainsi par exemple :


public String  onEdit(String id){

      return id;

}

public String  onList(){

      return "";

}


Un reproche possible à faire à mvp4g est

Un des reproches possible à faire est l’assemble dynamique et instanciation des composants. Nous n’avons pas toujours besoin d’en disposer au moment au l’ont accède à l’application. Dans notre cas, nous n’avons pas besoin d’édition d’un contact tant que n’a pas cliqué sur un contact. Rassurez vous, la construction paresseuse est là. Pour cela, nous allons changer la super classe pour LazyPresenter<V extends LazyView, E extends EventBus>. En plus de cela, notre interface de vue devra étendre l’interface LazyView. Cela va perturber un peu notre code et des erreurs de compilation vont s’inviter. Avant de les corriger, intéressons nous à la classe LazyPresenter et en particulier sa méthode bind()


final public void bind() {

      view.createView();

      createPresenter();

      bindView();

}


Voilà la clé de nos corrections :

  • Les constucteurs de vue et de présenteur deviendront respectivement createView() et createPresenter()

  • La méthode bind() du présenteur deviendra bindView()

Personnellement, j’ai remarqué qu’après ses modifications, le lancement était plus rapide.

Le principal avantage d’un découpage mvp est la testabilité. Notre présenteur étant décorélé de problématique d’affichage, il sera alors plus simple de le tester. En effet, en mockant la vue, les services et le bus, nous pourrons nous concentrer nos tests sur la logique métier. De plus avec le système évènementiel haut niveau de mvp4g, il est simple de tester la réception d’un événement.

Un aspect qui peu rebuter les plus intégriste du modèle mvp est la gestion évènement de haut niveau spécifique de mvp4g et principalement ses performances. Quelles sont elles ? Le wiki du projet répond à cette question :

http://code.google.com/p/mvp4g/wiki/Mvp4gPerformances

Les performances semble honorables. Bien sûr, tout produit vante ses performances, mais bon joueur les tests sont disponibles.

La question à se poser avant tout est de savoir ce que l’on teste exactement. En observant le code, on voit qu’un évènement est lancé est attrapé par son réceptacle. Rien de plus. Pour éviter un conflit entre les deux, un test se fait en temps : d’abord mgp4g puis gwtEvent.

Pour la partie benchmarking, j’ai réalisé depuis le lien appspot les même tests sous 3 navigateurs dans leur version courante :

  • Chrome 6

  • Internet Explorer 8

  • Firefox 3.6

Mes résultats diffèrent, mais attention cela ne signifie pas les résultats sur la page mvp4g sont faux. En effet, pour avoir reproduit ces même tests sur différentes machines possédant le même navigateur, j’obtenais des résultats avec une différence assez importante (jusqu’à x 10 entre un bon pc fixe et un simple netbook) :

Voici mes résultats pour 1000 évènements lancé :



mvp4g

gwt

Chrome 6

31

122

Internet Explorer 8

477

3609

Firefox 3.6

206

312

Ces résultats vont dans le même sens, c’est à dire que le modèle événementiel de mvp4g est plus rapide que celui de gwt.

Bien sûr, GWT 2.1 va arriver avec son modèle MVP intégré. Quand il sortira, on pourra re-comparer les temps de réaction événementielle. En attendant, sa sortie vous pouvez vous amuser au mpv avec mpv4g, qui propose bien d’autres fonctionnalités encore comme les filtres d’évènements, la gestion du multi-module, ....


Le code source complet est joint à cet article.

lundi 13 septembre 2010

Faire une application JavaScript crawlable

Le problème des applications JavaScript est qu'elles ne sont pas crawlable, il est impossible pour un moteur de recherche d'avoir accès à toutes ses informations. Or les interfaces ajax se sont développé énormément depuis quelques années avec la mode du Web 2.0 et la technologie Ajax.

Google a fait une proposition et la mise en oeuvre dans son indexeur pour résoudre ce problème. Il en a parlé initialement sur le blog : http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html, un site dédié à cette technique est maintenant disponible : http://code.google.com/web/ajaxcrawling/

Nous allons développé cette technique dans cet article que nous venons de mettre en place sur le site mobile de SFEIR qui a été réalisé en GWT avec le framework Modding.

Principe d'utilisation

Google part du constat que s’il rencontre un lien contenant une ancre commençant par le signe "!", ce lien ajax doit être indexé. Il va alors rappeler la page en prenant le nom de l'ancre et en la passant en paramètre de la page _escaped_fragment_=

Seulement les liens avec une ancre commençant par un "!" seront indexé, cela permet de contrôler l'indexation et ne pas se retrouver avec tous le contenu de notre application indexé par Google.

Exemple :
monsite.com/page.html#!url_ajax
Deviendra :
monsite.com/page.html?_escaped_fragment_=url_ajax

La première URL est l'URL publique, ce que l'on doit mettre en lien depuis tous les sites où l'on veux avoir un lien, l'application JavaScript doit donc ouvrir automatiquement la page url_ajax dans l'application à son ouverture.

La deuxième URL est utilisé uniquement par Google, et ne doit pas être mis en lien, elle doit retourner la version HTML de la page, c'est à dire ce qu'on aurait si on exportait l'HTML généré par notre application JavaScript si on va sur la première URL. Il est donc nécessaire que le serveur analyse l'URL et si il détecte le paramètre _escaped_fragment_, le serveur génére la version HTML de la page.

Google indexera ainsi le contenus de cette page HTML, mais dans les résultats du moteur de recherche, il affichera la première URL à l'utilisateur.

Mise en place dans une application JavaScript


Pour cela, il faut commencer par modifier son application JavaScript pour utiliser la gestion de l'Historique :
Pour les projets GWT, une api permet de le faire simplement en utilisant History : http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsHistory.html

History.getToken(); //Permet de récupérer le token
History.addValueChangeHandler(new ValueChangeHandler<String>() {
public onValueChange(ValueChangeEvent<String> event) {
event.getValue();
//Permet de récupérer les changements du token
}
};
History.newToken("!url_ajax"); //Ajoute un nouveau token



Notre framework Modding depuis sa version 0.3 est maintenant capable de démarrer une autre activité que l'activité principale lors du chargement de la page avec l'information dans l'url :
http://m.sfeir.com/#!com.sfeir.client.activity.PageActivity?hash=4&url=page%252Fjava.html


Ce liens lancera directement la page "Notre savoir faire / Expertise Java" sans afficher le premier menu disponible normalement :
http://m.sfeir.com


Un autre projet créé par Alexandre Thiel également chez SFEIR, permet de créer une application GWT en utilisant la notation Rest : http://code.google.com/p/restful-gwt/

Mise en place sur le serveur de la version HTML

Il faut maintenant modifier le serveur pour détecter que Google demande la version HTML ou pas, pour cela il faut détecter si le paramètre _escaped_fragment_ existe bien.
http://m.sfeir.com/?_escaped_fragment_=com.sfeir.client.activity.PageActivity?hash=4%26url=page%252Fjava.html

Pour cela, on peux facilement le faire en utilisant un filtre, qui vous permettre de choisir entre afficher la page habituelle ou la version HTML.

Pour cela, il est nécessaire de renommer le fichier html en jsp car il n'est pas possible en Java d'ajouter un filtre sur une page HTML. Ensuite, la configuration du fichier de configuration est très simple dans le fichier web.xml, en ajoutant simplement les balises filter et filter-mapping :
  <filter>
<filter-name>crawler</filter-name>
<filter-class>com.sfeir.server.CrawlerFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>crawler</filter-name>
<url-pattern>*</url-pattern>
</filter-mapping>

Voyons maintenant le fonctionnement de la classe :




Le filtre pour chaque requête, vérifie si le paramètre _escaped_fragment est présent, sinon il lance la chaine suivante des filtres avec le chain.doFilter(request, response);

Dans le cas où la requête est une requête de google pour indexer la page Ajax, on reconstruit l'url originale avec l'ancre ajax.

Il reste donc à produire le code HTML, pour cela, il y a deux stratégies, soit en fonction de l'url, produire la page html en utilisant les technologies habituelles de java : jsp, spring, velocity, etc ...
Soit utiliser un navigateur internet léger comme HtmlUnit pour construire la page directement en utilisant l'application JavaScript.

La deuxième approche conseillée par Google a le mérite d'être simple à mettre en place car on utilise le code de notre application. Voici un exemple d'utilisation avec HTMLUnit :
WebClient webClient = new WebClient(BrowserVersion.FIREFOX_3);
webClient.setThrowExceptionOnScriptError(false);
webClient.setJavaScriptEnabled(true);
HtmlPage page = webClient.getPage(pageName);
webClient.setTimeout(10000);
out.println(page.asXml());
webClient.closeAllWindows();


Le timeout dépend de votre application, et du temps nécessaires pour que le code javascript s'exécute, que les services soient appeler, et que le rendu final soit fait !
Cela peux donc prendre du temps et des ressources.

Pour le site mobile de sfeir, nous avons utilisé la première approche, car le site est hébergé sur Google App Engine, et la bibliothèque n'est pour l'instant pas compatible avec App Engine, le portage est en cours. De plus, nous sommes limité par le temps d'exécution des pages à 30 secondes.
Comme le site mobile est statique, réaliser la version HTML était assez facile, simplement à lire les fichiers HTML normalement chargés par la partie GWT et les écrirent dans la réponse du serveur.

Testons l'indexation

Cette article explique le fonctionnement préconisé par Google pour rendre ses applications indexable, et plus particulièrement les application GWT en Java.
C'est pour Sfeir, l'occasion de mettre en pratique et de lancer un test grandeur nature de ce référencement.

Merci de nous y aider en ajoutant des liens depuis vos sites vers une page particulière de notre site mobile pour tester l'indexation dans Google.

Cette expérimentation nous permettra ensuite de valider la technologie pour l'utiliser chez nos clients et vos clients.

lundi 5 avril 2010

GWT token Gestion de l'historique

La Gestion de l'historique et la possibilité d'avoir des pages 'bookmarkable' est un plus de GWT.
Cela est rendu possible grâce à une chaîne de caractères nomée token, placée après un # dans l'url.
Exemple :
    http://www.google.com/moderator/#15/e=8ea&t=8ea.41&f=8ea.3070

Le token représente un état du client, il n'est jamais envoyé au serveur et son changement ne provoque pas de rafraichissement de la page ni appel au serveur.

Pourquoi c'est important ? 

Les utilisateurs internautes ont acquis des reflexes "web" et s'attendent donc à :
- pouvoir faire précédent et suivant
- créer un favori pour revenir au même endroit (ou dans le même état) ultérieurement

Pourquoi c'est (encore plus) important ? 

Parce que google nous prépare une technique d'indexation des pages dynamiques

Google fait ses essais avec le Showcase de GWT.
http://www.google.fr/search?q=gwt+showcase+radio+button

Vous remarquerez le !Cw

En pratique, cela revient à fournir 2 versions de la page, une en html+Javascript pour l'utilisateur , qui veut que ça aille vite, et une html pour le robot d'indexation, qui veut lire du html.
C'est un énorme enjeu pour Google, qui a proposé un outil qui lui a 'masqué' une partie du Web.
Cette lacune est sur le point d'être comblée.

Que propose GWT ?

Les classes de base sont :
History auquel on peut ajouter un ValueChangeHandler<String> pour être prévenu des changements de token.
Hyperlink qui est le widget de base qui permet de déclencher un changement de token sur un clic.

GWT vous permet de construire votre token comme vous le souhaitez et cela reste assez bas niveau : il se contente de fournir un String java, à vous de le découper.
On remarque cependant que beaucoup adoptent les mêmes syntaxes proches des urls en utilisant les séparateurs / ? et &

Pour plus de détails : 

Frameworks
Il existe donc plusieurs frameworks qui tentent de faciliter la gestion de ce token :

Restful-gwt

http://code.google.com/p/restful-gwt/
Ce projet utilise les annotations JAX-RS afin d'extraire et découper le token.
@GET
@Path("hello/{name}")
public void helloWithIntegerParam(@PathParam("name") Integer myName) {
   
Window.alert("Hello "+(myName+1));
}

Exemple

gwt-mvc

 http://code.google.com/p/gwt-mvc/
Ce projet reprend les conventions JSP.
Le token est ainsi découpé: #ACTION?param1=value1&param2=value2
content.clearAndAdd(pocViewNumeric);
Integer modelAParamValue = Integer.valueOf(getUrlParam("modelA"));
updateModel(modelA, modelAParamValue, event);


Exemple

vendredi 15 janvier 2010

Evénement : Conférence "Jump Camp 4 IT" jeudi 21 janvier à 19h

Jeudi prochain aura lieu le premier opus du Jump Camp 4 IT.

Alors Jump Camp 4 IT, c'est quoi ?

Jump Camp 4 IT est une mini conférence en soirée sur Paris mêlant présentations et ateliers de coding, destinés aux passionnés des technologies de l'information.
Ainsi, ce qui est intéressant dans ce format, c'est que cela vous permet de mettre un premier pied à l'étrier sur le framework présenté, et non pas juste d'écouter une présentation théorique. Il est donc conseillé de venir avec son ordinateur portable pour profiter pleinement des présentations ;)

Ah, et petit détail qui ravira tout le monde : c'est gratuit.

Le premier opus de la série aura lieu jeudi prochain, soit le 21 janvier, de 19h à 21h.
Au programme, 6 présentations/séances de coding live autour des dernières technologies/tendances web du moment :

  • Surprise... : une présentation/annonce surprise par Didier Girard
  • Atmosphere :  un framework permettant de faire des applications web asynchrones (Comet) à partir de simples POJO (https://atmosphere.dev.java.net)
  • HTML5 : découverte de html5 step by step
  • Robots Wave et le WadRobotFramework : un framework qui simplifie énormément la création de robots pour Google Wave (http://goo.gl/6pOC)
  • Sisyphe version GWT : une interface à refaire ? reprogrammer ? Non, utilisez dès maintenant sisyphe.
  •  gwt-mvc : Framework pour GWT permettant de structurer le code client en suivant le design pattern MVC (http://code.google.com/p/gwt-mvc/

Si vous souhaitez vous inscrire, connaître le lieu exact de la conférence, ou avoir plus de détails sur les présentations, c'est par ici.

lundi 23 novembre 2009

La conférence "Innovation WEB" fait son retour

Le 4 décembre 2008, l'association GET (Google EFREI Technologies) organisait en association avec SFEIR une conférence sur les technologies Google.

Fort de son succès, une deuxième édition est programmée pour le 11 décembre 2009.

Cette année, il sera question d'Android, de Google App Engine, de GWT, de Google Wave et des standards du WEB (HTML5, CSS3, SVG).

Les intervenants de cette année seront Ludovic Perrier, Didier Girard et Patrick Chanezon.

Les conférences se tiendront de 13h30 à 16h30 dans les locaux de l'EFREI.


A la fin de la conférence aura lieu un cocktail, ce dernier sera suivi d'un atelier de développement Android organisé en association avec le Paris GTUG.

Pour plus d'informations, rendez vous sur le site de l'association.

jeudi 1 octobre 2009

Accélérez vos applications GWT avec Google Chrome Frame

Il y a un peu plus d'une semaine, Google annonçait la sortie de Google Chrome Frame.
Vous en avez surement déjà  beaucoup entendu parler.

Pour rappel, il s'agit d'un plugin s'intégrant à Internet Explorer et permettant de bénéficier
du moteur de rendu de Google Chrome, lui même basé sur WebKit.

Chrome Frame ne vient pas complètement remplacer le moteur de rendu d'Internet Explorer, il ne prend la main que si l'utilisateur ou la page qu'il visite le demandent explicitement.



Si vous souhaitez spécifier que votre page doit être chargée par Chrome Frame, il vous suffit de rajouter la balise suivante :

<meta http-equiv="X-UA-Compatible" content="chrome=1">


Sur le plateau de développement où je suis actuellement en mission, nous développons des applications GWT. Il s'agit d'applications de gestion dont les traitements côté client peuvent parfois être assez importants. La fluidité sous Internet Explorer n'est donc souvent pas optimale quand on la compare à celle sous Firefox ou Chrome.

Malheureusement, comme dans de nombreuses entreprises, le navigateur installé sur les postes de nos utilisateurs est Internet Explorer et faire installer un second navigateur pour optimiser la consultation de nos applications n'est pas vraiment une possibilité.

A l'annonce de la mise à disposition de ce plugin, nous avons décidé de le tester sur nos applications et les résultats se sont montrés vraiment impressionnants. Les gains en termes de rapidité d'exécution et de fluidité sont tels que l'adoption a été quasiment immédiate par le client.
Certes, tout n'est pas rose, nous avons eu quelques petites surprises d'affichage et le plugin est encore très jeune mais globalement pour un effort vraiment minime, les gains en termes de performance sont au-delà de ce que n’importe quelle optimisation de notre application aurait pu donner.


Le site officiel de Google Chrome Frame
L'annonce sur le site de GWT
Chrome Frame et Google Wave

jeudi 13 août 2009

Utiliser des CSS avec Uibinder

Pour revenir sur un billet précédent, dans lequel un widget basique était conçu avec UiBuilder, nous avions pu constater la puissance de la technologie, mais le résultat n'était pas visuellement appétissant.

Voilà qui est maintenant réparé avec l'utilisation des CSS avec UiBinder pour donner une meilleure apparence aux widgets. Ce fut aussi l'occasion d'utiliser une autre fonctionalité à venir de GWT, le ClientBundle, qui permet à l'instar de l'ImageBundle de transmettre toutes ses ressources au client à travers une seule requête HTTP.


Feuille CSS et UiBinder

mercredi 12 août 2009

Prendre de l'avance sur GWT 2.0

Google Web Toolkit étant un projet open source, il est possible de suivre l'avancement du projet au jour le jour sur le dépôt svn officiel.

On peut donc voir les fonctionnalités promises pour la version 2.0 apparaitre peu à peu, et on a récemment constaté l'apparition dans le code d'UiBinder, qui permet de construire ses interfaces GWT avec des templates en XML au lieu du code Java habituel.

C'était donc l'occasion rêvée de prendre le temps de compiler une version snapshot et de tester à travers un exemple simple l'efficacité d'UiBinder.

Le résultat de ces expérimentations peut être trouvé ici :

Télécharger GWT r5926

Un exemple d'utilisation

On retiendra que la conception d'interfaces avec cette technologie est très agréable et offre une séparation bienvenue entre le visuel et le code métier. Tout n'est pas rose cependant, puisqu'on perd entre autres les possibilités liées au code java telles que les possibilités de refactoring, mais gageons qu'une fois que l'utilisation de cette technologie se démocratisera, de nombreux outils permettront de l'utiliser pour améliorer la productivité.

mercredi 8 avril 2009

Développez en Java vos applications Google App Engine :

Il y a à peu près un an, Google ouvrait l'App Engine aux développeurs, il n'était alors possible de déployer que des applications développées en Python.
Pour rappel, Google App Engine est une offre de Cloud Computing permettant aux développeurs d’héberger leurs applications Web sur les serveurs de Google. Les applications ainsi hébergées bénéficient de ce fait de la même capacité de montée en charge que les services Google tels que Gmail ou Google Finance.
Google n’est pas la seule entreprise positionnée sur ce secteur, bien que pas tout à fait similaires, Amazon et Microsoft ont eux aussi leurs offres avec respectivement AWS et Windows Azure.
Un des atouts de Google App Engine c’est que gratuitement un développeur peut déployer une application qui soit accédées à raison de 5 millions de pages vues par mois. Ce qui est somme toute une offre d’hébergement intéressante. Au-delà de ces quotas, il est possible d’acheter des ressources supplémentaires.
Depuis quelques mois, nous pouvions voir dans la roadmap de ce projet que le support d’autres langages était un des objectifs de Google. Aujourd'hui, c’est chose faite, Google ouvre son service à une nouvelle communauté et contrairement à leur poisson d’avril, ce n’est pas Fortran mais bien Java qui est désormais supporté.
Cette nouvelle devrait donc être accueillie avec un vif enthousiasme lorsque l’on sait que le support de Java a été l’une des premières évolutions suggérées par les développeurs lors de la sortie de la première version de l’App Engine.
La version Java ne déroge pas au qualificatif de « Simple d’utilisation » qui caractérisait la version Python. En effet, il n’y a pas de différence majeure dans l’approche qu’ont ses deux dernières. Un atout supplémentaire de la version Java et qui a son importance, c’est le fait qu’elle s’accompagne d’un plugin Eclipse. Il est ainsi possible de créer une application et de la déployer en quelques clics.
De plus, l’intégration avec GWT (Google Web Toolkit) est enfantine et proposée par défaut par le plugin.
L’environnement de développement App Engine Java supporte les versions Java 5 et Java 6, sachant que sur les serveurs distants c’est la 6 qui est supportée. Les pré-requis au développement et au déploiement d’applications sur la plate-forme sont relativement faibles : avoir installé Java et le SDK de l’App Engine. L’installation du plugin Eclipse est bien entendu un plus non négligeable.
L’administration des applications se fait via la même interface que pour les applications Python. Il est ainsi possible de voir la répartition de la charge dans le temps, les requêtes HTTP les plus récurrentes, le taux d’utilisation ramené aux quotas. Il est également possible de consulter les logs. Enfin, une page permet d’accéder aux données stockées dans le Datastore.
Etudions de plus près l’architecture d’un projet et l’utilisation des APIs

Passons à la pratique : 

Les applications Google App Engine doivent être structurées en respectant l’arborescence WAR, ainsi, si vous créez un projet via le plugin Eclipse, vous obtiendrez une structuration semblable à celle-ci :

Cette arborescence de projet ne présente pas de spécificité particulière, on notera la présence d’un fichier web.xml permettant d’assurer le mapping entre les URLs et les classes des Servlets.
Lorsque vous déployez une application sur Google App Engine, une association s’opère entre les fichiers que vous transférez sur les serveurs de Google et les applications que vous êtes en mesure d’administrer. Cette association est possible grâce à un identifiant que vous vous devez de retranscrire dans le fichier appengine-web.xml. Ce fichier est l’équivalent du fichier app.yaml de la version Python de l’App Engine.
Les Servlets sont tout à fait communes et ne différent pas de celles que l’on peut développer dans une application traditionnelle. La Servlet d’un HelloWorld pourrait donc se présenter ainsi :

package com.sfeir.demo;

import java.io.IOException;
import javax.servlet.http.*;

public class DemoServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}


Maintenant que nous savons qu’il n’est pas difficile de créer un projet, intéressons nous aux APIs spécifiques de Google App Engine.

Utiliser les APIs :

Authentification

Ajouter un système d’authentification des utilisateurs se fait tout aussi facilement qu’avec la version Python :

package com.sfeir.demo;

import java.io.IOException;
import javax.servlet.http.*;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;

public class DemoServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
              throws IOException {
        UserService userService = UserServiceFactory.getUserService();
        User user = userService.getCurrentUser();

        if (user != null) {
            resp.setContentType("text/plain");
            resp.getWriter().println("Hello, " + user.getNickname());
        } else {
            resp.sendRedirect(userService.createLoginURL(req.getRequestURI()));
        }
    }
}


Ici, on utilise le UserService pour récupérer l’utilisateur actuellement connecté à l’application. S’il y a bel et bien un utilisateur authentifié, nous lui affichons un message de bienvenue et si ce n’est pas le cas, l’API nous permet de le rediriger vers une page de login. Lorsque vous travaillez en « local », le système d’authentification est émulé, il n’y a pas de vérification à proprement parler de l’existence des utilisateurs. Lorsque vous déployez votre application, le UserService se base sur les Google Accounts pour vérifier l’existence des utilisateurs.

Il est également possible de savoir si l’utilisateur actuellement authentifié est un administrateur de l’application et ainsi de lui donner accès ou non à certaines fonctionnalités.

Persistance


Attention, comme pour la version Python de Google App Engine, le stockage des données ne s’effectue pas dans une base de données relationnelle. Google dispose de son propre formalisme de stockage des données qui s’apparente à une Map multidimensionnelle partagée.
Le développeur dispose de trois solutions distinctes pour persister ses données, en effet, Google App Engine Java implémente JDO (Java Data Object), JPA (Java Persitance API) et met également à disposition une API de plus bas niveau (Datastore API).
Dans cette version de Google App Engine, Google pousse un Framework de persistance : DataNucleus. Sa configuration se fait très simplement (voir doc pour plus de détails)
Voici un exemple utilisant JDO, la définition des données à persister se fait par annotation.
Ci-dessous, l’objet Comment est défini comme pouvant être persisté, en le sauvant, les éléments annotés comme @Persistent feront parti de la sauvegarde.

package com.sfeir.demo;

import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.users.User;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Comment {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long id;

    @Persistent
    private User author;

    @Persistent
    private String content;

    @Persistent
    private Date date;

    public Comment(User author, String content, Date date) {
        this.author = author;
        this.content = content;
        this.date = date;
    }

}

Il est ensuite très simple de manipuler cet objet au travers de l’API. Ainsi, pour persister une instance de cet objet, on peut utiliser le PersistenceManager de la manière suivante :

Comment comment = new Comment(user.getNickName(), content, new Date()) ;
PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");
      PersistenceManager pm = pmfInstance.get().getPersistenceManager();
        try {
            pm.makePersistent(comment);
        } finally {
            pm.close();
        }



Avec ce PersistenceManager, il est tout aussi simple de récupérer un objet pm.getObjectById(…) ou encore de le supprimer pm.deletePersistent(…).
Au même titre qu’il était possible d’interroger la base au travers du GQL dans la version Python, il est ici possible d’utiliser un langage de requête proche de SQL pour récupérer des données, il s’agit de JDOQL.
On pourrait récupérer la liste de nos commentaires ainsi :

PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");

PersistenceManager pm = pmfInstance.get().getPersistenceManager();

String query = "select from " + Comment.class.getName();
List<Comment> comments = (List<Comment>) pm.newQuery(query).execute() ;


Gestion d'un cache mémoire


Afin de ne pas surcharger le Datastore avec des requêtes récurrentes, il peut être intéressant de stocker un certain nombre d’informations dans un cache mémoire. Cela peut se faire très simplement au travers de l’utilisation de la Memcache API.

cache = CacheManager.getInstance().getCacheFactory().createCache(Collections.emptyMap());
cache.put(‘‘cachedInteger’’, 25) ;
Integer cachedValue = (Integer) cache.get(‘‘cachedInteger’’);



Dans l’exemple ci-dessus, après avoir récupéré l’instance du cache mémoire, on y insère un entier à la clef « cachedInteger » au travers d’un put. Un simple get avec la clef nous permet de récupérer la donnée que nous avions mise en cache.
Le cache est utilisé pour cet exemple de manière très simpliste mais on pourrait imaginer l’utiliser pour retourner des informations ayant plus de valeur, comme le contenu RSS de l’application ou encore une page fréquemment requêtée.
Cette API de cache propose d’autres fonctionnalités intéressantes comme la possibilité de définir une période de validité pendant laquelle les données peuvent être considérées comme « fraiches ». Différentes politiques de gestion sont également applicables, ainsi il est possible de n’ajouter la donnée que si celle-ci est déjà présente ou réciproquement.

Envoi de mail


L'envoi de mail fait partie des fonctionnalités intégrées à Google App Engine et relativement simples à mettre en place au sein d'un projet.
Dans cette version Java, l'API implémente l'interface JavaMail, pour des raisons de sécurité, seules les adresses d’un administrateur de l’application ou celle de l’utilisateur couramment authentifié peuvent être spécifiées comme adresses de l’émetteur.
       

Properties props = new Properties();
        Session session = Session.getDefaultInstance(props, null);

        String msgBody = "Contenu du mail";

        ...
        Message msg = new MimeMessage(session);
        msg.setFrom(new InternetAddress("admin@mondomaine.com"));
        msg.addRecipient(Message.RecipientType.TO,new InternetAddress("destinataire@sondomaine.com", "Destinataire"));
        msg.setSubject("Email envoyé par Google App Engine");
        msg.setText(msgBody);
        Transport.send(msg);


L’exemple ci-dessus montre l’envoi d’un mail basic, sachez qu’il est également possible d’ajouter des pièces jointes (voir types MIME autorisés) avec la contrainte toutefois que l’e-mail ne dépasse pas les 1mb.

Comme pour la version Python, il est également mis à la disposition des développeurs une API permettant d’interroger des hôtes distants (via l’API URL FETCH) et une autre permettant de manipuler des images.

Cette version de Google App Engine étant toute récente, il va être intéressant de suivre l’adhésion des développeurs de la communauté Java à ce service. D’une part, elle offre une grande facilité de développement et de ce fait un gain de temps dans l’élaboration d’applications, ce qui devrait en attirer plus d’un. D’autre part, tout comme pour la version Python un certain nombre de quotas et de restrictions sont à prendre en compte lors de l’utilisation de ce service, ce qui exclu certain types d’applications de cette offre d’hébergement.

Cette nouvelle version est également un beau coup de pousse donné à GWT, en effet le plugin Eclipse permet de créer en quelques clics une application GWT pour Google App Engine et devrait donc  amener davantage de développeurs à adopter ce Framework Web.

Google Guice sera peut être un autre des bénéficiaires de cette version Java, bien qu’il ne soit pas poussé outre mesure par Google pour être associé à Google App Engine, sa légèreté et sa simplicité d’utilisation devrait lui permettre de s’intégrer facilement aux applications déployées sur la plate-forme.

Quoi qu’il en soit c’est une nouveauté que nous nous devons de suivre.

Références :

Pour s'inscrire
L'annonce officielle
Le Coud Computing
Tout sur Google App Engine
DataNucleus
Découvrir GWT
En savoir plus sur GUICE
Amazon Web Services
Windows Azure

- page 1 de 3