Blog KeepCore - Développement logiciel - Mobilité - Ergonomie

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.
  • Login
    Login Login form

Vaadin : un framework Java pour développer rapidement des applications web performantes, esthétiques & ergonomiques.

Posted by on in Développement
  • Font size: Larger Smaller
  • Hits: 24383
  • 3 Comments
  • Subscribe to this entry
  • Print

 Vaadin c’est quoi ? C’est un framework Java OpenSource (Licence Apache) qui encapsule un autre framework plus connu qui est GWT (Google Web Toolkit) avec l’ambition de faciliter et d’accélerer le développement tout en améliorant l’experience utilisateur.

vaadin java gwt framework de développement d'applications

Vaadin & GWT 

Vaadin s’appuie sur GWT pour en tirer toute la puissance tout en masquant une importante partie de l’implémentation que l’on fait habituellement en GWT : échanges entre la partie client et la partie serveur. En Vaadin on code seulement la partie serveur en déclarant des composants graphiques qui se retrouve “magiquement” dans l’interface client.  Plus besoin de se soucier des échanges client-serveur (appels RPC) ni de la sérialisation / désérialisation d’objets (par exemple avec des DTO et l’utilisation de Dozer).

Vaadin embarque sa propre version de GWT : la société derrière Vaadin fait partie du steering committee GWT et participe à son évolution. Ainsi il arrive que des bugs soient corrigés dans leur distribution avant la distribution officielle Google. A souligner pour les développeurs GWT que nous sommes : il est possible d’utiliser du GWT “classique” dans une application Vaadin (Using Vaadin in an existing GWT project - Wiki - vaadin.com).  A l’inverse, l’utilisation du Vaadin dans du GWT est très limitée.

Maintenant que les présentations sont faites, passons aux avantages qui vont particulièrement plaire aux développeurs GWT…

Moins de code source = Productivité + Facilité de maintenance 

Comme on vient de le dire, avec Vaadin, on code moins: seulement la partie serveur dans laquelle on intègre les composants UI. Par exemple si on considère une grille de données on peut faire directement du paging (pagination) ou même du “live” grid (chargement à la volée) sans coder les échanges client-serveur avec les offsets, la gestion du cache…

Composants graphiques natifs évolués

Par défaut le framework propose des composants mieux pensés, plus complets que les composants GWT natifs. On a parlé de la grille mais les exemples sont nombreux : une tree-table, un calendrier complet, un date picker évolué, des list builders, un color picker….

On trouvera aussi de magnifiques Charts dans les addons payants.

http://demo.vaadin.com/charts/#DonutChart

Layouts et Skinning

Vaadin propose un ensemble de composants de layouts évolués qui permettent de placer les composants d’UI efficacement et directement en JAVA : layouts verticaux, horizontaux, layout grille…

Un CSS layout permet de d’utiliser toute la puissance du CSS pour le placement des composants.

Pour le rendu graphique Vaadin s’appuye sur le language SAAS (Syntactically Awesome Style Sheet) qui permet d’étendre les capacités de CSS et propose un système de thèmes qui facilite le skinning des composants et des applications.

Et ça marche ! 

Et c’est même bluffant.. Développeurs GWT de la première heure, nous cherchons toujours à améliorer la productivité de développement et à améliorer l’expérience utilisateur de nos applications. Nous avons adopté Vaadin pour développer des applications métiers spécifiques et le résultat est là : plus rapide à développer (moins de code), plus facile à skinner, une ergonomie native plus développée… Nos clients et surtout nos utilisateurs les plus exigeants nous confortent dans ce choix.

N'hésitez pas à réagir et nous faire part de vos expériences ou nous contacter pour étudier ensemble l’opportunité d’intégrer cette technologie dans vos projets. 

Rate this blog entry:

Leave your comments

Post comment as a guest

0
Your comments are subjected to administrator's moderation.
terms and condition.

People in this conversation

  • Bonjour Jeremy,
    Voici quelques précisions / avis concernant le fond de cet article.

    En GWT on ne fait plus (suivant la version utilisée) des appels RPC et ni des DTO: les RequestFactory permettent de sérialiser directement les entités du domaine au travers de proxy. Ceci dit c'est toujours beaucoup de code comme toujours avec GWT et là, Vaadin est vraiment un plus puisque le code est coté serveur.

    Le coté "magique" est important à expliquer !
    Vaadin n'embarque coté client que les différents composants graphiques utilisés dans l'UI : il n'embarquent pas l'UI telle qu'on l'a définie pour répondre au besoin du client. Par exemple si un écran comporte une grille avec 4 colonnes, 2 labels et 3 boutons le code coté client ne sera composé que de 3 composants (grille + label + bouton). Si on rajoute un 2ème écran avec 3 labels et un bouton, le code coté client sera le même. C'est ce que l'on appelle le WidgetSet (la liste des différents composants utilisés mais pas comme ils sont utilisés). Pour afficher l'écran tel qu'on le souhaite, Vaadin utilise un protocole propriétaire afin de demander de créer et d'organiser les composants afin d'obtenir le résultat souhaité.
    Cela à plusieurs impacts:
    1- Le temps de compilation est très faible même pour plusieurs centaines d'écran (on en recompile la partie cliente que lorsque l'on souhaite ajouter / supprimer un type de composant graphique)
    2- La partie cliente ne PEUT pas embarquer du code métier (ce qui est souvent le travers des applications GWT qui finissent pas embarquer une grosse partie du métier)
    3- Le métier étant coté serveur cela signifie un nombre très important de requête (taille très faible) : Le fait de sélectionner une case à cocher pour afficher une autre partie d'écran demande que le click soit interprété coté serveur - Ce fonctionnement peut être géré coté client en développant un composant GWT spécifique
    4- Beaucoup plus sécurisé car tout le code sera coté serveur (une bonne partie des failles de sécurité sont dues au fait de croire qu'une vérification coté client est suffisante)
    5- Pas de transmission d'entité du domaine sur la vue avec tous les travers de DTO ou de proxy tel que GWT l'oblige aujourd'hui : chaque composant possède sont propre model spécifique et seul cela est transmis coté client
    6- Possibilité de faire de la validation des écrans avec la JSR-303 seulement en annotant les entités du domaine
    7- La vue étant construite dynamiquement avec le code coté serveur il est possible d'envisager de faire une web app OSGi : et ca c'est fun ! https://github.com/eric-taix/sonni


    Pour les layouts attention les layouts cités (layouts verticaux, horizontaux, layout grille) sont des vrais pièges à performance : ils génèrent beaucoup de <div> afin d'être compatible avec certains navigateurs (je parle ici notamment d'un navigateur issu d'une firme de Redmond). On peut les utiliser mais il faut toujours vérifier les performances surtout sur un écran complexe.
    Les prochaines versions de Vaadin devraient résoudre ce problème (enfin je l'espère)

    Et pêle-mêle, je rajouterai :
    - Responsive layout (7.2 à venir) natif (l'addon existe déjà)
    - Valo (7.3) ; le nouveau theme de Vaadin qui est vraiment extra et configurable à souhait https://dl.dropboxusercontent.com/u/1284319/tmp/valo-prealpha-preview.png
    - Intégration avec Spring / CDI
    - Gestion des routes pour le bookmarking
    - Saas est effectivement vraiment bien et efficace
    - Gestion des thèmes (faire son thème n'est pas non plus trivial...)

    Le seul point noir à souligner pour moi reste le coté stateful de Vaadin : chaque utilisateur génère une consommation mémoire coté serveur stocké dans... la session de l'utilisateur. Bref la scalabilité peut être un vrai problème avec Vaadin. A éviter donc pour les applications grand public et pour les applications d'entreprises bien prendre en compte le nombre d'utilisateur.
    Autre problème : les moteurs de recherche qui seront incapable de parser vos pages (mais GWT a le même problème)

    Ceci dit Vaadin est un très bon choix avec une réelle productivité pour un très bon résultat.
    Eric

    Like 0 Short URL:
  • Merci Eric pour cet excellent retour d’expérience et toutes ces précisions fort utiles !

    Sur le côté magique et la construction de l'UI côté serveur, je rajouterai que cela rend possible également l’utilisation d’outil de type JRebel de manière très efficace mais je pense que nous aborderons ce sujet dans un futur billet.

    Au plaisir de se rencontrer et d’échanger prochainement, peut être au cours d’un événement du JUG ou autre sur Montpellier ;-)
    Jérémy

    Like 0 Short URL:
  • Guest - Eric Taix

    Avec plaisir ! Le prochain JUG est le 21 mai sur Java8 ;-)

    Like 0 Short URL:

Contactez nous

KeepCore - 35 Place Charles Gontier - 13870 - Rognonas  
  Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
Formulaire de contact