Le 19 Mai prochain aura lieu Google IO, la messe annuelle des développeurs Google. C'est l'évènement majeur du monde IT pour tout ce qui tourne autour de technologies Google. Il était prévu que je fasse le voyage mais comme bien souvent, mon planning du moment m'a rattrapé. Pour marquer le coup, je voulais quand même vous faire partager les quelques nouveautés qui seront annoncées Mercredi prochain. Notez que je n'ai bien évidemment aucune information secrète à vous dévoiler ici (même s'il y en aura !), ce billet résume simplement les six mois d'activité observé sur le code source de GWT.
Le mot-clé à retenir pour GWT 2.1 est Bikeshed. Bikeshed est le nom de code d'un nouveau framework graphique sur lequel planche l'équipe de Bruce. Pourquoi ce nom ? Bikeshed n'a pas grand chose à voir avec les vélos, en réalité c'est un terme emprunté à l'historien Parkinson. Le Bikesheding est une loi qui exprime le fait que les sujets dont on discute longtemps sont ceux qui sont les plus triviaux alors que peu de personnes peuvent échanger et exprimer une opinion sur un sujet techniquement complexe (comme celui d'un réacteur nucléaire). Tout le monde peut discuter indéfiniment de la couleur d'un abri à vélo (BikeShed) et faire entendre son avis.
Bikeshed s'appuie sur plusieurs briques fondamentales :
- De nouveaux composants graphiques
- Un framework de Validation
- Un framework (RequestFactory) permettant de synchroniser des entités serveur suivant une philosophie REST/JSon
- Un framework de Data-Binding (appelé aussi ValueStore)
- Un framework gwt-collections
Au jour d'aujourd'hui, je ne sais pas si GWT 2.1 sera annoncé à Google IO et quelle sera la place laissée à Bikeshed. Vu la maturité du code disponible sur le trunk, Bikeshed n'est qu'un embryon de framework. En revanche, ce qui est sûr, c'est qu'il représente une brique majeure dans la stratégie GWT de Google pour les prochains mois.
Nouveaux composants graphiques
Il y a encore peu d'information disponible sur les nouveaux composants graphiques. La fameuse grille paginée est belle est bien là. Elle se prénomme PagingTableListView. Elle n'a plus grand chose à voir avec la fameuse grille du projet d'incubation. Cette fois, les entêtes sont personnalisables et un modèle (ListView) fait son apparition.
public class PagingTableListView<T> extends Widget implements ListView<T> { ... }
PagingTableListView<StockQuote> favorite = new PagingTableListView<StockQuote>(10);
favoritesListViewAdapter.addView(favorite);
favorite.addColumn(Columns.tickerColumn, "ticker" );
favorite.addColumn(Columns.priceColumn, "price" );
favorite.addColumn(Columns.profitLossColumn, "profit/loss" );
On trouve également de nouveaux composants de type arbre (SideBySideTreeView et StandardTreeView), un TreeView est également associé à un modèle. Plus généralement, la plupart des nouveaux composants arborent désormais un modèle et surtout, autre nouveauté, un client bundle pour la gestion des ressources. Voici une partie du code source de la classe TreeView :
public abstract class TreeView extends Composite {
/**
* A ClientBundle that provides images for this widget.
*/
public static interface Resources extends ClientBundle {
/**
* An image indicating a closed branch.
*/
ImageResource treeClosed();
/**
* An image indicating an open branch.
*/
ImageResource treeOpen();
}
private static final Resources DEFAULT_RESOURCES = GWT.create(Resources.class);
{...}
Framework de validation
Un framework de validation est également en préparation. Pour l'instant on ne peut pas dire qu'il soit réellement industriel, on trouve simplement une ou deux classes, une sorte de brouillon de prototype.
Gestion du data binding
Pour ceux qui ont l'habitude d'utiliser du DataBinding dans les framework traditionnel (beans-binding, Flex, Silverlight, .), oubliez tout, GWT a cherché à innover sur ce plan. Pour faire court, le RequestFactory est un framework permettant de créer des requêtes REST associé à un ValueStore, une sorte de mécanisme observer/observable permettant de synchroniser l'état d'entités (JPA) serveur sur le client. Sur le papier, le projet est très ambitieux. Dans la pratique, tout cela est encore loin d'être simple. Il manque encore tout l'outillage destiné à générer la tuyauterie aujourd'hui encore trop visible. Chaque objet du domaine, par exemple Facture ou Client possède une représentation cliente (FactureRequest) et des classes de requêtes (AllFacturesRequester) :
Ex :
public final class AllEmployeesRequester implements ValuesListView.Delegate {
private final ValuesListViewTable<EmployeeRecord> view;
private final ExpensesRequestFactory requests;
public AllEmployeesRequester(ExpensesRequestFactory requests,
ValuesListViewTable<EmployeeRecord> newView) {
this.view = newView;
this.requests = requests;
}
public void onRangeChanged(int start, int length) {
requests.employeeRequest().findAllEmployees().forProperties(
view.getProperties()).to(view).fire();
}
}
Le moins qu'on puisse dire c'est qu'il est encore trop tôt pour s'avancer sur une quelconque maturité de ce framework. A titre personnel, je le trouve (et j'ai eu l'occasion d'en parler avec Ray Ryan ici, à l'origine du projet) trop ambitieux, suréquipé et incontestablement trop compliqué. Un framework de databinding doit rester réservé au périmètre du poste client (il existe d'autres outils pour synchroniser des entités serveur) et se résumer à connecter deux propriétés. Ici, il faut compter pas moins de cinq classes par objet du domaine, même avec un générateur de code JPA, c'est beaucoup trop.
Malgré tout, il faut noter la richesse des fonctionnalités proposées ; gestion des deltas en cas de modification d'une liste, gestion des évènements (deleted, modified,..), gestion de la vue maître/détail, etc .
Collections
Bikeshed introduit également un petit framework de Collections (tableaux immuables et muables, .).
Les démos
Il existe sur le trunk plusieurs démos (elles seront sûrement présentées lors de Google IO) destinées à valoriser Bikeshed. J'avoue avoir pensé à les déployer sur AppEngine mais vu la maturité du code (tout cela relève du prototype encore) et la pauvreté des styles (le graphisme n'est décidément pas le point fort des Gwiters), cela n'aurait pas été très fair play. Voici malgré tout un petit screenshot de l'application Day Trader, on peut y apercevoir la nouvelle grille.
Pour le reste, vous en saurez beaucoup plus lors de Google IO, qui s'annonce très excitant !.
http://gwt-code-reviews.appspot.com/
et j'ai été interpelé par "Adds Street View support" qui n'est actuellement (sauf erreur de ma part) pas disponible dans l'api gwt de google maps.
En creusant un peu plus, j'ai vu ici :
http://code.google.com/p/gwt-google-apis/
que
" Google Maps 1.0 Library currently relies on GWT 1.5.3, but will be updated soon"
Tout ça pour dire que GWT (Google oblige) est vraiment un framework qui va prendre de plus en plus d'importance à mon avis.
Heureusement que des boites comme la tienne ou celle de didier l'ont compris et communiquent dessus !
L'étau se resserre autour de gmail :-)
Sami
Si tu es à paris mercredi prochain il y a une soirée organisée par Google France et le paris-gtug: http://www.zorgloob.com/2010-05/developpeur-on-vous-attend-au-gtug-paris-le-19-mai/
Sami
bref il faut bidouiller qqchose à partir du trunk pour utiliser le nouveau composant tableau...
j'ai jamais fait encore ça se fait fastoche?
Si tu peux attendre encore quelques semaines la release finale, c'est mieux.