22
Oct/09
0

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.).

23
Jul/09
0

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.