Site de rencontre

Je travaille depuis quelques mois sur un projet de site de rencontre, et voilà enfin le travail terminé.

www.flechedecupidon.fr

Mon site est assez simple, il ne propose pas de fonction avancée tel que tchat ou webcam. Un simple site pour célibataires souhaitant faire connaissance en s’échangeant des messages.

Le site est gratuit pour les femmes. Les hommes ont la possibilité de consulter les profils en page d’accueil, mais pour envoyer un message ou faire une recherche, ils doivent souscrire à l’offre Premium. De manière assez classique, je propose trois formules d’abonnement avec tarif dégressif.

Il y a beaucoup de sites de rencontre, mais il y a aussi beaucoup de célibataires à la recherche de l’amour. Je fais d’ailleurs partie de ces hommes esseulés. Cela peut paraître paradoxale d’être célibataire et de faire un site de rencontre, mais j’ai mené ce projet dans un esprit parfaitement professionnel.

Je ne compte pas faire fortune avec ce site. Je l’ai fais surtout pour découvrir le côté grisant de la création d’entreprise. Cela fait des nombreuses années que je veux franchir le pas, c’est maintenant chose faite, et je ne compte pas en rester là.

To be continued

PS : Vous pouvez également suivre l’actualité de FlecheDeCupidon sur le compte Twitter : https://twitter.com/fdc_fr

Comment utiliser Twitter

Twitter est la dernière mascotte des médias, il ne passe plus une journée sans qu’un site d’info ou un blog en parle.

Très simple en apparence, Twitter est pourtant régit par des codes obscurs pour le néophyte. Je vous propose donc un petit tutoriel pour vous initier aux pratiques en vigueur dans la twittosphère. Vous trouverez un petit lexique en bas de page.

Qu’est-ce que Twitter ?

Twitter est généralement défini comme un service de micro-blogging. Il vous permet de poster publiquement des séquences très courtes, précisément 140 caractères, sur votre dernière paire de chaussure achetée en solde, sur votre émotion en ayant apris la mort de Michael Jackson, sur une news dont vous avez entendu parlé à la pause café, bref, sur tout ce qui mérite plus ou moins d’être partagé avec qui veut bien l’entendre. Vous pouvez également échanger des opinions, partager des liens, images ou vidéos avec vos amis.

Comment se faire des amis ?

Twitter peut aussi se définir comme un réseau social au même titre que Facebook. Cependant, la notion d’ami y est différente. Sur Facebook, c’est vous qui décidez qui peut devenir votre ami et suivre les mises à jour de votre profil. Sur Twitter, c’est l’inverse. Ce sont les autres qui décident de suivre ce que vous postez. Vos tweets sont publics et ouverts à tous (sauf si vous décider de restreindre votre profil à vos amis, mais cette pratique n’est pas courante). Cela signifie que vous pouvez à votre tour suivre le profil de n’importe quel twittonaute.

C’est cet aspect qui est le plus déroutant et qui peut s’avérer le plus décourageant. Vos tweets sont jettés dans la twittosphère comme des bouteilles à la mer. Il faut du temps, comptez plusieurs mois, avant de se constituer un réseau d’amis avec lesquels vous pourrez discuter régulièrement. Car ceux que vous suivez ne vous suivront pas pour autant.

Alors pour répondre à la question “comment se faire des amis”, il y a quelques règles à respecter :

• Pour commencer, recherchez les personnes que vous connaissez avec la fonction de recherche de Twitter. Ensuite, de nombreux blogueurs mettent le lien de leur profil Twitter sur leur blog. Enfin, sachez que certaines personnalités sont présentes sur Twitter. Personnellement je suis Sébastien Chabal ainsi que Fabrice Luchini [EDIT : Le compte de Fabrice Luchini a été piraté]. A chaque fois, parcourez la liste des abonnés et abonnements pour trouver de nouveaux twittonautes.
• Une fois que vous avez trouvé des personnes sur Twitter, choisissez parmi celles-ci des personnes dont vous partagez les idées et les centres d’intérêts. Pour cela, lisez les 20 ou 30 derniers tweets. Il est tout à fait normal de commencer avec 20 ou 30 followings, tout en ayant aucun follower au début. Vous constaterez néanmoins qu’il devient difficile de suivre un trop grand nombre de personnes car cette activité est très chronophage. Personnellement, il me faut environ un heure, répartie sur toute la journée, pour suivre mes 100 followings et entretenir mon réseau.
• Ensuite, lorsque vous vous êtes constitué un petit réseau, adressez-vous directement à vos followers. L’usage est de commencer le tweet par le pseudo de votre interlocuteur, préfixé avec le signe @. Il n’est pas nécessaire que votre interlocuteur fasse partie de vos followers, c’est donc une bonne manière d’attirer l’attention de quelqu’un. Naturellement, ajoutez à vos followers ceux à qui vous vous adressez. Ex : @hadf Très intéressant ton tutotiel !!
• Enfin, persévérez. Il vous semblera crier dans le désert les premiers mois.

Que puis-je bien poster sur Twitter ?

C’est sans doute la question que se posent tous les néophytes. Que puis-je bien dire en 140 caractères ?

Tout dépend de l’usage que vous souhaitez faire de Twitter. Personnellement j’utilise Twitter comme un fil d’actualité, donc je partage moi-même des news qui m’intéressent ou mon opinion sur l’actualité informatique du jour. Mais vous pouvez parler de mode et de frou-frou si c’est ce qui vous passionne ^^ Le plus important est de se constituer un réseau qui soit en phase avec ses centres d’intérêts.

Très bien, mais 140 caractères, c’est un peu court. Eh bien, c’est justement cette contrainte très forte qui a stimulé la créativité des twittonautes. Ceux-ci ont développé des codes pour communiquer en si peu d’espace.

Voici un petit tour d’horizon des pratiques les plus répandues :

L’aparté :

Nous en avons déjà parlé, ce message débute avec le pseudo de votre interlocuteur préfixé avec le signe @. A ne pas confondre avec le message direct (DM : Direct Message) qui est très peu utilisé.

Sachez que, lorsqu’un tweet débute par un pseudo, celui-ci apparait uniquement dans la timeline des followers que vous avez en commun avec votre interlocuteur.

Ex: @hadf Merci pour ce tuto

Dans cet exemple, ce message apparaîtra uniquement sur la timeline des followers que vous avez en commun avec @hadf

Le lien :

Puisqu’il est difficile de philosopher en 140 caractères, la qualité d’un tweet est généralement jugé à la qualité du lien auquel il renvoi. Ainsi, vous partagez un article de journal ou un billet de blog. Le problème est que, limité à 140 caractères, vous ne pourrez bien souvent pas posté l’url complète de votre article. Il existe un service qui permet de contourner cet obstacle, ce sont les raccourcisseurs d’url. Le service officiel de Twitter est bit.ly, mais vous trouverez de nombreux autres services qui permettent de raccourcir une url pour la faire tenir en moins de 140 caractères, ce qui vous permettra d’y ajouter un commentaire car on ne poste généralement pas un lien tout seul.

Ex: Excellent tuto http://bit.ly/7RC9fd (ce lien renvoie vers cet article)

Le retweet :

Le retweet est une pratique qui consiste à reprendre à votre compte, tout en citant l’auteur, un tweet qui vous a particulièrement intéressé. Cette pratique est très répandue, c’est grâce à elle qu’une info peut se diffuser très rapidement dans la twittosphère, comme ce fut le cas lors de la mort de Michael Jackson. Les twittonautes ont été les premiers à apprendre le décès de la star car, de retweet en retweet, l’info s’est propagée à toute la twittosphère. Pour retweeter un tweet, il suffit de le copier-coller en le préfixant par les lettres RT suivies de l’auteur d’origine. La plupart des clients Twitter ont une fonction de retweet intégrée qui évite de copier-coller manuellement. Le problème du retweet est qu’il nécessite un peu d’espace supplémentaire. Donc quand vous écrivez un tweet que vous espérez voir retweeté, laissez toujours quelques dizaines de caractères libres. Etre retweeté est un signe d’influence dans la twittosphère.

Ex: RT @toto Excellent tuto http://bit.ly/7RC9fd

Le hashtag :

Le hashtag permet de tagger un tweet pour préciser le thème en le préfixant par le symbole #. Il est possible d’ajouter plusieurs hashtags, en revanche il n’est pas recommandé de hashtagger tous ses tweets. L’intérêt du hashtag est de réunir sous un même tag tous les tweets traitant du même sujet. Ainsi, le site http://www.hashtags.org permet de suivre les hashtags les plus populaires.

Ex: Sortie de prévue de Firefox4 fin 2011 #Firefox #Firefox4

Entretenir son réseau

La règle la plus élémentaire est de répondre à ses followers, ce qui vous oblige à consulter régulièrement les tweets qui vous sont adressés. Pour cela deux solutions. La première est de vous rendre régulièrement sur le site de Twitter et de cliquer sur le lien à droite qui porte votre pseudo (dans mon cas @hadf). La deuxième solution, de loin celle préférée par les twittonautes, est d’utiliser ce qu’on appelle un client Twitter. Il s’agit d’un petit logiciel qui vous permet de poster sur Twitter et de suivre votre timeline ainsi que les tweets qui vous sont adressés. Il existe de nombreux clients, personnellement j’utilise Seesmic Web, car cela me permet d’accéder à Twitter au boulot sans rien installer sur mon ordinateur de travail. Il existe une liste officielle de clients Twitter :

• http://twitter.com/downloads

Pour entretenir votre réseau, sachez également qu’une pratique courante sur Twitter consiste à gratifier ses followers les plus intéressants par un Follow Friday. Comme son nom l’indique, le Follow Friday se pratique le vendredi et consiste à poster les pseudos des personnes que vous voulez mettre en avant en ajoutant le hashtag #FF. Il est tout à fait possible de mentionner un follower à plusieurs reprises, ou d’en mentionner plusieurs en même temps. Néanmoins, je recommande d’éviter de mentionner trop de personnes en même temps car cela atténue la visibilité de votre Follow Friday.

Ex: #FF @hadf @toto

Les applications exotiques

Twitter, comme nous l’avons vu, est un service de micro-blogging. Mais sachez que ce service peut être utilisé à d’autres fins qui reposent généralement sur le hashtag.

Je citerai deux services qui utilisent Twitter :

• Facebook : Vous pouvez poster sur Facebook à partir de Twitter, ce qui permet de partager un message sur les deux réseaux en même temps. Vous devez pour cela ajouter l’application Selective Twitter à votre compte Facebook. Ensuite, la manipulation consiste tout simplement à ajouter le hashtag #fb à la fin de votre tweet, et dans les minutes qui suivent, votre message apparait également dans votre profil Facebook
• Covoiturage : Le site easycovoiturage.com a mis en place un service basé sur Twitter. Vous pouvez ainsi proposer des trajets à partir de Twitter en utilisant le hashtag #covoiturage et en respectant une syntaxe bien précise : départ/arrivée/commentaire #covoiturage. Ce service est très peu utilisé, mais il donne un aperçu de ce qui se fait autour de Twitter.

Je citerai également une des plus anciennes applications faite autour de Twitter, il s’agit de TwitterVision, un service qui permet de localiser les tweets en temps réel :

• http://beta.twittervision.com/

Conclusion

J’espère vous avoir donné envie de mieux connaître Twitter et surtout de l’utiliser. N’hésiter pas à m’ajouter dans vos followings ^^

• http://twitter.com/hadf

Lexique

tweet : message posté sur Twitter

twittosphère : le réseau Twitter

twittonaute : adepte de Twitter

follower : twittonaute qui suit votre profil (abonné)

following : twittonaute que vous avez décidé de suivre (abonnement)

timeline : fil d’actualité qui agrège tous les tweets de vos followings

client : logiciel que vous installez sur votre ordinateur

url : lien hypertexte commençant par http://

Responsabilité et atomicité des fonctions

Le projet sur lequel je travaille comporte des problèmes d’architecture que j’ai déjà évoqué dans mon billet précédent. Aujourd’hui, je souhaite aborder un autre problème de conception, qui concerne la répartition des responsabilités dans une classe.

Craig Larman nous conseille de respecter le principe de forte cohésion lorsqu’on défini les responsabilités que doit implémenter une classe. A une échelle inférieure, une méthode doit également respecter une certaine cohésion.

Pour être concret prenons l’exemple d’une méthode qui s’appellerait isValide() et supposons que l’implémentation de cette méthode nécessite d’effectuer une itération sur une liste. La tentation est de profiter du parcours de cette liste pour effectuer des traitements annexes “à la volée”, ce qui évite de parcourir la liste une deuxième fois. Dans notre cas, le contrat annoncé par la méthode isValide() consiste fournir la réponse à une question. Pour respecter la cohérence de la fonction, celle-ci doit se contenter strictement d’y répondre et rien d’autre. Tout traitement annexe vient polluer la méthode et rend son utilité moins évidente.

Le problème qu’on peut rencontrer est que cela peut aboutir à une duplication de code. Pour reprendre l’exemple d’une fonction qui implémente une itération sur une liste, on peut se retrouver à implémenter cette itération dans plusieurs méthodes pour respecter l’unitarité de chacune d’elle. Si cela pose des problèmes rédhibitoires de performance, la solution est de n’avoir qu’une seule itération et d’implémenter le pattern Observer pour effectuer plusieurs traitements sur les éléments de la liste.

La cohérence d’une fonction rend son utilité plus claire ce qui facilite la maintenance du code.

La gestion des dates en Java

Je travaille actuellement sur un projet dans lequel nous avons besoin de manipuler des dates. Le projet est assez ancien, il date de plus de quatre ans, et à l’évidence, ceux qui ont écrit cette appli ne maîtrisaient pas très bien la programmation orientée objet. Et comme dans le même temps, très peu de documentation a été rédigée et que le projet a changé de domaine, je me retrouve tout seul à essayer de décrypter des lignes de code absconses et indigestes.

Je souhaite donc vous faire profiter d’un petit retour d’expérience afin d’améliorer la gestion des dates dans vos projets Java.

Petit rappel, il existe deux classes qui permettent de représenter une date dans l’api standard. Il s’agit de Calendar et Date, toutes deux dans le package java.util. Je ne traite pas ici du package java.sql.

Lorsque vous avez besoin de représenter une date en attribut d’une classe, je recommande l’utilisation de Date plutôt que Calendar. En effet, Date est un objet immuable (ou presque), il garanti qu’il ne sera pas modifié par mégarde et élimine les problèmes d’accès concurrent en cas de programmation multithread :

public class Personne {
    public final String nom, prenom;
    public final Date dateDeNaissance;
}

Faites attention lorsque vous initialisez une Date. Si vous utilisez le constructeur par défaut, la date sera initialisée avec pour valeur le nombre de milliseconde depuis le 1er janvier 1970. Le problème est que lorsque vous récupérez une deuxième Date par défaut et que vous les comparez toutes les deux, bien que ces deux dates correspondent au même jour calendaire, la comparaison échouera car la valeur en milliseconde sera différente.

Je recommande donc l’écriture d’une classe d’utilitaire qui permettra de manipuler les dates en adoptant une approche fonctionnelle :

public class CalendarUtil {
    private static final Calendar calendar = Calendar.getInstance();

    public static Date getDate(int jour, int mois, int année) {
    }
    public static Date getDate() {
        //retourne une date correspondant à la date courante (aujourd'hui)
    }
    public static Date incrementer(Date date, int jours) {
    }
    public static boolean equals(Date date1, Date date2) {
        //indique si deux dates correspondent au même jour calendaire
        //sans tenir compte des heures, minutes, secondes
    }
    public static int difference(Date date1, Date date2) {
        //retourne la différence en nombre de jours
    }
    public static boolean isEcheanceEchue(Date date, Periodicite period) {
    }
    public static String format(Date date, String pattern) {
    }
    [...]
}

Comme vous l’aurez constaté, cette classe d’utilitaire ne prend que des Date en paramètre. C’est en effet ma troisième recommandation et sans doute la plus importante. L’usage de Calendar doit être réservé aux calculs sur les dates, et donc être circonscrit à la classe CalendarUtil.

Je ne traite pas de la question des fuseaux et des locales, mais je recommande là encore une approche fonctionnelle

Par ailleurs, les plus perspicaces d’entre vous aurons remarqué que la méthode incrémenter() de CalendarUtil peut entrainer une conflit de signature. C’est le cas si l’on a besoin d’ajouter des mois ou des années à une date.

Dans ce cas, je recommande de suivre les préconisations de Stephan Schmidt :

public static Date incrementer(Date date, NbJours jours) {
}
public static Date incrementer(Date date, NbMois mois) {
}
public static Date incrementer(Date date, NbAnnees annees) {
}
public class NbJours {
    public final int value;
    public Jour(int value) {
        this.value = value;
    }
}
[...]

Ces recommandations, si elles sont suivies à la lettre, vous éviterons bien des soucis tel que je peux en rencontrer actuellement avec mon vieux projet. Dernier conseil qui va de soit, vous devrez évidemment tester unitairement chaque méthode de CalendarUtil.

Lancement du projet CodeLang

Je vous annonce le lancement du projet CodeLang.

Il s’agit d’un projet extrêmement ambitieux qui vise à créer un metalangage permettant de retranscrire un document texte dans n’importe quel langage naturel, pourvu que ce langage soit supporté.

J’ai ce projet en tête depuis un certain nombre d’années, mais ce n’est que très récemment que m’est revenue la volonté de le mettre en oeuvre.

Ce projet ce compose en plusieurs phases.

Tout d’abord la rédaction d’une spécification détaillée du metalangage. En parallèle, un Modèle Conceptuel des Données précisera la structure de la base de données.

Puis lorsque les spécifications auront été rédigées, viendra la constitution des données elles-même. Ce travail sera le plus laborieux. J’envisage de le réaliser sur un mode collaboratif à l’instar de l’encyclopédie Wikipedia.

L’annonce de ce lancement se fait à un stade très embryonnaire du projet. Je dois dire que, compte tenu de l’ambition du projet, je ne peut pas affirmer avec certitude qu’il aboutira avec succès. Néanmoins, je pense avoir suffisamment muri le problème pour être convaincu de la pertinence de l’approche.

• http://code.google.com/p/codelang/

Google Chrome OS

Google lance une véritable bombe thermonucléaire sur le monopole bien gardé de Microsoft. Les rumeurs couraient bon train depuis quelques mois, et même quelques années. Personnellement je n’y croyais pas car il me semble que Google s’éloigne de son coeur de métier, mais il faut avouer que je ne suis pas insensible à l’idée de voir un challenger de poids proposer une alternative sérieuse à Windows.

J’aime beaucoup le navigateur Chrome et j’ai hâte qu’il soit disponible en version stable pour Linux. Ce qu’ils ont fait avec Chrome montre que les ingénieurs de Google ont des idées neuves et le talent pour les mettre en oeuvre. Pour Chrome OS, le défi est d’une toute autre ampleur et l’ambition clairement affichée. Créer un OS fiable, rapide et conviviable. Je suis certain que les ingénieurs de Google sauront répondre à chacun de ces critères.

C’est une bonne chose que Google ait décidé de développer un OS spécifique pour le marché des PC car celui-ci a des exigences différentes en matière d’ergonomie que les téléphones portables. Cela permettra d’ailleurs aux équipes d’Android de concentrer leurs développements sur le marché très prometteur des terminaux mobiles, et aux équipes de Chrome OS de travailler sur l’ergonomie propre aux PC.

Google a une vision de l’informatique diamétralement opposée à celle de Microsoft. Il sera donc intéressant de voir la concrétisation de cette vision car elle apportera un regard nouveau sur notre relation à la machine. Microsoft base son modèle économique sur la notion de biens et de possession alors que Google met en avant les possibilités en matière de services et de mutualisation qu’offrent les réseaux. Il y a autant de différence entre le modèle économique de Microsoft et celui de Google qu’entre la notion d’économique primaire et tertiaire.

Je suis ravi que Google assume sans complexe son rôle de challenger de Microsoft car cela va mettre un terme à l’économie de rente qu’est devenue le marché des systèmes d’exploitation pour favoriser au contraire l’innovation.

Swinger 0.4.1 is released

Comme le titre l’annonce, j’ai livré une version intermédiaire qui ajoute le support des layouts managers. Il est donc possible de choisir son layout, ce qui n’était pas le cas auparavant.

Cette version corrige également un bug concernant le chargement des scripts groovy à partir d’une librairie externe.

Le choix de mon parser CSS (2)

Voila quelques semaines, j’avais décidé d’implémenter les CSS dans le framework Swinger. Je savais que je me lançais dans une tâche ardue. Je m’étais fixé comme objectif de livrer une version ce mois de juin.

Avec l’arrivée du mois de juillet, je dois dire que le choix du parser Batik est un échec, je ne serai pas en mesure de tenir les délais. La raison est que je me suis rendu compte à l’intégration que mon modèle ne collait pas avec celui de Batik. Je m’attendais à un parser plus facilement exploitable, en fait il a été développé dans une philosophie assez rigide et difficile à cerner car mal documentée.

Mais la vraie raison de cet échec est que je ne me suis pas donné suffisamment de temps pour étudier cette api. La conséquence est que je me retrouve confronté à une impasse. Je n’ai que deux options qui s’offrent à moi. Soit détricotter mon code pour me conformer aux attendus de Batik, soit abandonner cette api et développer mon propre parser.

C’est la deuxième option que je choisi. Pour plusieurs raisons. D’abord cela m’ennui de renoncer à plusieurs semaines de travail. Le code que j’ai produit est loin d’être parfait et devrait pêcher par manque de performance dans le cas de CSS très complexes. Mais il est bien à adapté à l’architecture de Swinger qui repose sur des Accessors qui attendent des chaînes de caractères pour l’initialisation des attributs.

L’autre raison qui me trotte dans la tête depuis deux ou trois semaines est que je souhaite que l’api Swinger puisse être intégrée comme bundle Osgi. Or dans ce cas, les librairies externes sont un handicap si elles ne sont pas elles-même livrées en tant que bundles.

Pour ces raisons, je n’ai pas de regret à me séparer de Batik. La conséquence est que cela va retarder sensiblement la livraison d’une version supportant les CSS. Du coup, je vais livrer dans les semaines qui viennent une version intermédiaire qui permettra de choisir son layout. C’était en effet le point de départ de ma réflexion sur la configuration des attributs apparents.

Je ne suis pas en mesure de fixer de date quand au support des CSS. Ce qui est certain est que ce support sera partiel et portera sur quelques attributs seulement. Les aspects les plus délicats, comme le positionnement relatif des composants, sera reporté à une version ultérieure. En tout état de cause, le support de CSS ne sera jamais complet car la philosophie de l’api swing ne permet pas par exemple de gérer le texte de la même manière qu’en html.

Sans fournir de date buttoir en raison des beaux jours dont je profite autant que possible, j’espère néanmoins finir mon parser avant la fin du mois de juillet.

Je vous tiendrai au courant de l’arrivée de la prochaine release dans les semaines à venir qui supportera la personnalisation des layouts.

Refactoring de Swinger

Je n’ai pas encore pu commencer les tests d’intégrations car j’ai rencontré quelques soucis d’architecture. Je me suis rendu compte que l’ajout d’un attribut au modèle m’obligeait à reporter cette modification à chaque classe de composant, ce qui est évidemment aberrant. J’ai donc réécrit une partie de mon api en utilisant un Decorator ce qui rend l’architecture beaucoup plus saine. Cela va m’obliger à mener des tests de non-régression car ce refactoring n’est pas sans risque vu qu’il touche au coeur de l’api. J’espère néanmoins tenir les délais que je me suis fixé et livrer la version 0.5 avant la fin de ce mois de juin.

Cette livraison portera sur une implémentation basique de CSS avec le support de quelques attributs seulement. Je n’ai pas encore pris de décision définitive pour la configuration du layout. Ce qui est certain est qu’il sera finalement possible de le configurer dans le fichier xml, mais je ne suis pas sûr de vouloir ajouter une propriété non standard à CSS.

J’avais un temps envisagé d’ajouter une balise <layout>, mais à bien y réfléchir cela me poserai un problème. J’ai en effet l’intention d’implémenter XPath pour permettre d’explorer le modèle. Or permettre de récupérer des valeurs de type différent apporterai un niveau de complexité supplémentaire. Je réserve donc cette possibilité à une future release.

Après l’implémentation des CSS, la prochaine étape est la possibilité de définir le modèle des composants complexes comme JTree ou JTable. Là encore, je n’utiliserai pas de balise comme cela se fait avec les tableaux HTML. La définition du modèle se fera dans un premier temps avec un format de fichier texte du type CSV, puis avec un format XML dans une release ultérieure.

Implémentation du pattern IoC

J’ai eu le temps dans le train de réfléchir à quelques problèmes qui s’annoncent dans l’évolution à venir de Swinger. Jusqu’à présent, j’ai laissé de côté les composants complexes de Swing tels que les JTree ou encore les JTable. La raison est que cela nécessite de pouvoir spécifier des valeurs à insérer dans le model comme dans le cas des tables en HTML. J’avais commencé à introduire une balise <item> qui était utilisée pour les JList, mais je suis finalement revenu en arrière car l’approche n’était pas la bonne. Les items ne font pas partie de la couche Vue mais de la couche Model. Il n’était donc pas judicieux de traiter communément ces deux types d’élément.

La solution que j’adopterai du point de vue du langage sera l’introduction des namespaces. Ils permettront d’identifier les différentes couches de l’api Swing. Du point de vue de l’implémentation, je suis toujours confronté à la nécessité de différencier les traitements associés à ces couches. Pour cela, j’adopterai une implémentation simplifiée du pattern Inversion of Control.

Prenons comme hypothèse de départ que vous êtes en présence d’une architecture dans laquelle l’implémentation d’une responsabilité varie selon le type de composant passé en paramètre.

Plutôt que d’implémenter la responsabilité dans une seule méthode avec des vérifications de casting, je dispatch la responsabilité dans des méthodes différentes selon le type d’objet à traiter, et je délègue l’appel de la méthode idoine au niveau des composants subalternes.

Typiquement, l’implémentation sera celle-ci :

public class Child1 implements IoC {
    @Override
    public void delegate(Parent parent) {
        parent.method1();
    }
}

public class Child2 implements IoC {
    @Override
    public void delegate(Parent parent) {
        parent.method2();
    }
}

Cette approche me permettra de conserver le caractère modulaire de Swinger. Tout type de composant pourra être ajouté à un parent, ça sera le composant fils qui déterminera de quel manière il sera ajouté à son parent. Actuellement, seule la méthode Container.add() est utilisée. Avec cette nouvelle architecture, il sera même possible d’ajouter un layout à un conteneur grâce à une balise. Je rappelle que c’est ce problème qui m’avait amené à l’origine à implémenter CSS. Je n’ai pas pour autant l’intention d’abandonner CSS car je pense que cela apportera une plus grande simplicité dans la création d’IHM.