Mardi 28 octobre 2008 2 28 /10 /Oct /2008 11:07
En butinant un peu sur le net, j'ai découvert une annonce sur la sortie de la version 0.6 d'un framework graphique nommé Metawidget.
Alors, Metawidget, késako ?
  • comme je l'avais dit plus haut, il s'agit d'un framework graphique. Il permet donc de créer des IHM avec du code Java
  • quelles différences avec ce qui existe déjà, genre Struts, Spring MVC, Swing, JSF et tout le bazar ?
    • Metawidget fonctionne un peu différemment, pour moi, c'est le "bean thinking"+"no graphical component coding" : vous développez vos beans Java comme vous le souhaitez, sans vous soucier de la création des composants graphiques associés
    • Mieux encore, Metawidget est multi-support : on peut créer des IHM Swing aussi bien que des pages HTML avec, rien qu'en jouant avec des fichiers de configuration
    • Dans un pattern MVC, il se situe dans la partie V (view)
    la prise en main est très simple : en moins de 5mn, j'ai réussi à créer un IHM Swing (et Dieu sait que je suis nul en Swing) qui me permet de saisir les informations sur une personne, tout ceci sans avoir eu à fouiller dans les API Swing
Je résume un peu les étapes :
  • j'ai créé un POJO tout ce qu'il y a de plus classique
public class Eleve {
    private String nom;
    private String prenom;
    private Date dateDeNaissance;
    private boolean paresseux;
    private int note;
  
   ............... + tous les getter possibles
}
  • j'ai piqué le code du tutorial pour avoir le manager et l'introspecteur de Metawidget
public class EleveUI {
    public static void main(String[] args) {
        Eleve eleve = new Eleve();
        
        SwingMetawidget metawidget = new SwingMetawidget();
        metawidget.setInspector( new PropertyTypeInspector() );
        metawidget.setToInspect( eleve );
   
        JFrame frame = new JFrame( "Metawidget Tutorial" );
        frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
        frame.getContentPane().add( metawidget );
        frame.setSize( 400, 220 );
        frame.setVisible( true );
    }
}

  • Rien qu'avec ça, j'ai eu ce résultat

Notez que :
  • il s'est débrouillé tout seul pour rajouter les attributs de ma classe les uns en dessous des autres
  • il s'est adapté tout seul au type
  • il a trié par ordre alphabétique mes attributs (j'aurais aimé un tri suivant l'ordre d'apparition dans le fichier source mais bon...)
  • mieux encore : sans que je fasse quoi que ce soit, il m'a mis comme libellé "Date de naissance" pour l'attribut "dateDeNaissance"
  • il faut que l'attribut soit lisible, donc soit en visibilité "public" soit avec un getter public
Ce premier test se revèle déjà concluant, en montrant les capacités de Metawidget, avec une prise en main très facile.
Le tutorial nous permet d'aller plus loin :
  • je peux donner moi-même l'ordre d'apparition des champs, en mettant des annotations dans le fichier source. Par exemple, si je veux que la date de naissance apparaisse après le prénom, je mets :
@UiComesAfter("prenom")
private Date dateDeNaissance
  • je peux aussi externaliser cette gestion dans des fichiers de configuration XML, ce qui est à la mode en ce moment, et permet aussi de la souplesse, car honnêtement, aller dans le fichier source pour ordonner les champs, ce n'est pas ce qu'il y a de mieux, c'est même une hérésie pour moi
Là, je n'ai fait que du Swing, mais il parait qu'avec le même bean, en changeant juste d'introspecteur, je peux générer du JSF voire du GWT... pas mal non ?
Bref, ce framework promet pas mal de choses, espérons que son avenir en sera autant, je vais essayer de le suivre de près.
Il est accessible ici
Par Lanto Randria - Publié dans : Veille
Ecrire un commentaire - Voir les 0 commentaires
Mardi 21 octobre 2008 2 21 /10 /Oct /2008 10:12
Quand je dis "petits jeunes développeurs", je parle de ceux qui viennent de sortir de l'école ou de la fac, et qui arrivent dans le monde merveilleux de l'informatique, en étant développeurs (ou consultants juniors comme ils aiment bien le dire en ce moment).
Cet article pourrait vous être utile, pour vos développements Java/J2EE. Ayant géré une équipe de développeurs, j'ai découvert toutes les petites bêtises (plus ou moins graves selon le cas) qu'un développeur débutant peut commettre. Je vais donc essayer de lister ici ce qui me passe par la tête.
  1. Bien formater le code : sachez que le code que vous allez développer sera repris par quelqu'un d'autre, notamment dans le cadre d'une maintenance. Si le code est "mal écrit" (mal indenté, par exemple), celui qui va le reprendre prendra plus de temps à comprendre le code qu'à le corriger). Demandez si, sur votre projet, il n'existe pas un document sur les normes de codage à respecter. Sinon, un excellent document sur lequel vous pourrez vous baser est celui de Sun
  2. Eviter d'utiliser "System.out.println" : cette méthode devrait être bannie par le compilateur, si ça ne tenait qu'à moi :
    1. Quand vous devez développer une application Web, il faut savoir que votre application va tourner en permanence, peut-être même 24h/24. Prenons par exemple le fait que vous affichez l'entrée dans la méthode qui authentifie les utilisateurs : à chaque connexion (réussie ou échouée), vous allez écrire sur la sortie standard, qui est redirigée vers un fichier dans la plupart des cas. Ce fichier va exploser assez vite pour peu que vous avez quelques centaines d'utilisateurs à authentifier par jour
    2. Les messages imprimés de cette façon le seront irrémédiablement : plus moyen de les enlever à moins de modifier le code et de recompiler l'application, mais sur un système en production, ce ne sera pas faisable en 15mn
    3. Je conseille l'utilisation des frameworks de logging, le plus connu et utilisé étant LOG4J. Il y en a beaucoup d'autres mais celui-ci est le plus facile à mettre en oeuvre à mon avis
  3. Modifier les templates par défaut d'Eclipse : je pars du principe que vous allez développer sous Eclipse. Dans ce cas, je conseille vivement d'aller directement modifier les templates par défaut d'Eclipe (Menu Windows -> Preferences -> Java -> Templates).
    1. Changez le template de code pour le bloc "try...catch". Pourquoi ? Parce que celui qui est proposé ne fera qu'afficher la stack trace de votre exception et ne fera rien d'autre. Et comme d'habitude, le développeur est pressé, donc il ne prendra pas la peine de le modifier. Or c'est une des principales sources de bug : on a "catché" une exception, on a imprimé sa stack trace, mais on n'en fait rien.
    2. Dans ce cas, mettez donc un nouveau template, en virant en premier l'immonde "e.printStackTrace();" par un autre message d'erreur du style "logger.error("Erreur", e);" (on utilise ici LOG4J, par exemple)
  4. Faire gaffe aux exceptions "étouffées" : prenons un exemple simple
    1. import java.io.*;

      class LireLigne
      {
      public static void main(String[] argv) throws IOException
      {
      BufferedReader lecteurAvecBuffer = null;
      String ligne;

      try
      {
      lecteurAvecBuffer = new BufferedReader
      (new FileReader(argv[0]));
      }
      catch(FileNotFoundException exc)
      {
      System.out.println("Erreur d'ouverture");
      }
      while ((ligne = lecteurAvecBuffer.readLine()) != null)
      System.out.println(ligne);
      lecteurAvecBuffer.close();
      }
      }

    2. (c'est marrant, j'ai piqué le premier code que j'ai trouvé sur le net, et je vois déjà toute ce que je ne souhaite pas voir... )
    3. Jettez un oeil au catch : il imprime l'erreur comme quoi il n'arrive pas à ouvrir le fichier (c'est bien !), mais... il n'en fait rien. Pire en core, avec ce code, même si le fichier ne peut pas être ouvert, il va quand même continuer à essayer de lire dedans. Et ça va encore planter sur la ligne suivante. C'est ce que j'appelle "étouffer" une exception : quand on catche une exception :
      1. soit on l'enchaine, en la levant une fois de plus
      2. soit on lève une nouvelle exception (peut-être plus compréhensible que l'exception originale)
      3. soit on ne fait rien, mais dans ce cas, on en assume les conséquences en assurant que ce qui se fait après ne va pas planter. Et dans ce cas, bien mettre dans le code un commentaire disant qu'il est normal que l'exception soit étouffée
  5. Documenter votre code : comme dit plus haut, vous ne serez pas le seul à travailler sur votre code. Ayez donc une pensée amicale à celui qui va le reprendre : ajouter des commentaires utiles à votre code.
    1. ne pas en mettre trop pour qu'on ne soit pas noyé dans des commentaires
    2. ne pas en mettre peu pour que ce soit quand même compréghensible
Par Lanto Randria - Publié dans : Conseils
Ecrire un commentaire - Voir les 0 commentaires

Présentation

Créer un Blog

Recherche

Calendrier

Juin 2012
L M M J V S D
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
<< < > >>
Créer un blog gratuit sur over-blog.com - Contact - C.G.U. - Rémunération en droits d'auteur - Signaler un abus