Déplacement de blog

Bonjour.
J'envoie ce billet pour informer mes chers lecteurs (s'il y'en y'a :-)) que ce blog n'est plus maintenu et que j'ai migré vers un autre blog (hébergé sur développez.com) don voici l'adresse:

http://blog.developpez.com/index.php?blog=174

Merci et on se retrouve dans mon nouveau blog !

Drag'n'Drop avec RichFaces

Bonjour: Encore un petit exemple avec RichFaces.
Cette fois-ci, il s'agit de réaliser une petite application mettant en oeuvre le drag and drop offert par RichFaces.
C'est une simple application composée d'une seule page et qui simule l'activité d'achat en ligne: quleques articles et un paneau. Pour acheter un article, il suffit de le dragger et le dropper dans le paneau.

Attaquons sans tarder la couche métier de notre application.
On commence par les entités (1 seul dans ce cas-ci):

• L'objet Item représente un article. Il contient juste un identifiant, un nom et un prix.

package model;

public class Item {
private String name;
private Long price;
private Long id;

public Item() {
}

public Item(String name, Long price) {
this.name = name;
this.price = price;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public Long getPrice() {
return price;
}

public void setPrice(Long price) {
this.price = price;
}

public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}
}

Passons maintenant au contrôleurs JSF. On en a deux:

• ItemCtrl: Un simple pojo qui expose une liste d'Items.
• CartCtrl: Contient lui une liste d'Items qui représente les articles achetés jusque là ainsi qu'un champ price qui contient le prix total des articles achetés.
  De plus, c'est ce contrôleur qui gère l'evènement drop généré lorsque l'on dépose un article sur le paneau.
  

Voici le code d'ItemCtrl

package control;

import java.util.ArrayList;
import java.util.List;

import model.Item;

public class ItemsCtrl {
private List<item> items = new ArrayList<item>();

public ItemsCtrl() {
items.add(new Item("Montre", 50L));
items.add(new Item("Table", 450L));
items.add(new Item("Chaise", 150L));
items.add(new Item("Moquette", 250L));
items.add(new Item("Lit", 750L));
items.add(new Item("Armoire", 1050L));
items.add(new Item("Ordinateur", 750L));
items.add(new Item("Imprimante", 90L));
}


public List<item> getItems() {
return items;
}

public void setItems(List<item> items) {
this.items = items;
}

}

Rien de spécial à dire à propos de cette classe ;-) (juste un détail, dans le constructeur, j'ai ajouté quelques articles fictifs pour égayer un peu l'application !)
Maintenat, le code de CartCtrl:

package control;

import java.util.ArrayList;
import java.util.List;

import org.richfaces.event.DropEvent;

import model.Item;

public class CartCtrl {
private List<item> items=new ArrayList<item>();
private Long price=0L;

public void onDropItem(DropEvent e) {

Item i = (Item) e.getDragValue();
items.add(i);
price += i.getPrice();
}

public List<item> getItems() {
return items;
}

public void setItems(List<item> items) {
this.items = items;
}

public Long getPrice() {
return price;
}

public void setPrice(Long price) {
this.price = price;
}
}

Le seul point à expliquer ici est la méthode onItemDrop.
Cette méthode ne retourn rien (void) et accèpe un paramètre de type org.richfaces.event.DropEvent
qui contient toutes les informations relatives à un évènement Drag and Drop.
En particulier, on a le champ dragValue (Object) qui contient l'objet qu'on a déplacé et laché au dessus du paneau. Ici, c'est un Item. Dèslors, on l'ajoute à la liste des articles achetés et on incrémente le prix total des achats.

Passons smaitnenant à la couhe présentation.
Pour afficher la liste des articles, j'ai décidé d'utiliser le composant DataGrid de RichFaces qui ressemble à DataTable mais qui affiche les données exactement comme le composant PanelGrid de JSF:

<rich:dataGrid value="#{itemsCtrl.items}" var="item" columns="3">
<h:panelGrid border="0" columns="2">
<h:outputText value="Nom: " />
<h:outputText value="#{item.name}" />
<h:outputText value="Prix: " />
<h:outputText value="#{item.price}" />

</h:panelGrid>
</rich:dataGrid>

Voici ce que ça donne:

on va maintenant rendre les éléments draggables. Pour ce faire, il suffit d'ajouter le composant

dragSupport de RichFaces dans chaque article. Comme le composant support d'ajax4Jsf (présenté dans les posts précéednts), ce composant ajouté le comportement draggable au comopsant qui le contient.

Dans notre cas, on va placer le panelGrid sur lequel on itère dans le composant a4j:outputPanel (dragSupport impose quelques limitations sur le conteneur, et il se trouve que outputPanel les satisifait). On ajoutera ensuite dragSupport dans le outputPanel, ce qui donne:

<rich:dataGrid value="#{itemsCtrl.items}" var="item" columns="3">
<a4j:outputPanel layout="block" style="cursor: move">
<rich:dragSupport dragType="item" dragValue="#{item}" />
<h:panelGrid border="0" columns="2">
<h:outputText value="Nom: " />
<h:outputText value="#{item.name}" />
<h:outputText value="Prix: " />
<h:outputText value="#{item.price}" />
</h:panelGrid>
</a4j:outputPanel>
</rich:dataGrid>

Comme principaux paramètres, dragSupport prend:

• dragType: une chaine qui identifie le type de l'élément. C'est surtout utile pour pouvoir discerner entre plusieurs types d'élements draggables. Ici, on en a qu'un seul, et on le nomm item.
• dragValue: la valeur de l'élément draggé. C'est cette valeur là qui sera récupéré dans DropEvent .getDragValue (cf plus haut). Ici, on met l'Item courant.

Reste maitnenant à définir la zone de drop.
Comme pour le drag, on définit un etelle zone en incluant le composant dropSupport:

<a4j:outputPanel layout="block">
<rich:dropSupport acceptedTypes="item"
dropListener="#{cartCtrl.onDropItem}"
reRender="boughtItems, totalPrice" dropValue="x"></rich:dropSupport>
<h:graphicImage url="/pics/shopping_cart.png"></h:graphicImage>
</a4j:outputPanel>

En gros, il s'agit d'une image à l'intérieur dans outputPanel 'pour les même raisons que pour le dragSupport).
Les attributs de dropSupport sont:

• acceptedType: un liste de types d'élements acceptés par cette zone. Ici, on ne a qu'un seul qui est item (cf attribut dragType du composant dragSupport).
• dropListener: la méthode d'un managed bean qui sera appelée lorsque le drag and drop est terminé (cf CartCtrl.onDropItem).
• reRender: les identifiants des composants à redessiner à la réception de la réponse de la requête générée par le drop.

N.B: Il faut mettre les composants dragSupport (ainsi que ses parents) et dropSupport (ainsi que ses parents) dans un formulaire et dans le même formulaire !

Reste enfin à afficher les articles achetés ainsi que le prix total:

<rich:dataList id="boughtItems" value="#{cartCtrl.items}" var="item">
<h:outputText value="#{item.name}" />
</rich:dataList>
<h:outputText id="totalPrice" value="Prix total: #{cartCtrl.price}" />

voilou ! C'est un peu long parceque on est passé par un exemple plus ou moins réaliste et pratique, mais c'est hyper-simple dans le fond !

Voici un petit shot de l'application:

Configuration d'eclipse WebTools 2 pour JSF

Afin de pouvoir utiliser les fonctionnalités de WTP 2, il faut le configurer avec une implémentation JSF.

J'ai réalisé deux petites démos avec Wink montrant ce processus que vous pouvez consulter dans mon espace developpez.com. Les démos sont dans cette page.

Quelques remarques vite-faites:

• Il vous faut eclipse 3.3.1.1, sinon, vous risquez le suicide avec les OOME PermGenSpace.
• Il vous faut wtp 2.0.1 (pas le 2.0), sinon vous risquez encore une fois le suicide :-)

Voilou.

GuessGame version RichFaces

On y arrive enfin !
Sans plus tarder, attaquons la chose.
N.B: Je vais passer l'étape de configuration de RichFaces (voir post précédent).
Je vous rappèle donc le principe du jeu: Au départ, l'application génère un nombre aléatoire entre 1 et 100. L'utilisateur essaie de deviner ce nombre à travers un textbox. à chaque essais, l'application vous informe si c'est trop grand, trop petit ou si c'est la bonne réponse.
On commence par le backing bean de notre jeu qui va génerer le nombre aléatoire et ensuite vérifier les essais du joueur.:

public class GameBean {
private int magic;
private Random random;
private String guess;
private String message;

public GameBean() {
random = new Random();
reset();
}

private void reset() {
magic = random.nextInt(100) + 1;
guess = "";
message = "...";
}

public String check() {
int x = 0;
try {
   x = Integer.parseInt(guess);
   if (x < 1 || x > 100)
       throw new Exception();
} catch (Exception e) {
   message = "Entrée non valide";
   return null;
}

if (x < magic) {
   message = "Trop petit !";
} else if (x > magic) {
   message = "Trop grand !";
} else {
   message = "Excellent ! Le nombre magique était " + magic;
}
return null;
}

public int getMagic() {
return magic;
}

public String getGuess() {
return guess;
}

public void setGuess(String guess) {
this.guess = guess;
}

public String getMessage() {
return message;
}
}

Voici rapidement de quoi il s'agit:

• Le champ magic (int) va contenir le nombre à deviner.
• Le champ random (java.util.Random) servira à générer les nombres aléatoires.
• Le champ guess (String) servira à receuillir les essais de l'utilisateur. Normalement, il devrait être de type int combiné avec un converter dans la page JSF, mais bon, j'ai omis ça pour simplifier la chose.
• Le champ message servira à contenir la réponse de l'application suite à un essai du joueur (trop grand, trop petit, etc.)
• La méthode privée reset() sera appelée à l'initialisation du jeu pour générer le nombre aléatoire.
• La méthode check() est une action JSF (type de retour String, sans paramètres) quis era appelé à chaque entrée utilisateur pour la vérifier.
  N.B: check retourne toujours null, et ce pour rester dans la même page.
  
• Les méthodes restantes ne sont que des getters et des setters pour exposer nos champs à l'EL (aux pages JSF).

Passons maintenant à la partie présentation. Notre jeu tiendra dans une seule page.
Normalement (sans Ajax), nous aurions déclaré dans <f:view > un élément de type <h:form > avec un inputText la dedans bindé avec notre #{guessBean.guess} ainsi qu'un outputText bindé avec #{guessBean.message} qui affichera le résultat, un truc de ce genre:

<h:form>
 <h:inputText value="#{gameBean.guess}" />
 <h:outputText value="#{gameBean.message}" />
 <h:commandButton value="Check" action="#{gameBean.check}" />
</h:form>

En cliquant sur le commandButton "check", le formulaire sera envoyé et traité par JSF, ce qui implique entre autre que gameBean.guess se verra affecter la valeur entrée dans le champ texte. Ensuite, la méthode gameBean.check() à sera appelé qui va mettre dans le champ message le résultat de la vérification et retournera null. JSF retournera la main alors à la même page qui sera rendu à nouveau mais avec le message adéquat.

Nous allons maintenant ajaxifier la chose avec RichFaces (ou plus exactement avec Ajax4Jsf).
Dans une première passe (et là, c'est vraiment magique ;-)), on se contente de remplacer le composant form de JSF par celui d'ajax4jsf, comme ça:

<a4j:form>
 <h:inputText value="#{gameBean.guess}" />
 <h:outputText value="#{gameBean.message}" />
 <h:commandButton value="Check" action="#{gameBean.check}" />
</a4j:form>

N.B: l'uri qu'il faut importer pour utiliser les comosants a4j est:

http://richfaces.org/a4j

Relançons l'application.
A première vue rien ne se passe: suite à un clic sur le commandButton, absolument rien ne se passe ... mais en fait si ! Pour s'en convaincre, il suffit d'ajouter un simple :
System.out.println("check "+guess);
au tout début de GameBean.check().
Réessayez de nouveau ... et vous remarquerez que chaque fois que l'on appuie sur le commandButton, une ligne telle que celle-ci s'ajoute dans la console (d'eclipse par exemple):

check 45
check 23

Explication ? <a4j:form> intercepte tout submit déclenché par un de ses fils (ici, le commandButton) et le traduit en requête ajax vers le serveur où elle sera traité.
Mais alors, pourquoi le message ne change pas ?
C'est simple, il suffit d'indiquer à <a4j:form> quels composants il faut re-dessiner à la reception d'une réponse ajax. Ce comportement est plus qu'il y'a de naturel, autrement, on devrait re-dessiner tout faute de savoir qu'est ce qui a changé, ce qui revient à un submit http classsique et non plus Ajax.
Notre code devient donc:

<a4j:form reRender="out" >
 <h:inputText value="#{gameBean.guess}" />
 <h:outputText value="#{gameBean.message}" id="out" />
 <h:commandButton value="Check" action="#{gameBean.check}" />
</a4j:form>

J'ai ajouté :

• l'attribut reRender="out" dans <a4j:form>


• L'attribut id="out" dans <h:outputText>

Ce qui tout naturellement veut dire "re-dessiner le composant dans l'identifiant est out à lae reception d'une réponse ajax".
N.B: reRender n'est pas limité à un seul identifiant, et peut prendre une liste d'attributs à re-dessiner, comme par exemple reRender="out, x, y, z".

En relançant l'application avec ces modifications, on aura notre guess-game version AJAX !
Pour approfondir la chose, vous pouvez essayer d'ajouter un compteur trials qui indique au fur et à mesure combien d'essaies le joueur a fait + un bouton rejouer qui ne s'affiche que lorsque la réponse est bonne (le second point, je vous le dis d'avance, est un casse-gueule :-) ... j'expliquerais pourquoi dans un prochain post).

Say Hello Version RichFaces

Bonjour.
Chose promise, chose dû (voir post précédent) ... enfin, presque: au lieu du célèbre GuessGame, on va démarre avec un truc plus simple : le non moins célèbre SayHello.
Donc, il s'agit ici de réaliser une petite application JSF + JBoss RichFaces qui se contente de récupérer un nom entrée par l'utilisateur pour ensuite le saluer (Hello $nom).
Pour commencer, dans eclipse Europa + WTP 2.0.1, il faut créer un projet "Dynamic Web Project" en prensant soin d'unclure dans les librairies du projet les 3 fichiers jars de Rich Faces 3.1.2 GA téléchargeables ici.
Ajaxifier son application JSF avec RichFaces revient juste à ajouter ces 3 fichiers jars dans le classpath de l'applciation ainsi qu'ajouter ces quelques lignes dans son web.xml (juste après <display-name>).

<filter>
 <display-name>RichFaces Filter</display-name>
 <filter-name>richfaces</filter-name>
 <filter-class>org.ajax4jsf.Filter</filter-class>
</filter>
<filter-mapping>
 <filter-name>richfaces</filter-name>
 <servlet-name>Faces Servlet</servlet-name>
 <dispatcher>REQUEST</dispatcher>
 <dispatcher>FORWARD</dispatcher>
 <dispatcher>INCLUDE</dispatcher>
</filter-mapping>

Attaquons maintenant le jeu. On commence par créer un simle POJO (le managed bean) qui servira à stocker le nom saisie par l'utilisateur:

public class HelloBean {
private String name;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}

On déclare ensuite ce bean dans faces-config.xml pour qu'il soit accessible à nos pages:

<managed-bean>
<managed-bean-name>helloBean</managed-bean-name>
<managed-bean-class>HelloBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>

On crée ensuite une première pages (index.jsp) qui se contente de "forwarder" vers la page JSF:

<jsp:forward page="hello.jsf" />

Enfin, on arrive aux choses sérieuses: du JSF et de l'AJAX. Dans la page hello.jsp, et à l'intérieur de l'élément view:

<h:outputText value="Name :" />
<h:form>
<h:inputText value="#{helloBean.name}">
<a4j:support event="onchange" reRender="greeting" />
</h:inputText>
</h:form>
<h:outputText id="greeting" value="Hello #{helloBean.name} !" />

Toute la magie de la chose est réalisée par le <a4j:support>. Il permet d'ajaxifier n'importe quel composant JSF standard. Ce composant est très flexible et a de nombreux usages, mais dans ce cas particulier, on l'a utilisé par capturer l'évènement onchange (javascript), formuler une requête AJAX et redessiner le composant outputText (reRender="greeting") à la reception de la réponse de cette requête. C'etait le comportement côté client. Côté serveur, RichFaces s'occupe de décoder la requête AJAX, mettre à jour le champ "name" de notre managed bean et formuler la réponse.

C'etait un aperçu rapide sur la simplicité de la puissance de RichFaces. Je suis en train de rédiger un tutoriel plus détaillé sur RichFaces que je publierais ensuite dans mon espace de Développez.com.

RichFaces est Cool !

Tout est dans le tire: RichFaces est cool, plus que cool !
C'est un peu tard pour le dire, mais malheureusemnt, ce n'est que là que j'ai eu l'occasion de travailler avec :-(

Sinon, sa configuration est simple (quelques jars dans le WEB-INF\lib) et quelques lignes dans le web.xml, et hop, ça fonctionne !

Mais le plus important, c'est son utilisation: j'avais déjà quelques notions en AJAX et je sais en gros de quoi il s'agit. C'est pour ça que j'avais des doutes quant au jeux de composants ajaxifiés de JSF. Mais après quelques petites applications réalisés avec RichFaces 3.1.2 GA, je ne trouve plus de noms de oiseaux pour me traiter avec ! C'est simple, c'est court, c'est solide et c'est beau !
De plus, et là je tiens à remercier la section de rédaction de la documentation de JBoss, le Getting Started de RichFaces est vraiment bien fait, à l'inverse de la documentation de nombreux autres frameworks et jeu de composants ... je pense notamment à celui d'ICEfaces avec leur tutoriel d'introduction (TimeZone application) : Bravo les gars ! Ce tutoriel là m'a convaincu de laisser tomber ICEfaces malgré que ca m'a l'air bien fait lui aussi.

Je compte prochainement rédiger un petit tuto d'introduction à RichFaces (le célèbre Guess Game que je viens de finir cet après midi). Restez à l'écoute !

P.S. : Jetez donc un coup d'oeil sur leur live demo ... Je suis sûr que vous tomberez sous le charme.

Designers vs. Developers, Declaration vs. Procedure

Silence messieurs ! Gavin a parlé !
Voilou, dans son blog, Gavin King (le créateur d'Hibernate, architecte principal de JSF, membre du comité à l'origine de JPA, Seam, etc.) a posté pour parler de l'un des aspects les plus anciens et les plus problématiques du développement web en général et Java en particulier: la couche présentation.

Le problème principal est le suivant: qui devrait réaliser cette couche ?

• Les designers ? impossible, à moins de les apprendre à travailler avec la technologie utilisée (JSP/Java, PHP, etc.)
• Les programmeurs ? Oh ... et obtenir un résultat moche !
  
• Les hybrides (programmeurs/designers) ? Difficile de manier à la fois l'art de la progrmmation et l'art du web design ...
• Les deux ? C'est la pire des possibilités à mon avis ... et ça nécessite que chaque partie connaisse les ficelles des autres ... sinon, on risque de casser le design avec des bouts de code mal placés ou de casser le code avec des bouts de html mal placés ...

Bref, JSF présente une solution plus ou moins viable à ce problème: les vues peuvent être totalement abstraites (on touche pas au html) avec une description déclarative de la page, du genre:

<h:selectOneMenu value="#{pas important pour le moment}">
   <f:selectItem itemLabel="label" itemValue= "valeur"/>
   :
   :                 
</h:selectOneMenu>

On n'exprime que son besoin, c'est à dire un menu qui permet de sélectionner un seul élément.
Une telle page (ne contenant que ce genre de déclaration) peut parfaitement être réalisé par un développeur. Après, si on veut rendre la chose plus zolie, on n'a qu'à ajouter quelques attributs dans les composants JSF pour faire le lien avec des styles CSS. C'est alors aux designers de préparer les styles, et hop !

C'est d'ailleurs la bonne architecture, même pour une page html: la page ne doit contenir que le contenu (sémantique) tandis que la mise en forme va dans les CSS.

Bref, j'explique comme une patate. Jetez plutôt un coup d'oeil sur ce qu'en dit Gavin.

Le sang coule !

Voici ce que j'appèle un débat enragé ! C'est incroyable comment une simple refléxion posée par une personne dans son blog peut faire couler du sang, euh ... de l'encre !

En gros, c'est une question simple qu' a posé Nati Shalom dans son blog: "Why most large-scale Web sites are not written in Java ?" ou en français "Pourquoi les plus grands sites ne sont pas écrits en Java ?".
Pour appuyer ses dires, il a inclu un zoli tableau généré des statistiques de High Scalability et qui est représenté dans l'image ci dessous:

Mais la réaction des internautes a été violente ... jugez en par vous même !

Nati Shalom Blog.

Eclipse Europa, enfin utilisable !

Ouf ! Les gars d'eclipse viennent enfin de fixer le maudit problème du Out of memory et PermGen Space.
Je suis actuellement en train de travailler sur eclipse depuis plus d'une heure et devinez quoi ? Pas de plantage ! C'est tout bizarre, mais je m'y ferais :-). Et le comble, c'est que le mesquin n'a que 512Mo de RAM ! et il bosse sur WTP 2 en plus !

Eclipse peut être téléchargé ici : http://www.eclipse.org/downloads/.

Defective C++

Je sais que je risque de me faire lapider pour ça, mais la tentation est trop forte ...
Voila l'expression écrite des tous mes sentiments les plus secrets et tabous à l'égard de la monstruausité qu'est le C++ :
http://yosefk.com/c++fqa/defective.html
C'est un article en anglais, qui dissique froidement et sans la moindre pitié les moindres défauts du C++ sans toutefois plonger dans la haine aveugle, c'est assez technique et agrémenté de boutts de code pour apputer ses dires.

Etant un Javaïste jusqu'à l'os, je ne peux que remercier le ciel d'avoir déniché un tel article !

Régalez vous en (ou l'inverse, ça dépend bien sûr de quel camp on est !)

Quake III Arena Reborn

Je ne sais pas si y'a encore des gens qui adorent encore jouer à Quake III malgré son age imposant et son graphisme digne du premier ping-pong sur commodore ;-), mais moi, je le suis encore ! C'est comme une maladie dont on se pas soigner !

Bref, juste pour info, Quake III Arena a trouvé un sérieux coup de tuning sous les mains experts d'excessive plus qui ont su redonner à Quake tout son charme et ont même réussi à rendre la chose encore plus speed.

Quelques points forts du mod X+ ou XP pour les connaisseurs:

• Vitesse de déplacement encore plus rapide, que ce soit sur terre ou dans l'air.
• 3 armes seulement : BFG, Lance grenades et Lightening Gun.
• BFG boosté au max : un seul coup peut couter à sa cible 200 points de santé si c'est pas plus.
• Lance grenades modifé et sert uniquement à sauter : fini de devoir marcher vers les sautoirs : on peut sauter depuis n'importe quel pixel de la carte !
• Lightening Gun modifié pour permettre de faire le Wall Riding: dans la carte Q3Dm17 (la meilleure, l'unique), il devient possible d'éviter de tomber dans le vide ou encore de faire des acrobaties hallucinantes.
• Auto Health Regeneration et plafonné à 300 points.
• Auto Reload pour tous les armes.

Bref : on a mis tout le paquet pour un maximum de fun et de speed ! N'hésitez pas, et installez la chose, ça en vaut largement la chandelle !

JSF et Facelets

Pour commencer, je dois avouer que j'adore JSF, peut importe ce qu'on raconte de mal à son égard. J'ai fait la transition l'année dernière de Struts 1.x vers JSF et je dois dire que je ne suis pas deçu. Loin de ça, je suis sous le charme ! Le degré de flexibilité que JSF offre parapport à Struts (et tout autre framework web basé sur les actions) est tout simplement imprésionnant :

• La possibilité d'utiliser ses propores JavaBeans comme managed beans (pas besoin d'hériter d'une classe particulière par exemple).
• Le binding via l'expression Language.
• Le mécanisme du navigation flow : certes basique mais simple et flexible.
• La simplicité avec laquelle on utilise plusieurs boutons submit dans un seul formulaire, ou encore la récupération de la ligne sélectionnée.
• Les validators et les converters.
• etc.
  

Ajoutons à cela que des composants d'excellente facture n'arretent pas de voir le jour (IceFaces, RcFaces, etc.).

Et pour conclure, il ne faut surtout pas oublier de mentionner la technologie de présentation Facelets qui fait passer JSP au rang de dinausore:

• rapide et léger.
• templating
• création de composants sans la moindre ligne de code Java.
• etc.

Bref, si JSF vous intéresse et facelets en particulier, vous pouvez consultez ce tutoriel rédigé par mes soins et hébergé dans Développez.com et qui décrit comment démarrer rapidement avec facelets.

Bonne lecture !

Akrogen

Bonjour.
Il s'agit ici de faire une petite présentation d'un projet OpenSource hébergé dans SourceForge dont je suis membre, qui est Akrogen.
Akrogen est un plugin eclipse de génération de code orienté composants extrêmement flexible et simple d'emploi. Une fois installé, il permet de créer des générateurs de code comme ceux d'eclipse (wizards).
Dans eclipse (et en général), pour développer un générateur de code, il faut:

1. Créer une IHM (une page ou un wizard de plusieurs pages) qui permet de collecter les différents paramètres de l'utilisateur. Cette étape nécessite de maitriser une bibliothèque de GUI (Swing, SWT/jFace, etc.)
2. Mettre en place un mécanisme de génération de code configurable (pour pouvoir injecter les paramètres collectés de l'utilisateur). Cette étape peut être simplifiée en passant par un langage de templating comme Freemarker, Velocity, etc.

Le but d'Akrogen est de s'occuper des détails techniques et de permettre au développeur de se concentrer sur l'essentiel.
Pour ce faire, Akrogen permet de:

1. Décrire ses IHMs en un langage simple basé sur XML: c'est le XUL de Mozilla qui est utilisé entre autres pour batir l'interface de Firefox et Thunderbird ainsi que leurs plugins. La tache devient alors beaucoup plus simple que si on passe par Swing ou SWT.
   De plus, il est possible d'utiliser JavaScript dans les IHMs pour décrire la logique.
   
2. Ecrire les templates du code à générer en utilisant les langages Freemarker, Velocity ou XSL.

Akrogen s'occupe alors de transformer les IHMs XUL en fenêtres SWT/jFace et d'injecter les données collectées dans les templates pour générer le code.

Akrogen permet aussi de lancer des taches Ant pour générer du code en masse ou encore effectuer des traitements plus complexes, comme du revers-engineering sur une base de données.

Une version stable d'Akrogen est disponible dans SourceForge et actuellement, on travaille sur la prochaine version d'Akrogen ou plus exactement sur un nouveeau moteur de transformation XUL -> SWT/jFace (actuellement, on utilise notre propre couche au dessus de Wazaabi) pour y inclure les fonctionnalités suivantes :

• possibilité d'utiliser d'autres grammaires que XUL (certains ne l'aiment pas trop ;-)) comme xhtml ou xforms.
• possibilité d'utiliser d'autres guis que SWT/jFace, comme Swing (Le but est de porter Akrogen vers Netbeans) ou SWT Forms.
• possibilité d'utiliser le CSS.
• un mécanisme de binding évolué, comme celui de JSF par exemple.

Nous somme à la recherche de toute personne désirant nous aider à améliorer Akrogen, surtout dans la création de catalogues (générateurs de code). Actuellement, on a comme catalogues:

• Catalogue Struts 1.x : permet de générer les Actions, ActionForm et struts-config.xml.
• Catalogue Struts 2, mais c'est loin d'être complet.
  
• Catalogue JPA : permet de générer les DTOs (Entities), DAOs et persistence.xml en utilisant JPA et Hibernate.
• Catalogue OpenJPA qui permet de récupérer la structure d'une base de données dans un fichier XML. On peut ensuite l'afficher grace au XUL dynamique.
• Catalogue XMI.

Les catalogues sont disponibles dans un repository CVS.
Le plugin et les autres fichiers sont disponible en téléchargment ici.
Pour nous contacter, vous pouvez consulter la page équipe du site d'Akrogen.
Angelo Azerr, le créateur d'Akrogen et son principal contributeur en parle dans ce blog hébergé dans Developpez.com.

Jigloo

La semaine dernière, j'ai téléchargé et installé Jigloo, le plugin eclipse qui permet de créer ses interface Swing et SWT en WYSIWYG.

C'est pas mal du tout, du moins comparé à la création manuelle des IHMs (une horreur !). Les fonctionnalités qu'il offre sont pour le moins alléchantes, surtout la conversion automatique d'IHMs entre Swing et SWT.
Pour être tout à fait franc, je ne lui ai pas accordé suffisamment de temps (d'autres fois peut être). Toutefois, j'ai pu constater les défauts suivants:

• Dans swing, les composants Glue m'ont manqué ;-) : pour s'en sérvir, il faut y aller à la main et plonger dans le code. Même si Jigloo donne la possibilité d'ajouter d'autres comosants dans la palette, ça ne marche pas avec les Glue car ils ne sont disponibles que via un static factory (Box.createGlue() par exemple).
• J'ai surtout détesté les accolades qui sont générées automatiquement par Jigloo dans le code. Bon, je comprends que ça l'aide à se retrouver dans le code, mais ça devient vite un cauchemar quant à la visibilité des variables qu'on déclare soit même.
• J'aurais aimé que Jigloo nous donne la main sur la création des model (de Swing : ListModel, etc.).
  

Néamoins, j'étais séduit par Jigloo dans l'ensemble, et je le préferais volontiers au lieu de me taper des dizaines de lignes de code rien que pour l'IHM.

Point of Inception

Voilou: c'est le premier message de mon premier blog.
Dans ce blog, je compte parler de pleins de choses, notamment de Java et des divers outils et frameworks que j'ai ou que j'utiliserais (Dieu sait qu'ils sont si nombreux).
Ca tournerait autour de JSF, Facelets, JPA, eclipse, etc.
En espérant que ce sera utile !