J’ai bien avancé sur mon projet, je suis sur le point d’ouvrir le site en version bêta. J’en viens donc aux derniers réglages et petites corrections, dont -chose que je repoussais depuis longtemps- le passage sous IE6… Si globalement ça va, y’avait quand même pas mal de choses à retoucher : des positionnements fantaisistes, des marges aléatoires et surtout des PNG transparents qui ne le sont plus… Ce dernier point m’a bien gonflé.

“que les utilisateurs d’IE6 aillent se faire… ah ouais, mais ils sont encore nombreux quand même!”

Bref, éternel problème du développeur web : abandonner ou pas le support d’IE6 avec la part de marché non négligeable qu’il représente toujours? Pour moi, la question ne se pose pas, je dois supporter ce vieux navigateur né en 2001… 9 ans! Je ne peux pas me permettre de perdre quelques clients alors que je n’en ai pour l’instant pas un. Mon service s’adresse à Mr tout le monde, pas aux geeks qui naviguent sous Google Chrome depuis déjà longtemps. Je n’ai pas le choix.

Et pour tester? Hé bien, j’ai du supprimer mon installation d’IE7 sur mon vieux PC, pour y remettre IE6!

J’en suis même venu à me demander : ne vaudrait-il pas mieux développer sous IE6? On aurait moins de surprises dans ce sens là. Si des développeurs passent par là, comment procédez-vous?

Coïncidence, le site Smashing Magazine a publié aujourd’hui un article sous forme de BD (dont est issue la première image de l’article) qui traite de l’histoire d’IE6 et du choix des développeurs : The Life, Times (and Death?) of Internet Explorer 6 (Comic Strip).

Dans l’impression écran ci-dessus, vous pouvez voir un petit bandeau “Internet Explorer is missing updates…”. Ceci est un faux message d’erreur qui s’affiche lorsque le navigateur détecté est IE6. Un clic envoie sur la page de téléchargement d’IE8. C’est le plugin WP-IE6Update qui gère ça. Une façon de participer à l’euthanasie de ce vieux bonhomme qu’est IE6.

Je compte utiliser cette solution dans un premier temps, parce qu’elle est la plus reconnue et me parait simple à mettre en place. C’est à ce sujet que j’ai discuté avec un représentant de Paypal. Il m’a confirmé qu’il y avait 2 façons de procéder :

• tout déleguer à Paypal, en appelant une simple URL à laquelle on ajoute certains paramètres, comme une URL de retour
• utiliser l’API proposée pour développer soi-même le process de paiement.

Et pour me renseigner sur l’API, il m’a indiqué l’adresse du site où l’on peut trouver toutes les infos : x.com. Si si, c’est bien ça. Vous pouvez cliquer dessus, vous ne tomberez pas sur un site… X.

Etonnant. Etonnant, de voir un nom de domaine sur un caractère, ça a l’air d’être le seul pour un .com. Etonnant aussi de choisir un tel nom de domaine, vu la connotation qu’il porte.

Bon allez, je retourne me rincer l’oeil sur x.com!

Du coup, j’en ai profité pour aussi mettre à jour jQuery UI pour la version 1.7.2 (la 1.8 ne devrait pas tarder pour faire suite à jQuery 1.4), qui fonctionne bien avec la nouvelle version 1.4.

Seul souci, lorsqu’on télécharge la librairie depuis le site jqueryui.com, elle ne contient pas les versions minimisées des fichiers javascript. Bien sûr, on peut le faire soi-même, mais sinon, sachez qu’on peut les trouver sur l’hébergement google code du projet jQuery UI : http://code.google.com/p/jquery-ui/downloads/list. Le zip à télécharger contient un répertoire ui, avec tous les js, et un sous répertoire minified avec tous les mêmes js mais minimisés cette fois.

A première vue, ça ressemble à un Gmail nouvelle version. C’est normal, c’est un site en Ajax entièrement fondé sur GWT (de chez qui? de chez Google!). Mais très vite, je me dis… que faire? Je n’ai qu’un contact -la personne qui m’a invitée- et à part créer une ou deux waves avec lui pour m’amuser, il n’y a pas grand chose d’autres à faire.

Aller plus loin avec Google Wave en attendant ses amis

Les waves publiques

J’ai découvert qu’il y a moyen de participer à de grosses waves publiques. Il est possible de faire des requêtes sur toutes les waves publiques en plaçant la requête suivante dans le champ de recherche :
with:public

Et là, le flux de toutes les waves publiques se met à défiler en temps réel dans le panel central. Ce qui a tendance à faire ramer le navigateur et qui n’est pas très pertinent de toutes façons. Par contre, il est possible d’y accoler n’importe quelle recherche de mots-clés, du genre :
with:public jeansarkozypartout

Pour avoir toutes les waves publiques contenant le mot clé jeansarkozypartout. Il se trouve qu’actuellement, il n’y en a aucune, ce qui n’est pas le cas, si on tente la même opération sous Twitter. Car justement, cette fonctionnalité de Google Wave, tend très nettement à concurrencer Twitter sur le terrain de la recherche temps réel.

Les extensions

Dans la wave d’accueil “Welcome to Google Wave”, il y a un lien vers une autre wave nommée “Extensions gallery”, qui recense et permet l’installation de quelques plugins : météo, Google Maps, Sudoku, …

Ca permet de continuer à jouer… seul en attendant que tout le monde viennent à Google Wave. Et là, bien que je sois convaincu de l’avancée et des nouveautés apportées par ce produit, je crains que ça ne mette du temps à prendre chez les simples utilisateurs de mail (1.0!).

Google Wave pour faire autre chose que de la messagerie

J’aimerais vraiment pouvoir faire quelque chose avec Google Wave, je suis persuadé qu’il y a moyen de développer de nouveaux outils collaboratifs révolutionnaires. Je n’ai pas d’idées précises pour le moment, mais je pense que tout comme ça va ringardiser les bons vieux mails, ça va mettre au placard les forums à l’ancienne, voire les blogs. A creuser…

D’ailleurs, ce matin, j’ai reçu mon invitation pour accéder au Google Wave developer sandbox. J’attends maintenant la confirmation…

J’ai assez peu hésité sur le choix du moteur. J’avais déjà eu l’occasion d’utiliser Smarty (mais il y a déjà quelques années sur un tout petit site) et à la lecture d’un comparatif sur developpez.com, je me suis vite rangé du côté de ce que je pense être le moteur n°1. Le seul inconvénient qu’on lui trouve est la difficulté de la syntaxe… je ne vois pas pourquoi. Ce n’est pas plus compliqué que n’importe quel langage de script, syntaxe XML ou autre.

Il y avait bien PhpLib, le moteur des forums PhpBB, que j’ai été amené à côtoyer, car c’est la solution de forum que j’ai toujours utilisée. Mais contrairement à Smarty, elle ne gère pas de cache. Et j’espère un jour avoir des soucis de performances dûs à la trop grande fréquentation de mon site! Et je serai content alors de ne pas avoir à migrer de PhpBB à Smarty. Je mets toutes les chances de mon côté dès maintenant.

Je ne peux pas proposer de saisir les coordonnées à la main. Non, il faut que les utilisateurs déplacent eux-mêmes la Google Map et qu’ensuite je récupère les paramètres de cette carte, qui sont dans mon cas la latitude et la longitude du centre de la carte et le niveau de zoom, pour les sauvegarder. Et avec l’API Google Maps, c’est finalement assez simple.

La map se place dans un div, suivi dans champ input hidden, qui contient les paramètres :

<div class="map" id="map_'.$i.'"></div>
<input id="content-'.$i.'" name="content-'.$i.'" type="hidden" value="" />


Puis, j’initialise chaque map de la page par la méthode suivante :

function newMap(rowId, lat, lng, zoom) {
if (GBrowserIsCompatible()) {
var map = new GMap2(document.getElementById("map_"+rowId));
map.setCenter(new GLatLng(lat, lng), zoom);
// Ajout des contrôles ou autres paramètres
GEvent.addListener(map, "moveend", function() {
$("#content-"+rowId).val(map.getCenter().lat()+"|"+map.getCenter().lng()+"|"+map.getZoom());
});
}
}


Le listener associé à la map se déclenche en fin de déplacement (‘moveend‘), et récupère alors les paramètres (map.getCenter().lat()) pour les placer dans le champ hidden associé ($(‘#content-’+rowId).val(…)).

Avec un poil de jQuery (qui me séduit de plus en plus), c’est vraiment simple de faire des choses sympas. La preuve.

On entend de plus en plus parler de l’évolution future de la syntaxe HTML : HTML5. Et je n’avais jusque-là jamais pris le temps de me pencher dessus et de lire un article en entier, car je me dis que ce n’est pas pour tout de suite.

Je n’avais pas tord, ce n’est pas pour tout de suite, il va falloir attendre que les navigateurs implémentent ces nouvelles spécifications, mais aussi, éternel problème, que les utilisateurs fassent les mises à jour…

Et c’est dommage, car ce qui s’annonce est très prometteur : un code beaucoup plus léger et cohérent pour le développeur, des applications web plus “riches” pour les internautes. Plus de détails dans l’article.

Il me faut donc un composant de formulaire plus évolué qu’un basique élément textarea, soit un éditeur de texte riche. Après une recherche sur Google de scripts implémentant ce besoin, j’ai éliminé les composants moches, ceux n’étant plus mis à jour depuis trop longtemps et ceux qui ne géraient pas l’upload d’image mais seulement un lien vers une image déjà présent sur le réseau et j’ai retenu une liste de 4 composants :

• Dsrte : avidansoft.com/dsrte
• TinyMce : tinymce.moxiecode.com
• CKEditor : ckeditor.com
• NicEdit : nicedit.com

DSRTE

J’ai trouvé DSRTE (pour Damn Small Rich Text Editor soit en français un sacrément petit éditeur de texte riche), en cherchant tout d’abord un script basé sur jQuery que j’utilise en tant que framework javascript.

Il contient toutes les fonctionnalités dont j’ai besoin, mis à part peut-être la possibilité d’insérer une image par une URL. Le look est par contre un peu à l’ancienne, pas très sexy…

J’avais essayé de l’installer il y a 3, 4 mois sans y parvenir… Mais je dois avouer que je n’avais trop pousser les essais non plus, je n’en avais pas encore besoin à l’époque.

Site : avidansoft.com/dsrte

TinyMCE

Très complet… trop complet… trop complexe! Les utilisateurs de mon service ne seront pas tous des geeks! Ca m’étonnerait d’ailleurs! (Vous comprendrez plus tard…) Il y a un “Image Manager” et il faut y ouvrir trois fenêtres pour pouvoir charger une image : pas assez ergonomique à mon goût.

Je n’ai pas essayé de l’installer car du coup il ne m’intéresse pas. Mais ça semble être tout de même un très bon produit, pour des besoins plus évolués peut-être.

Site : tinymce.moxiecode.com

CKEditor

Celui-ci est très très bien. Complet (insertion de Flash, de formulaires, … le tout customisable bien sur), beau (et on peut choisir d’autres skins et changer les couleurs). Bref, super sauf… la licence. Hé oui, ça a son importance aussi! Dans mon cas, j’aurai besoin d’une licence commerciale à 375$. NEXT!

Site : ckeditor.com

NicEdit

NicEdit n’offre pas des “centaines” de fonctionnalités, mais largement de quoi satisfaire la plupart des gens.
Il propose l’upload de fichier très simplement, en les envoyant par défaut sur le service imageshack, mais il est possible de les héberger soi-même en copiant un script PHP sur son serveur. Je ne l’ai pas encore fait, je ne sais pas quelle est la meilleure stratégie : sous-traiter un service et la charge qui va avec ou être indépendant (d’un arrêt de service par exemple).

Mais surtout, ce qui m’a séduit, c’est l’intégration : 1 minute et je n’exagère pas.
Il y a un fichier javascript et une image à copier.
Ensuite, dans un formulaire il suffit d’ajouter un élément textarea des plus classiques :

<textarea id="test"></textarea>

Puis un petit bout de javascript pour faire évoluer ce champ de texte en un composant riche :

var editor = new nicEditor().panelInstance('test');

Voilà, c’est tout. Ca marche nickel. Je suis convaincu.

Site : nicedit.com

Et GWT?

Ben oui, pour faire des formulaires un peu avancés, pourquoi pas GWT?

Utilisant régulièrement cette technologie pour mon boulot, la partie GWT elle-même ne m’inquiètait pas. Ce qui me faisait plus peur, c’était plutôt l’intégration avec une application PHP… Je sais que c’est possible en communiquant avec JSON, mais franchement, ce serait autrement plus complexe que la seule ligne de code ci-dessus.

Pour les motivés, un article chez IBM : XML: The bridge between GWT and PHP

Toute développeur web a déjà été confronté au terrible test sous IE6. Car ce vieux navigateur, sorti en 2001, ne respecte pas les normes CSS comme ses confrères. OK, erreur de jeunesse, c’est pas grave, c’était en 2001… sauf que chez Microsoft, ils n’avaient pas prévu de mise à jour automatique dans l’optique d’un IE7 (comme Firefox, qui propose la mise à jour lorsqu’elle est disponible, ou comme … IE7! qui est passé en IE8 quasiment tout seul). Ce qui fait qu’aujourd’hui, IE6 représente encore un bon 30% des navigateurs utilisés à travers le monde. On ne peut donc pas le négliger et on doit passer du temps à corriger les différents bugs graphiques qui lui sont spécifiques. Sans parler de la difficulté de tester un site sous IE6, IE7 et IE8…

Mais comment se débarrasser de ces IE6 récalcitrants? Ceux qui l’utilisent ne sont certainement pas technophiles, et ne vont pas subitement se mettre à installer Google Chrome! Faut-il attendre que leur machine tournant sous Windows XP (et sur lesquels IE6  était installé d’office) meure de vieillesse? Ça peut prendre du temps…

Le problème connait peut-être un début de réponse grâce à Facebook et Youtube pour ne citer que les plus gros, qui ont décidé de prendre les choses en main. Vu leur rayonnement, seul ce genre de site peut se permettre de faire passer un tel message :

En tout cas, je pense que pour mon projet en cours, je vérifierai la tête qu’ont les pages, mais je ne m’embêterai pas à les rendre strictement identiques à ce que j’attends sur les autres navigateurs. Et j’ajouterai un message en tête de page expliquant et invitant à mettre à jour le navigateur.

Espérons que cette démarche fonctionne, et pour toi visiteur sous IE6, ce petit message ci-dessous. N’hésites pas, mets à jour, si tu ne le fais pas pour toi, fais le pour ceux qui développent!

Tout d’abord, petit point sur les origines et la situation de mon projet.

J’ai commencé par développer un site web pour un besoin personnel. Après les retours de certaines personnes qui trouvaient les fonctionnalités intéressantes et qui se disaient même prêtes à payer (c’est là que j’ai du avoir le déclic!), je me suis dit que je pourrais peut-être en faire quelque chose…

Maintenant que j’en suis à la phase de refonte plus sérieuse du site en vue de son automatisation, je suis confronté au dilemne suivant : PHP ou Java / J2EE?

Naturellement au début, dans l’optique d’un simple et modeste site, j’ai opté pour le package PHP + MySQL, facile, simple… J’ai toujours utilisé ces technos lorsque j’ai développé d’autres petits site web.

Mais maintenant que je me lance dans un projet plus conséquent et plus long terme, je me suis dis “Et pourquoi pas faire ça en Java / J2EE?”

Ce sont des technologies que j’utilise quotidiennement pour mon boulot depuis 5 ans maintenant, avec lesquels je me sens donc beaucoup plus à l’aise que dans l’univers LAMP (Linux, Apache, MySQL, PHP). Selon moi, c’est un environnement beaucoup plus professionnel, permettant le développement d’applications beaucoup plus conséquentes. Et coder en Java avec un IDE (environnement de développement) comme Eclipse, c’est vraiment plus facile qu’en PHP.

Donc il est clair que mon coeur penche plus que fortement du côté Java/J2EE.

MAIS, car bien sûr il y a un plusieurs “mais”. Si jusqu’ici je n’ai fait que des sites en PHP, c’est que les offres d’hébergement de sites en J2EE sont quasi-inexistantes. En France, je n’ai trouvé qu’althosting, qui offre un pack à 6€ HT. Mais mes enquêtes pour avoir l’avis de clients m’ont fait comprendre que la prise en main était limitée, à priori pas moyen par exemple de redéployer soi-même son application. Mon e-mail auprès du service commercial est resté sans réponse…

L’autre solution serait de prendre un serveur virtuel (à partir de 12€ TTC sur 1and1), mais ça commence à revenir plus cher pour un projet qui ne garantie pour l’instant aucun revenu (on y reviendra plus tard).

De plus, l’existant de ce projet est en PHP, et tout recoder prendrait tout de même un certain temps. Même si je pense que je pourrais rattraper ce temps sur le long terme, notamment avec des outils comme GWT.

S’ajoute à cela le fait que j’ai fait tomber certaines limitations (qui ne tenaient qu’à moi) en faisant quelques découvertes intéressantes.

Ma mauvaise appréciation de la solution PHP venait en partie du serveur de base de données qui lui ai systématiquement associé (dans les offres d’hébergement, car il peut fonctionner avec toutes bases de données) MySQL. Car je n’avais jamais prêté attention à l’intérêt des moteurs de stockage MyIsam et InnoDB. Le premier étant celui par défaut, je n’avais jamais tenté de changé ça, ne sachant ce que cela allait engendré.

Et bien InnoDB, c’est mieux! Et c’est peut-être la clé d’un début de réconciliation avec PHP + MySQL. En effet, contrairement à MyIsam, InnoDB permet de définir des contraintes de clés étrangères, ce qui garantie une meilleure intégrité des informations. Mais ce n’est pas tout, il permet aussi l’utilisation de transactions!

De quoi rendre la solution PHP un peu plus convenable dans un contexte professionnel. Il me faut encore trouver un système de mise en cache, qui existe mais que je ne connais pas encore, et ce sera pas mal.

J’ai donc décidé de rester sur PHP + MySQL, histoire d’avancer tout de suite, et en fonction de l’évolution de l’application une fois en place, j’envisagerais peut-être la migration vers J2EE.

Ca me permet aussi de rester pluri-disciplinaire plutôt que d’être un intégriste du J2EE!