11548 sujets

JavaScript, DOM et API Web HTML5

Fonctions et scripts de référence?

Bonjour à tous,

Je bosse actuellement, de temps à autre, sur une boite à outils pour l'IDE/éditeur de code Komodo (by ActiveState). Elle est disponible ici (en anglais):
http://community.activestate.com/node/3024

J'avais commencé avec HTML et CSS uniquement, et sur ce front c'est à peu près finalisé. Mais je me suis dit que ça manquait de JS (pas ma spécialité, mais théoriquement ça fait aussi partie de mon domaine Smiley cligne ). Donc je suis parti en chasse de documentations de référence pour JavaScript (dur à trouver...). Ça devrait être correct de ce côté.

Je suis maintenant en chasse de fonctions et scripts simples, et si possibles ne nécessitant pas telle ou telle bibliothèque, pour... tout ce qui vous semblera utile.

Quelles sont les fonctions dont vous ne pourriez pas vous passer? Quelles fonctions et scripts utilisez-vous régulièrement d'un projet à l'autre?

J'ai déjà inclus directement (comme code snippet) ou lié différentes ressources, mais si vous avez des préférences, des idées pour compléter, etc., n'hésitez pas.

Pour info, ma toolbox ressemble à ceci (capture d'écran, désolé, pas le temps de tout transcrire):

upload/2043-jstoolbox.png

(On notera que ce sont essentiellement des liens... un peu tendu d'inclure des scripts complets susceptibles de changer régulièrement.)

Merci d'avance. Smiley smile
Modifié par Florent V. (19 Nov 2008 - 23:22)
'lut Florent,

je ne sais pas si ça peut t'aider mais je me sers régulièrement des fonctions addEvent, EcrireCookie, LireCookie et getWindowHeight (lien supprimé) et de temps à autre d'un petit script de rollover (prévu au départ pour les liens de menus mais fonctionnant aussi pour les autres images).


Edit: suite au message de Julien j'ai modifié mon code mais comme c'est du fait maison et que tu as déjà addEvent j'ai supprimé mon lien et il ne reste plus que getWindowHeight ( http://www.pompage.net/pompe/pieds/ ) qui peut éventuellement t'intéresser
Modifié par Heyoan (20 Nov 2008 - 03:22)
Heyoan a écrit :
je ne sais pas si ça peut t'aider mais je me sers régulièrement des fonctions addEvent, EcrireCookie, LireCookie et getWindowHeight disponibles ici

Attention, LireCookie est buggé. Si je cherche à récupérer le cookie dont le nom est "securite", je peux très bien me retrouver avec la valeur de celui dont le nom est "insecurite". Smiley cligne

C'est pour cela que j'essaie de me fier autant que possible seulement aux références incontournables (exemple : jQuery) quand j'ai besoin de code JavaScript externe.
Arf ! Smiley biggol

je l'utilise depuis des années et je ne l'avais jamais remis en question !

Merci Julien. Je me renseigne pour me mettre à jour. Smiley cligne
Modifié par Heyoan (20 Nov 2008 - 01:11)
Heyoan a écrit :
je l'utilise depuis des années et je ne l'avais jamais remis en question !

Je pense que tu n'es pas le seul. Smiley smile
Modérateur
Salut, Smiley smile

Comme disait Julien, difficile d'être exhaustif. Smiley ravi

Je rajouterais juste un petit outil :

http://www.javascriptbeautifier.com/

ce qui peut être pas mal lorsqu'on bosse sur un projet déjà existant.

Après, concernant les fonctions indispensables, ça dépend pas mal du projet et du temps imparti.

Ceci dit, quelque soit le site, j'aurais toujours :

- une entité gérant les événements,
- une manipulant le DOM et
- une manipulant les classes.

A cela, peuvent venir se greffer, suivant les besoins :

- un module pour gérer les requêtes Ajax,
- un pour les cookies,
- quelques algo' étendant les fonctionnalités liées à chaque type de données (array, string, etc...) lorsque ceux-ci ne sont pas disponibles et
- diverses fonctions structurelles (pour faire des interfaces, des classes, de l'héritage, etc...).

... J'oublie peut-être des trucs... Smiley murf

Concernant tout ce qui est lié à l'architecture de l'application, je mets ça en place assez vite lorsque le projet commence à être un peu conséquent et surtout lorsqu'il s'agit de travailler à plusieurs. De même, je ne bosse pas à plusieurs sans un outil tel que TortoiseSVN; cela permet un meilleur suivi et facilite grandement la maintenance.

Après, ben... je me sers actuellement beaucoup de Mootools mais ce n'est pas une fin en soi.

A mes yeux, le mieux, au vu des différentes bibliothèques, est de se créer un modèle car certains ont l'habitude de coder avec leurs propres fonctions et d'autres se basent sur des bibliothèques du type JQuery, Mootools, Prototype, YUI, etc...
Pourtant, tous auront l'équivalent du addEvent et veulent pouvoir s'en servir comme ils l'entendent et non pas forcément comme le fait le petit copain d'à côté.
Donc, je crée, dans un premier temps, une fonction englobante qui s'occupe de switcher sur la fonction la plus adaptée à la demande et je m'attache à cerner ce dont je me sers tout le temps et ce qui est inutile.

De là, tous mes scripts futurs sont basés sur la fonction englobante et non plus sur l'appel lié à telle ou telle bibliothèque.

Au début, on a quelquechose de lourd mais après deux, trois scripts et un peu de nettoyage, on n'a plus que l'essentiel pour un usage qui nous est propre. Smiley smile
Merci pour vos réponses. Smiley smile
J'ai inclus une partie de vos propositions.

koala64 a écrit :
- une entité gérant les événements,

Juste des fonctions addEvent/removeEvent, ou plus avancé?

koala64 a écrit :
- une manipulant le DOM

Tu penses à certains scripts en particulier (hors bibliothèques complètes)?

Dans l'ensemble, cette base que tu évoques me semble proche du dLite de Robert Nyman. À l'exception des fonctions manipulant le DOM, peut-être?

koala64 a écrit :
- un module pour gérer les requêtes Ajax,

Là encore, une référence hors bibliothèques?

koala64 a écrit :
- un pour les cookies,

Idem. Smiley smile

koala64 a écrit :
- quelques algo' étendant les fonctionnalités liées à chaque type de données (array, string, etc...) lorsque ceux-ci ne sont pas disponibles et
- diverses fonctions structurelles (pour faire des interfaces, des classes, de l'héritage, etc...).

J'en ai croisé quelques unes mais ne sachant pas les évaluer je les laisse de côté. Comme je vais maintenir ces contenus (que j'espère packager comme extension pour Komodo prochainement), c'est mieux si j'ai une compréhension même superficielle de leur intérêt, de leur qualité et de leur degré d'obsolescence. Smiley smile

koala64 a écrit :
Donc, je crée, dans un premier temps, une fonction englobante qui s'occupe de switcher sur la fonction la plus adaptée à la demande et je m'attache à cerner ce dont je me sers tout le temps et ce qui est inutile.

De là, tous mes scripts futurs sont basés sur la fonction englobante et non plus sur l'appel lié à telle ou telle bibliothèque.

Au début, on a quelquechose de lourd mais après deux, trois scripts et un peu de nettoyage, on n'a plus que l'essentiel pour un usage qui nous est propre. Smiley smile

Tu m'as perdu avec cette histoire de fonction englobante. Ça ressemble à quoi?
(Bon pour le coup c'est un peu hors-sujet, mais ça m'intrigue.)
Modérateur
Florent V. a écrit :
Juste des fonctions addEvent/removeEvent, ou plus avancé?
Il peut y avoir aussi fireEvent pour générer des évenements personnalisés, stopEvent pour empêcher la propagation de l'événement et annuler l'action par défaut de la cible, getPositionEvent pour récupérer les coordonnées de la souris, ou encore getCodeEvent pour récupérer le code des touches du clavier.

a écrit :
Tu penses à certains scripts en particulier (hors bibliothèques complètes)?
mmh... ben des fonctions du type insertAfter, remove, etc... qui, en définitive, se construisent toujours avec les mêmes bout de code. Après, il y a aussi tout ce qui va effectuer la sélection d'éléments du genre des $(), $$(), getElements(), etc... On en a toujours besoin et c'est pourquoi on trouve ça dans n'importe quelle bibliothèque.

a écrit :
Dans l'ensemble, cette base que tu évoques me semble proche du dLite de Robert Nyman. À l'exception des fonctions manipulant le DOM, peut-être?
moui... Je préfère rajouter ces fonctions parce que cela fait parti quasi systématiquement de mes besoins. Si je ne l'ai pas, je me retrouve, en définitive, à le recoder durant le projet... et donc je perds du temps.

koala64 a écrit :
- un module pour gérer les requêtes Ajax,
a écrit :
Là encore, une référence hors bibliothèques?
ben il faut surtout quelquechose qui sache lancer une requête en GET, en POST, tout en sachant récupérer du texte, du JSON, du XML ou je ne sais quoi d'autre.
Il peut être intéressant aussi de créer un système de pile pour gérer la coordination des appels et des réponses. Bref, je n'ai pas vraiment de référence en tête... C'est plutôt à la pratique qu'on s'aperçoit des 3, 4 fonctionnalités qui nous sont vraiment utiles.

Pour les cookies, les besoins sont toujours les mêmes :
les écrire, les lire, et les supprimer.

Concernant les fonctionnalités liées aux types de données, je pense surtout à des fonctions qui se trouvent dans des versions plus récentes du langage (et donc pas forcément implémentées dans chaque navigateur) comme, par exemple, pour les tableaux : filter, map, some, etc...
Il peut aussi y avoir des fonctions telles que trim sur une chaine texte, qui existe en php mais pas en js, ce qui peut pourtant s'avérer utile.
Ceci dit, pour cette partie, la chose qui me semble vraiment importante, c'est bien de reproduire une entrée et une sortie identique à l'implémentation d'origine.
Ainsi, le jour où une fonction telle que filter est prise en compte par un navigateur, on n'a plus à charger notre propre émulation et du fait qu'on ait collé au modèle d'origine, il y a très peu de chance pour qu'on ait besoin de modifier les scripts dans lesquels on les utilise.

a écrit :
Tu m'as perdu avec cette histoire de fonction englobante. Ça ressemble à quoi?
Le Factory Pattern.

En gros (et pour faire simple), le modèle est le suivant :
function addObserver() {
   switch(arguments.length) {
      case 1: return new addEvent(arguments[0]);
      case 2: return new observe(arguments[0], arguments[1]);
      default: return new addListen(arguments[0], arguments[1], arguments[2]);
   }
}
new addObserver('click', func);
addEvent, observe et addListen sont 3 fonctions qui font la même chose.
addObserver, elle, s'occupe de faire le choix.
Donc, quelquesoit les futurs scripts que tu produis, tu peux maintenant te servir de addObserver parce que ça répond à ton besoin.
Si, à la longue, tu t'aperçois, qu'en fait, tu bifurques tout le temps vers addEvent, tu sais maintenant comment alléger ton script en supprimant les fonctions inutiles.
En somme, tu augmentes le volume de ton script dans un premier temps (ce qui n'est pas le plus pénalisant en terme de performances) mais au final, tu cernes plus vite ce qui t'es vraiment nécessaire.

L'intérêt de définir un modèle, c'est que ce que je t'indique comme une fonction de référence sera celle en laquelle je crois... mais peut-être que quelqu'un qui va poster par la suite va proposer quelquechose de mieux... ou différent.
Sans modèle, tu te retrouves alors à devoir modifier tous tes anciens scripts parce que inadaptés.
Avec un modèle, en revanche, tu remplaces ou inclus en surplus la nouvelle fonction au sein même de celui-ci et tu n'as qu'à jouer sur les critères de choix; tous tes appels au modèle, par contre, restent inchangés.
Modifié par koala64 (20 Nov 2008 - 20:17)
Sujet clos
Aller à