Expertise Java & J2EE

Sélectionner les premiers N rangées dans MS SQL, Oracle et DB2

Thu, 28 May 2009 20:45:45 +0200

Comment faire les requêtes SQL qui ne retournent que les premiers n rangées?

Déjà il faut comprendre que les rangées ne sont pas stockées physiquement dans un ordre quelconque. Il est donc essentiel de spécifier un ORDER BY dans la requête. Cela dit, regardons comment faire un SELECT qui ne retourne que les premiers n résultats trouvés (dans tous ces exemples, n = 10):

MS SQL Server

SELECT TOP 10 NOM, DESCRIPTION
FROM MATABLE
ORDER BY NOM ASC

Il y a des fortes chances que cela marche sous Sybase aussi, mais je n'ai pas eu l'occasion de tester.

Oracle

SELECT * FROM
(SELECT NOM, DESCRIPTION
FROM MATABLE
ORDER BY NOM ASC)
WHERE ROWNUM <=10

(On doit imbriquer la requête dans Oracle, car si on suivait directement la clause WHERE par la clause ORDER BY, sans parenthèses, la BDD prendra les premiers résultats, aléatoires, et ensuite les triera. Ce qui n'est pas ce qu'on veut faire.)

DB2

SELECT NOM, DESCRIPTION
FROM MATABLE
ORDER BY NOM
FETCH FIRST 10 ROWS ONLY
OPTIMIZE FOR 10 ROWS

Et voilà. C'est dommage qu'il n'y a pas de façon uniforme de faire ces requêtes, mais ce n'est pas trop compliqué une fois qu'on connaît les variantes.

Les trois plugins Firefox les plus incontournables

Thu, 2 Apr 2009 07:07:07 +0200

Grâce à son architecture extensible et son licence open source, le navigateur Firefox est devenu un des outils les plus utiles pour les développeurs web. Nul autre outil permet tellement facilement de tester des sites web, et de diagnostiquer ce qui ne va pas en cas de mauvais affichage, et tout cela gratuitement. En voici les trois plug-ins qu'il vous faut installer pour transformer votre navigateur Firefox dans un outil puissant de développement.

1. Firebug. La transition de HTML classique vers CSS nous a permis de séparer contenu et présentation. Tout cela est génial, mais comment est-ce qu'on s'en sort quand on a plusieurs feuilles de style avec des centaines de classes, et on doit trouver pourquoi tel <div> se trouve pas au bon endroit? Firebug permet de voir, simplement en passant le souris sur la page, toutes les classes css qui s'y appliquent, et lesquelles sont priorisées au-dessous des autres. Débugger le css serait un cauchemar si on n'avait pas Firebug.

2. Selenium. Marre de remplir les formulaires pour tester les différents parcours de votre application? Selenium permet, à la manière de jUnit, de sauvegarder vos parcours et de les rejouer automatiquement. Un outil très mûr et facile à adapter à vos besoins (exportation des tests en java, intégration ant, etc.), Selenium est indispensable pour tester vos applications web.

3. LiveHttpHeaders. Des fois, le serveur ne se comporte pas comme on s'y attend et on a du mal à comprendre pourquoi. Le plugin LiveHttpHeaders permet de voir, pour n'importe laquelle page internet, les en-têtes HTTP que votre navigateur a envoyé avec sa requête, et aussi les en-têtes de la réponse serveur. C'est rare qu'on en a besoin, mais c'est extrêmement utile à avoir lorsque, par exemple, on a des comportements différents en recette et en production et qu'on soupçonne qu'une configuration WebSphere ou Apache est derrière le problème...

Garder les fichiers generes de vos JSP dans WebLogic

Fri, 13 Feb 2009 20:02:02 +0100

Par défaut Weblogic supprime les fichiers .jsp qui sont générés lors de la phase de traduction d'un JSP. Il ne garde que les fichiers .class qui sont compilés par la suite. Néanmoins, en développement ces fichiers .java peuvent s'averer très utiles. Par exemple, lors d'une exception dans le JSP, la trace donnera la ligne exact du fichier .java où l'exception a eu lieu. Si on a le fichier .java, on peut souvent trouver plus rapidement qu'est-ce qui s'est passé, ce qui est plus facile que de relire tout le JSP en essayant de voir qu'est-ce qui a pu tourner mal (sans numéro de ligne).

Pour dire à Weblo de ne pas supprimer ces fichiers .java, donc, on ajoute le texte suivant dans le weblogic.xml de votre application :

<jsp-descriptor> <precompile>false</precompile> <precompile-continue>false</precompile-continue> <keepgenerated>true</keepgenerated> <verbose>true</verbose> <working-dir>/tmp/bea</working-dir> </jsp-descriptor>

Notez bien que vous pouvez spécifier le dossier où vous voulez stocker les fichiers .java avec la balise <working-dir>.

Garder les fichiers générés de vos JSP dans WebLogic

Fri, 13 Feb 2009 07:02:02 +0100

Pour dire à Weblo de ne pas supprimer ces fichiers .java, donc, on ajoute le texte suivant dans le weblogic.xml de votre application :

Notez bien que vous pouvez spécifier le dossier où vous voulez stocker les fichiers .java avec la balise <working-dir>.

html:checkbox ne marche pas

Fri, 1 Aug 2008 00:01:01 +0200

Si vous travailler assez longtemps avec Struts, tôt ou tard vous allez le constater : <html:checkbox> ne marche pas. Ou bien s'il marche, son comportement est trop complexe et non-intuitif pour qu'il soit utile.

Que faire ? La solution peut sembler radical, mais je vous le conseille vivement : il faut s'en passer tout simplement. Avec un peu de JavaScript, ce n'est pas si brutal que ça. Au lieu de mettre :

<html:checkbox property="champs" />

On met :

<input type="checkbox" id="champs2" onchange="Util.setValue('champs', $('champs2').checked);" /> <html:hidden property="champs" /> <script> Util.setValue('champs2', Util.getValue('champs')); </script>

Et c'est tout. (J'utilise mon propre classe "Util" pour le JavaScript, mais son fonctionnement est clair.) Nos actions récupèrent le champs pareil, qu'il soit dans un checkbox ou un hidden, et la champs s'initialise et garde sa valeur comme on le voudrait.

Un look and feel Swing pas comme les autres

Thu, 31 Jul 2008 07:07:03 +0200

Napkin est un "Look and Feel" (LAF, synonyme de skin ou thème) qu'on peut installer pour Swing qui répond à un besoin tout à fait original: souvent en tant que développeurs, on veut présenter aux clients une maquette de ce qu'on pense réaliser comme intérface graphique de leur logiciel. Mais les clients, ne connaissant pas l'informatique, voient une maquette qui ressemble à ce qu'ils veulent, et disent "on le prend comme ça!" Après il est difficile de leur faire comprendre que ce n'est qu'une maquette, et il reste beaucoup de développement encore derrière à réaliser.

Napkin nous permet de montrer clairement que l'intérface qu'on est en train d'utiliser n'est qu'un prototype. Et comment le communique-t-il? Le plus naturellement possible! Napkin permet de dessiner n'importe lequel interface Swing comme si c'était dessiné sur une serviette en papier! Une capture d'écran parle plus fort que les mots :

Et le plus beau dans tout ça? Ce n'est qu'un Look and Feel, donc l'application reste 100% fonctionnel. On peut même faire tourner NetBeans sur une serviette en papier :

Pour un prototype, donc, ce LAF permet de montrer clairement qu'il ne s'agit que d'un prototype—mais, une fois le prototypage fini, il suffit d'enlever le LAF et on a notre application, toute sage et professionnelle avec le Look and Feel par défaut. C'est malin!

Astuce: utiliser extends avec les génériques

Wed, 21 May 2008 22:51:21 +0200

(L'idée pour cet article vient d'un blog en anglais de John Zukowski.)

Java 5 a introduit au langage Java les génériques, et depuis il est devenu beaucoup plus agréable de coder en Java. Alors qu'avant on avait un objet List, et chaque fois qu'on itérait dessus il fallait se souvenir du type des objets qu'on avait mis dedans pour faire un cast ("String s = (String) s.iterator().next();"), maintenant on peut simplement déclarer qu'on a un List<String> et ce n'est plus nécessaire d'avoir des casts partout.

Cependant, il y a un comportement bizarre qu'on constate avec ces génériques lorsqu'on veut en utiliser comme paramètre à une méthode. Regardons un petit exemple :

public static void main(String[] args) { List arg = new ArrayList<String[]>(); String[] a = {"a", "b", "c"}; String[] b = {"d", "e", "f"}; arg.add(a); arg.add(b); System.out.println("Notre liste applati a " + applatirList(arg).size() + " éléments"); return; } private static List applatirList(List<Object[]> list) { List result = new ArrayList(); for (Object[] array : list) result.addAll(Arrays.asList(array)); return result; }

Mais quand on compile ce programme, on a l'erreur "Test.java:19: applatirList(java.util.List<java.lang.Object[]>) in Test cannot be applied to (java.util.List<java.lang.String[]>)". En effet, contrairement au comportément des objets en général, les génériques par défaut ne sont valables que pour le classe même, mais pas forcément ses classes filles ! (J'avoue que je trouve ce comportement un peu illogique, mais c'est le compilateur qui décide.)

La solution, c'est de modifier notre signature de méthode comme suit :

private static List applatirList(List<? extends Object[]> list)

Maintenant la méthode acceptera n'importe lequel type de liste, de moment que son type générique est Object[] ou une classe fille de Object[].

Pensez donc à utiliser ? extends avec vos génériques pour rendre plus souple vos interfaces!

Diagrammes de séquence UML : percer le mystère

Sun, 18 May 2008 10:35:16 +0200

Très répandus, mais aussi très mal compris, les diagrammes de séquence sont pour moi une des parties le moins bien compris de l'UML. Cette mécompréhension mène beaucoup d'analystes d'études à finir par s'en passer complètement, en préférences d'un usage exclusif des diagrammes d'activité pour modéliser le comportement de leurs projets.

Ce phénomène révèle une première mauvaise idée reçu, car les diagrammes d'activité et les diagrammes de séquence devraient intervenir dans le projet à des stades complètement différentes !. En effet, le diagramme d'activité, plus générale, sert à définir le déroulement d'un cas d'utilisation. Il est donc utile au moment de la spécification où les besoin fonctionnels deviennent figés pour les acteurs techniques on concrétise ce que le logiciel va faire. ("Voici ce qui va se dérouler dans le programme.) Et, effectivement, pour modéliser ces déroulements les diagrammes d'activité sont faciles à lire et très utiles.

Les diagrammes de séquence n'ont rien à faire à ce stade. Les acteurs fonctionnels dans le projet n'y comprendront rien, et ceci pour une bonne raison: les diagrammes de séquence existent pour modéliser le comportement technique. Ils doivent donc intervenir lors de la conception technique de l'application: les diagrammes de séquences sont étroitement liés à la code source de projet, et non pas aux cas d'utilisation au sens métier.

La deuxième chose qu'il faut donc comprendre c'est que, comme le diagramme de séquence est un modélisation technique et non pas fonctionnel, cette modélisation revient à faire de la programmation visuelle. Et comme telle, pour bien faire un diagramme de séquence, il faut avoir une connaissance profonde de la programmation orienté objet.

Déjà pour poser le premier élément du diagramme, l'objet, il faut comprendre le cycle de vie de l'objet, car il est modéliser par la ligne pointillé: il descend, non pas systématiquement du haut en bas du diagramme comme on voit souvent, mais uniquement aussi loin que l'objet modélisé n'existe. Le début represente la création de l'objet ; lorsqu'il est détruit (manuellement dans des langages comme C++, ou bien conceptuellement dans tous les cas), son trait s'arrête.

Le deuxième chose que beaucoup d'analystes comprennent mal c'est les rectangles qui se posent sur ces lignes de vie. Alors que, pour un programmeur, il n'y a rien de plus simple: ça veut dire que la méthode est en train d'exécuter. Quelle méthode? Mais la méthode indiqué sur la flèche stimulus, bien sûr! En effet, ces flèches doivent être utilisées pour définir les appels des méthodes eux-mêmes, et les blocs sur l'objet montrent l'espace de temps où il est en train de s’exécuter activement. C'est donc pour ça que ces diagrammes sont étroitement liés à la code source :

Je peux dire ça dans d'autres mots pour ceux qui sont peut-être plus orienté développement: imaginez le diagramme de séquence comme un schéma visuel de ce qui se passe lorsque vous passez sur un point de débogue. Chaque flèche représente un appel de méthode que vous suivez, et le rectangle représente l'espace de temps que le méthode s’exécute jusqu'à son return. Ce rectangle s’agrandira, donc, si notre méthode appelle d'autres méthodes (sur ce même objet ou un autre). Le rectangle finit lorsque notre appel se retire du call stack.

Lu comme ça, on voit qu'un diagramme de séquence n'est pas du tout un diagramme d'activité difficile à lire! Au contraire, c'est une représentation très lisible des détails au niveau du code qui ne seraient jamais modélisables sur les diagrammes de classes, et qui ne sont pas spécifiés par les diagrammes d'activité. C'est un diagramme qui répond à la question: quel est l'enchaînement des appels des méthodes, sur quels objets, et dans quel ordre?

J'espère que ces points aideront à mieux comprendre ce diagramme et son rôle utile dans la documentation d'un projet informatique. Si vous avez des questions ou si vous n'êtes pas d'accord avec mon point de vue, n'hésitez pas à laisser un commentaire ci-dessous).

Tester des Web Services avec une interface graphique

Fri, 21 Mar 2008 07:02:32 +0100

Comme un Web Service n'a par définition aucune interface utilisateur, on ne peut pas facilement interagir avec lui sans avoir un outil spécial. Idéalement cet outil devrait permettre de composer des requêtes SOAP directement en XML, et de visualiser les réponses SOAP que le serveur nous renvoie. Un outil excellent, et gratuit, que j'ai déjà eu l'occasion d'utiliser est SoapUI. Voici rapidement ce que ce logiciel permet de faire :

Inspecter les Web services (en local ou sur le réseau)
Invoquer des Web services
Développer des Web services (directement dans l'outil)
Tester des Web services (y compris des testes de capacité)

En plus, c'est un logiciel Java et donc disponible sur Linux, Windows, et Mac OS X. Et encore mieux, en plus du logiciel à part, des plugins existent pour l'intégrer dans Eclipse, NetBeans, et IntelliJ. Donc, quel que soit votre EDI préféré, SoapUI peut s'intégrer dedans.

La clause IN dans un PreparedStatement

Thu, 20 Mar 2008 22:20:03 +0100

Récemment un lecteur m'a posé la question suivante: «Je veux saisir un argument pour une clause IN dans une requête SQL. Mais je ne sais pas dans quel format il faut mettre la chaîne. J'ai essayé :

public ResultSet executerSQL(String[] arg) { PreparedStatement ps = conn.prepareStatement( "SELECT * FROM TAB WHERE TAB.LIBELLE IN (?) "); ps.setArray(1, arg); ...

Mais ça ne marche pas! Qu'est-ce qu'il faut faire ? »

Ce qu'il faut comprendre, c'est que le "?" dans un PreparedStatement ne peut pas être employé pour remplacer n'importe laquelle chaîne plus tard. Chaque "?" doit correspondre à une donnée qui sera liée à un valeur avant de lancer la requête. (conn.prepareStatement() va compiler l'SQL fourni, alors le nombre d'arguments doit être fixe.)

Il en résulte qu'il est impossible d'avoir un nombre variable d'arguments pour un PreparedStatement une fois que celui-ci est créé. La seule solution est de générer le SQL dynamiquement. Imaginons que notre méthode reçoit en argument un String[] pour la clause IN. On peut donc écrire la requête de l'exemple précédent comme ça:

public ResultSet executerSQL(String[] arg) { PreparedStatement ps = conn.prepareStatement( "SELECT * FROM TAB WHERE TAB.LIBELLE IN " + getInClause(arg.length)); for (int i = 0; i < arg.length; i++) ps.setString(i + 1, arg[i]); ... } private String getInClause(int length) { StringBuffer sb = new StringBuffer("("); for (int i = 0; i < length; i++) sb.append(i + 1 == length ? "?)" : "?,"); return sb.toString(); }

Certes, ce n'est pas aussi beau que ça n'aurait été si on pouvait utiliser setArray(), mais c'est la seule façon qui est permise.

Comment intéroger un répertoire LDAP avec Java

Fri, 14 Mar 2008 23:38:30 +0100

Lightweight directory access protocol (LDAP) est une technologie extrêmement repandu en entreprise pour les annuaires. Typiquement, lorsque l'autentification des utilisateurs sur une application intranet passe par l'annuaire LDAP, on configure celui-ci avec JAAS dans le web.xml. Mais ceci n'est pas le sujet de cet article. Ici je veux traiter du cas où l'on veut intérogger directement un serveur LDAP et y lancer des recherches, ce qui peut être le cas quand on veut afficher des données qui sont dans l'annuaire, par exemple.

Il se trouve que c'est extrêmement simple de communiquer avec LDAP en Java, surtout parce que toutes les librairies nécessaires sont déjà présents dans le JVM, dans les packages javax.naming. Il n'y a donc rien à installer, même dans une application Java SE.

Une connexion LDAP est représenté par un objet DirContext, typiquement instantié par un InitialDirContext qui prend dans son constructeur un Hashtable contenant les paramètres de connexion. Voici l'incantation magique :

Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldap://example.com:3060/"); env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_PRINCIPAL, "cn=test,cn=Users"); env.put(Context.SECURITY_CREDENTIALS, "password"); DirContext ctx = new InitialDirContext(env);

Cet exemple connecte un utilisateur appelé "test" avec un mot de passe "password" au serveur "example.com". Il assume aussi que les utilisateurs se trouvent dans un dossier qui s'appelle "Users". Evidemment ces paramètres sont à modifier en fonction de l'annuaire qu'on veut consulter et sa structure.

Ensuite, on peut passer des requêtes à notre objet ctx. Le syntaxe pour une requête LDAP sera facile à comprendre pour ceux qui connaissent bien le langage Lisp ; malheureusement cette connaissance est de plus en plus rare alors une explication sera peut-être nécessaire...

Les parties de la requête sont regroupés entre parenthèses, avec un opérateur tout de suite après le parenthèse d'ouverture, et les arguments après. Alors là où dans Java ou C on écrit

(a && b && (c || d))

en LDAP ça devient

(& a b (| c d))

Les opérateurs sont & (AND), | (OR), et ! (NOT). Les arguments sont de forme "clef=valeur", où "valeur" peut contenir des étoiles (par exemple, "nom=Dup*"). Les arguments sont eux-même entourés des parenthèses. Voici un exemple complet d'une recherche lancé sur notre ctx, qui est le DirContext qu'on a créé dans le premier exemple :

SearchControls controls = new SearchControls(); controls.setSearchScope(SearchControls.SUBTREE_SCOPE); NamingEnumeration results = ctx.search("", "(&(uniquemember=cn=test,*)(objectclass=groupofUniqueNames))", controls);

La recherche retourne un NamingEnumeration, qui implémente Enumeration et qui est donc facile à itérer.

Et voilà, à vous d'employer les données retrouvés comme bon vous semble dans votre application. N'oubliez pas d'appeler un ctx.close() pour fermer votre connexion quand vous n'en aurez plus besoin!

Gestion des trunk, branch, et tags dans Subversion

Tue, 11 Mar 2008 07:27:17 +0100

Subversion est actuellement parmi les solutions de gestion de versions les plus employés de nos jours. Une organisation typique de projet avec Subversion utilise ce qu'on appelle un "trunk", des "branches", et des "tags". Dans cet article j'explique brièvement ces termes.

Le trunk (tronc en français) est, comme son nom l'indique, le projet principal. Si on veut faire du développement en parallèe (ce qui arrive souvent, par exemple, quand on a livré une version, qu'on continue à maintenir pour corriger des éventuels bogues, mais on prépare en parallèle une version 2.0 avec plein de nouvelle fonctionnalités), on met ces "branches" dans, comme on pourrait le deviner, un branch.

Un tag, quant à lui, est une balise, qu'on peut appliquer à une révision pour l'identifier plus facilement—pour dire, «ça, c'est la version 1.2», par exemple. Un tag n'est en réalité qu'un branch qu'on ne modifie jamais, mais on les met à part parce que conceptuellement les deux sont très différents.

Un dossier subversion aura donc typiquement trois dossiers à la racine, branch, tags, et trunk, avec une copie du projet dans trunk, et d'autres copies dans des sous dossiers de branch et/ou tag selon les besoins et l'évolution du projet.

Comment générer des PDFs très longs avec JasperReports

Sat, 9 Feb 2008 07:37:36 +0100

La solution Open Source JasperReports est déjà bien connu et bien respecté dans l'informatique d'entreprise pour générer des reports, sous format .pdf, Excel, html, et autres. Sur un projet récent, on avait cependant un problème: nous nous retrouvions avec un pdf à générer qui faisait plus de 700 pages, et le pauvre serveur chargé de le produire plantait en OutOfMemoryError. Après débogage, on a vu que le coupable était JasperReports lui-même, qui plantait lors de la création du JasperPrint. Ma première réaction était donc d'éviter de créer un JasperPrint, et d'utiliser des méthodes qui permettent de créer un report directement avec des InputStream et OutputStream. Mais l'utilisation d'un PipedInputStream oblige déjà l'utilisation des Threads, ce qui n'est pas strictement permis dans une application J2EE (la gestion des threads étant le domaine du serveur). Mais même avec ces modifications, les problèmes des OutOfMemoryError persistaient. Heureusement la solution s'est ensuite présentée, et donc dans ce petit article, je vais expliquer comment on peut utiliser JasperReports pour créer des documents de n'importe laquelle taille, sans avoir des soucis de mémoire.

La solution qui a finalement marché était moins radicale que cette première idée. En fait on continue à utiliser un JasperPrint, alors les effets sur le reste notre code étaient minimes. Il suffisait en effet d'ajouter les lignes suivantes juste avant sa création:

JRSwapFile swapFile = new JRSwapFile("/tmp/", 0x400, 0x400); JRAbstractLRUVirtualizer virtualizer = new JRSwapFileVirtualizer(0x40, swapFile, true); parametres.put(JRParameter.REPORT_VIRTUALIZER, virtualizer); JasperPrint print = JasperFillManager.fillReport( jasper, /* notre fichier .jasper compilé */ parametres, /* notre Map des paramètres */ new JRBeanCollectionDataSource(donnees)); /* notre Collection des données */

(La dernière ligne est inchangée de notre classe d'origine, mais je l'inclus pour vous donner le contexte.) Que font ces trois nouvelles lignes? En fait, notre ancienne solution plantait parce que le JasperPrint qu'on gardait en mémoire était trop grand. Les Virtualizer de JasperReports permettent de déclarer des fichiers tampons, qui sont utilisés par Jasper pour écrire une partie de ses données sur disque. En ajoutant un virtualizer dans le Map des paramètres, Jasper va automatiquement se servir de cette fonctionnalité (dans notre cas, en écrivant un fichier tampon dans le dossier temporaire /tmp/; il existe aussi d'autres types de Virtualizer).

Dans notre projet, le simple ajout de ces trois lignes supplémentaires a suffit pour qu'on sorte nos .pdf de plus de 700 pages sans problème. Les vrais experts de JasperReports remarqueront quand même qu'on utilise un JRBeanCollectionDataSource, ce qui implique que nous avons une Collection en mémoire avec nos données. On peut imaginer que, si notre rapport était vraiment énorme (disons 7000 pages), on n'aurait pas assez de mémoire pour stocker toutes ces données en mémoire. En effet, si le volume des données est trop important, il faut implémenter un JRDataSource qui permet de lire les données un à un, au lieu de tout prendre en mémoire à l'avance. (JRResultSetDataSource répond déjà à ce critère.)

Si on fait attention sur ces deux points, d’utiliser un JRDataSource extensible, et d’inclure un REPORT_VIRTUALIZER dans les paramètres fournis au JasperFillManager, on pourra créer des JasperReports extrêmement volumineux sans avoir à se soucier de l'utilisation de mémoire.

Comment déclencher du JavaScript après n secondes

Fri, 8 Feb 2008 18:41:32 +0100

Dans certains cas, on peut avoir une bonne raison de vouloir déclencher du JavaScript après un délai de 10 secondes, par exemple. On sait, j'espère, qu'il ne faut jamais utiliser un boucle qui ne fait rien pour compter le passage du temps ! Mais alors, comment faire ça correctement? Heureusement il existe en JavaScript un moyen très facile et propre de le faire:

var delai = 5; /* Cinq secondes */ var apres = function () { alert(delai + 'secondes se sont pass\351es!'); } setTimeout(apres, delai * 1000);

Et voila, c'est tout ce qu'il faut pour que notre fonction apres se déclenche après 5 secondes. Pour résumer, la fonction JavaScript setTimeout prend donc une fonction en premier argument, et un délai en second argument, exprimé en millisecondes. Facile! Cliquez ici pour le voir en action.

Voir aussi :

Besoin de vous rappeler des accents comme le \351 dans l'exemple? Trouver un tableau complet ici.

À la recherche d'un bon plugin JavaScript pour Eclipse? Essayez JSEclipse.

NetBeans 6 est sorti

Mon, 10 Dec 2007 18:22:22 +0100

La nouvelle version de NetBeans, mon EDI préféré, est maintenant disponible. La nouvelle version comporte plein de nouvelles fonctionnalités et améliore beaucoup de choses par rapport à la version 5.5. Un des plus grandes nouveautés est l’inclusion des modes pour travailler avec le langage du moment Ruby et son framework Rails.

La seule chose qui m’embête encore chez NetBeans, c’est que la Moblity Pack, qui permet de développer pour des téléphones portables, n’est pas disponible sur Mac OS X, même avec un processeur Intel. J’espère que cela changera un jour car tout mon developpement personnel se fait sur mon iMac maintenant et je ne peux plus donc faire du developpement mobile du tout à la maison. Mais bon, c’est le cas pour Eclipse aussi alors ce n’est pas vraiment la faute de NetBeans.