Oct/090
Amélioration des événements génériques an javascript
La problématique concerne la façon dont le MVC est addressé en javascript dans notre application.
Lorsque l’on veut répondre à un événement, on code de la façon suivante :
- création du lien HTML avec l’attribut
data-event
indiquant l’événement utilisé - création de la fonction javascript permettant de répondre à cet événement
- création du code d’association entre l’attribut et la fonction
Ces cas sont représentés ainsi :
Création du lien :
<a href="xxx" data-event="eventStart">event</a>
Fonction javascript :
$.extend({ eventStart: function() { console.log("eventStart fired"); } });
Code d’association :
$(document).bind("eventStart", $.eventStart);
La fonction utilisée afin de se substituer au click n’est pas représentée ici, elle peut être retrouvée dans un ancien article
Le problème est que l’on se retrouve rapidement à écrire une floppée de lignes d’association qui posent problèmes :
- les lignes sont triviales et apportent beaucoup de bruit pour rien
- introduit une duplication des noms d’événements non maintenable
Le mieux est de pouvoir inférer automatiquement ces lignes d’association à partir du javascript créé.
Résolution
Pour cela, on va stocker les événements génériques dans un autre espace de nom. On modifie donc nos événements en les stockant dans la clé events
:
$.extend({ events: { eventStart: function() { console.log("eventStart fired"); }, init: function() { $.each(this, function(key, value) { if (key != "init") $(document).bind(key, value); }); } } });
Et on rajoute par la même occasion, une fonction d’introspection qui permet d’associer toute fonction dans l’espace events
à l’événement correspondant au nom de la fonction !
Il suffit alors de rajouter un comportement global de type :
$(function() { $.events.init(); }
Et tout lien qui possède l’attribut data-event
sera associé automatiquement à une fonction correspondante dans l’espace events
.
La restriction est que tout événement ne doit pas comporter de caractères spéciaux. Nos événéments précédent comme login:start
doivent être renommés en loginStart
.
Maintenant, le workflow est le suivant :
- indiquer l’événement dans le lien à travers l’attribut
data-event
- écrire la fonction ayant le même nom dans l’espace
$.events
Simplissime, j’adore.
Extensions
Certains événements sont définis dans des fichiers séparés afin d’aider à la maintenance de l’applicatif.
Dans ce cas, il n’est pas possible d’utiliser la même notation, et il devient nécessaire d’augmenter la définition de la table de hachage de la façon suivante :
$.extend($.events, { moreEvent: function() { ... } });
Oct/090
Bibliothèque javascript Pure ou mécanisme interne ?
Le site fait une utilisation intensive d’échange de données JSON. Ces données doivent ensuite être réintégrées au niveau d’une structure de page HTML.
Par exemple, en prenant la structure suivante :
<div> <div class="title">Template title</div> <div class="body">Template body</div> </div>
Un fragment JSON reçut de ce type pourra être facilement intégré :
[{"title", "my new title"}, {"body", "a comment"}]
chaque clé sera utilisée comme filtre afin de déterminer l’élément HTML dont le corps sera remplacé. La clé est transformée en sélecteur jQuery de classe (« .title ») et le code HTML de l’élément est alors remplacé par la valeur de la clé.
Jusqu’à présent, il m’était évident que ces transformations devraient être réalisées par la bibliothèque pure
. C’est d’ailleurs ce qui a été fait jusqu’à présent, comme indiqué dans les premiers articles.
Cependant, il est peut être intéressant d’explorer également une voie de fonctionnement plus simple.
Pure
fonctionne sur un mécanisme de templates
ou modèle de code HTML : la structure HTML utilisée est dupliquée et le résultat affiché n’est qu’une copie de la source. Ceci permet de créer des fragments de code qui peuvent être réutilisés.
Le problème est que si on fait un « rendu » de la vue complète (le tag body) en espérant que seuls les éléments indiqués seront impactés, ce n’est pas tout à fait le cas. Tout le code HTML du body
sera remplacé, et donc tous les événements javascript associés de façon non obtrusive aux tags seront effacés !
Pure
ne peut pas travailler sur les éléments finaux.
Je ne sais pas encore si ce schéma est pénalisant pour l’application ou non, car la gestion des différentes « vues » ou « pages » applicatives n’est pas encore réalisé.
En attendant, il est facile de proposer une version dégradée de ce fonctionnement qui réalise un remplacement et non un écrasement :
$.fn.extend({ autoReplace: function(data) { $.each(data, function(key, value) { $(this).find("." + key).html(value); }); } });
Le remplacement sera effectif, sans détruire les événements associés au code affiché. Les limitations sont que seules les directives simples liées à la classe d’un attribut HTML sont gérées.
A voir avec les développements suivants, si une version simpliste de ce système est suffisant ou si l’on doit utiliser un mécanisme complet et complexe (car pure
gère plusieurs bibliothèques javascript, une précompilation des modèles, etc.).
Oct/090
Mise en oeuvre de l’authentification (3 - niveau navigateur)
On met en oeuvre la partie utilisateur/interface.
Tout d’abord, on rajoute un lien dans l’en-tête du site afin de diriger sur l’url /login.html
(priv/templates/views/index.haml
) :
%body #header #ids Guest %a{ 'data-event' => "login:start", :href => "/login.html" } (login)
Ce lien possède un attribut particulier data-event
. Cet attribut est correct selon les normes HTML 5, et peut être utilisé sans problème dès aujourdh’ui. Pour plus d’informations, vous pouvez lire cet article de John Resig.
Cet attribut personnalisé va nous permettre de définir des liens demandant un déclenchement d’événement lors d’un click. Cet événement est la valeur de l’attribut lui même. Le comportement générique sera de ne pas déclencher le click normal (navigateur) mais de le remplacer par le déclenchement de l’événement.
Oct/090
Gestion générique des appels Ajax
Le fonctionnement au niveau du navigateur est revu, et on pose les briques de base pour une gestion générique des événements Ajax au niveau de l’interface.
Pour cela, jQuery offre de nombreux points de rattachement lorsqu’une requête Ajax est déclenchée.
Notre but sera de programmer des comportements génériques de la façon la plus personnalisable et en essayant de rester au plus près du style de programmation jQuery.
Jul/090
Comportements Ajax génériques
Le test Ajax prédédent va être modifié afin d’aporter de la généricité dans les comportements, et la possibilité d’avoir plusieurs blocs sur la même page, sans toucher aux modèles.
Pour cela, nous allons travailler principalement sur le javascript.
Jul/090
Pure IHM
Le système final est prévu comme étant une « application web ».
Je fais la distinction entre « application web » et « site web » : ce dernier étant soumis aux contraintes habituelles des sites internet, à savoir principalement les questions d’accessibilité et d’indexation (référencement, SEO).
Ces questions ne seront pas prises en compte ici, une application web étant une application riche dont le déploiement se déroule à travers Internet. A cette fin, plusieurs technos sont disponibles dont celles d’Adobe avec Flex, Microsoft avec .NET ou Silverlight.
Le challenge est de rester en technologies W3C le plus possible.
Le but est donc de mettre en place les composants qui seront dédiés à l’interface utilisateur.