(Ne sont pas listées les bibliothèques archi-connues comme Spring, Hibernate, hsqldb...)
Traitement automatique des languages et automates
Vu dans http://www.java.net/external?url=http://www.oracle.com/technetwork/artic...
com.sun.awt.AWTUtilities.setWindowOpacity(window, 0.5f);
et hop, une fenêtre transparente !
Sympa. Gadget, mais sympa.
Un peu de philosophie... Dans les sources de JSesh, on trouve actuellement un petit framework applicatif (org.qenherkhopeshef.guiFramework).
Celui-ci a été créé avec dans l'idée de disposer d'un système simple, indépendant de tout IDE, pour créer des applications multilingues.
Dans ce framework, l'exécution des actions est déléguée à un objet de type façade. Je me base sur une classe proposée dans un article de Hans Muller sur java.net.
Cette classe, BundledAction, représente une action
This is the home page for the Java Library JVectCutAndPaste. This library provides :
Le frameword Spring inclus dans Netbeans 6.5.1 ne fonctionne pas très correctement avec Glassfish, inclus dans le même Netbeans.
Plus exactement, la balise <form:form> donne une URL qui référence la jsp qui sert de vue et non le FormController (les personnes potentiellement intéressées par ce message comprendront).
Pour faire correctement fonctionner les formulaires, il suffit de récupérer une version récente de Spring (la 2.5.6 par exemple), et d'utiliser ces jars là au lieu de ceux fournis avec netbeans.
Quelques notes personnelles sur la marche à suivre
Opérations à mener pour faire un site Drupal multilingue:
a) activer localization (être bien sûr qu'on le fait depuis un compte d'administration, ou qui aura les droits nécessaires)
b) charger les langues désirées.
c) activer les parties désirées de i18n
d) aller dans "Multilingual system"
- activer "browser language detection".
Comme la documentation sur les formulaires d'openoffice n'est pas vraiment facile à trouver, je vais mettre ici mes remarques sur les problèmes rencontrés.
Vous avez intérêt à mettre les noms des champs et des tables en MAJUSCULE. Oui, c'est lourd, illisible, et pas beau.
Il semble (il faudrait que je cherche les standards pour ça) que les noms des tables soient réputés être en majuscule. Sinon, openoffice n'est pas content. Ou plus exactement, certaines parties d'openoffice ne sont pas contentes.
Il y a un bug ennuyeux dans les JTables. Quand on met en place un éditeur spécifique pour une case, par exemple un JCombobox (ou plus exactement un DefaultCellEditor auquel on passe un JCombobox), si la case est détruite, l'édition continue quand même. On se retrouve alors avec un éditeur actif placé sur une case qui n'a plus rien à voir.
J'ai trouvé sur le web deux solutions:
En développant un dictionnaire hiéroglyphique, j'ai le problème suivant: je souhaite utiliser des JList et/ou des JCombobox pour afficher la liste des mots (avec un Renderer adapté). Hélas, le résultat est très lent. Que se passe-t-il ?
En fait, Swing gère au départ des liste dont les éléments peuvent avoir des tailles très diverses (mettons une liste d'images, par exemple). Résultat: il est impossible de calculer rapidement la taille de la liste. La seule solution est donc de simuler le dessin de la liste dans son intégralité. Et chez moi, ça prenait un temps certain.
J'ai un panneau avec deux listes, et je désire faire passer des éléments de l'une à l'autre. Une solution simple est bien entendu d'utiliser deux boutons.
L'utilisateur souhaitera certainement pouvoir effectuer des sélections de manière différente: