Prototype est gratuit et simplifie beaucoup la vie pour la portabilité. De plus, son utilisation nos protège contre des erreurs de programmation JavaScript courantes. Bien que je l’ai rapidement adopté et que je ne regrette rien, j’ai récemment découvert qu’il y a d’autres alternatives intéressantes.

Prototype : Bien écrit, bien supporté, grande communauté d’utilisateurs. Documentation succinte, très peu d’exemples. Pour les effets visuels avec Prototype, le choix qui s’impose est Scriptaculous.

mootools : Il est très léger. (mootools library pour les effets). La plus petite lib et la plus rapide. (extJS pour les effets)

YUI (Yahoo UI) Il est lourd, c’est incroyable, mais a un nombre considérable de fonctionnalités. (bloated, overly complicated, slow).

GWT (Google Web Toolkit): Concept très attrayant. Développement en Java, puis diffusion en HTML et JavaScript par conversion du code.

JQuery: Bonne documentation. Il racourci la syntaxe au maximum. Moins de code à écrire, plus productif. Léger, architecture avec greffons le garde léger et flexible pour l’ajout de nouvelles fonctions. Fully supports CSS1, CSS2, CSS3, and basic XPath. Tons of plugins. Chainable.

dojo: Big bloat and slow, but shine with vector graphics with dojox.gfx.

Backbase : Full toolkit. Big, but nice GUI.

1. Je veux afficher le sous-graphe (de 5 à 30 sommets) d’un immense graphe de plus de 30,000 sommets. Puis, je une interface pour naviguer dans le graphe en passant, d’un sous-graphe à l’autre.
2. Je veux expérimenter des idées de GUI, donc des contrôles non standard, et partager le résultat et mes conclusions en ligne sur le Web.

Constat pour les images vectorielles statiques

Pour ces besoins, il me faut un outil qui me permet de mettre en ligne du contenu vectoriel interactif. Présentement la solution qui s’impose est Adobe Flash. Cependnat, puisque j’utilise Linux, je n’ai pas accès à l’IDE d’Adobe car ce dernier n’est disponible que pour Mac et MS-Windows. Alors, j’ai commencé à regarder les alternatives.

La technologie SVG est très prometteuse. Déjà, c’est un format largement accepté pour échanger des images vectorielles. Lorsqu’il est temps de placer ces images en ligne, FireFox à un support minimum pour le rendu SVG, il est donc préférable, pour l’instant, de convertir l’image en SWF. Pour l’impression, il est préférable de convertir l’image en PDF. Ce scénario est une solution «freeware» intéressante pour des images vectorielles statiques.

Constat pour le contenu vectoriel animé avec interaction

Maintenant, pour gérer des interactions avec l’utilisateur les solutions sont moins évidentes. Dans l’état actuel des choses, il n’y a pas de lecteur SVG largement répandu qui implante de façon fiable les interactions. De plus, il y a encore moins d’environnement intégré de développement pour produire des SVG interactifs. Bref, tout doit être codé à la main.

Une solution plus fiable consiste à produire des SWF à la main par programmation en utilisant des libraires. L’effort est grand et les résultats laissent à désirer. Néanmoins, voici quelques liens utiles pour cette approche.

Open Source Flash et deux sous liens notoires swftools et MTASC

Solution pour l’avenir

Je ne sais pas si cette solution est et sera intéressante, elle semble vouloir tout inclure dans un seul et unique langage de programmation Web. C’est très ambitieux, mais le projet est en vie et évolue. Je vais garder un œil là dessus.

haXe

J’envisage d’utiliser un seul blogue WordPress, qui sera divisé avec le mécanisme des catégories. Mon information sera centralisée, cependant, si je décide un jour d’utiliser des noms de domaine, je vais devoir faire quelques petits tours de passe-passe. De plus, je vais devoir modifier le code de présentation de WordPress, pour accommoder mes points d’entrées multiples. Ceci à l’inconvénient de rendre la mise à jour beaucoup plus laborieuse, puisqu’il faudra se souvenir de toutes les modifications et les réappliquer.

Je ne sais pas encore si je vais migrer mes blogues multiples, dans un seul point centralisé. Je suis en réflexion.

L’avantage de cette approche est sa simplicité, mais elle a ses inconvénients. Premièrement, la production de l’image se fait à chaque appel de la page. Donc peu d’espace disque est utilisé pour les images, mais une exécution est requise à chaque chargement de la page. Deuxième point négatif, la qualité du rendu est faible.

Voici un exemple d’utilisation.

Puisque je ne sais pas comment compiler TeX sur le serveur hôte, je n’ai pas accès aux autres solutions qui utilisent TeX directement. Par exemple, mathTeX produit une image de meilleure qualité, mais il faut avoir LaTeX installé sur le système. D’autre part, il y a le gadget Google «Equation editor» qui peut générer un rendu très rapidement. Voici le lien http://www.sitmo.com/latex pour l’essayer.

Pour ce qui est de mathTeX et mimeTeX c’est disponible sur http://www.forkosh.com.

Sur le client:

1. Créer le répertoire ~/.ssh, s’il n’existe pas (mkdir ~/.ssh).
2. Assigner les droits uniquement à l’utilisateur (chmod 700 ~/.ssh).
3. Générer une paire de clefs (ssh-keygen -t dsa, faire [entrée] à toutes les questions).

La clef privée est dans «~/.ssh/id_dsa» et la publique dans «~/.ssh/id_dsa.pub». Avant de poursuivre, copier id_dsa.pub sur le serveur.

Sur le serveur :

1. Créer le répertoire ~/.ssh, s’il n’existe pas (mkdir ~/.ssh).
2. Assigner les droits uniquement à l’utilisateur (chmod 700 ~/.ssh).
3. Placer la clef publique dans le fichier authorized_keys (cat id_dsa.pub >> ~/.ssh/authorized_keys).
4. Assigner les droits uniquement à l’utilisateur (chmod 700 ~/.ssh/authorized_key).

Voilà, la connexion avec ssh et scp ne devrait plus demander le mot de passe. Si ce n’est pas le cas, on peut vérifier le déroulement des opérations d’authentification avec «ssh -v» pour tenter d’isoler le problème.

cvs -z3 -d:pserver:anonymous@vim.cvs.sf.net:/cvsroot/vim checkout vim7

Ensuite, pour avant de lancer la compilation avec «make», j’ai utilisé la commande «configure» suivante:

./configure –prefix=$HOME/local –disable-gpm –disable-xsmp –enable-multibyte –enable-gui=no –without-x

La destination pour l’installation est un répertoire nommé «local» dans mon répertoire personnel. J’ai désactivé toute les options utilisant la souris et celle faisant intervenir X. Le but est d’obtenir un programme VIM aussi petit que possible et indépendant de X Windows. À noter que j’ai explicitement spécifié le «multibyte», afin d’être certain que le support pour Unicode soit dans l’exécutable.

La dernière étape était une simple, «make» suivie d’un «make install».

Et voilà, WordPress peut maintenant être en version française tout comme sur une plateforme 32 bits.