Nouvelle version de Mootools : 1.2rc1
19 septembre 2007 7 commentairesA priori il y a déjà des changements dans le code par rapports aux précédentes versions mais surtout pas de panique, vos scripts réalisés avec les version 1.0 et supérieures fonctionneront toujours grâce à l’inclusion par l’équipe de mootools d’un module de compatibilité. Il faudra attendre encore un peu avant de savoir ce que ces changements apportent comme nouveautés mais ce doit être la classique de toute sortie de librairie js : plus d’optimisation et plus de compatibilité. Il y a cependant un nouveau plugin qui a l’air bien pratique : swiff, pour l’inclusion de swf via javascript [2].
Vu que c’est une release candidate elle est encore à tester car susceptible d’évoluer. Évidemment, si vos sites utilisent de jolis effets et des appels ajax un peu partout réalisés avec mootools, ne vous précipitez pas sur cette nouvelle version ; attendez la 1.2 finale.
- rc pour release candidate
- perso inclure un swf en javascript je trouve ça dément pourtant c’est ce que pleins de sites à la pointe de la hypitude en développement web font. Pourtant, on peut faire autrement.
salut,
sur la question de l’inclusion de flash via SwfObject ou autre, je trouve pour ma part, cela très pratique en terme de gestion. Lorsqu’il n’y a qu’un seul flash à gérer… pourquoi pas.
Mais lorsqu’il y a plusieurs éléments flash sur un site (la question de la volumétrie est importante), cette méthode est plus simple. Tu n’intervients que sur le code html et non pas sur le code et sur le flash. De plus si les éléments flash sont réalisés par des collègues, cela devient plus simple : les éléments ne sont jamais définitif, et il arrive (souvent) que l’on change un chemin… avec la solution Satay, je vais devoir modifier d’une part le code et d’autre part le flash… multiplier par le nombre d’élément…
euh… non. Avec flash Satay, tu passes le chemin vers ton swf en paramètre lors de l’appel de ton fichier satellite. Comme ça :
[object type= »application/x-shockwave-flash »
data= »c.swf?path=lecheminversmonfichierflash.swf »
width= »400″ height= »300″]
[param name= »movie »
value= »c.swf?path=lecheminversmonfichierflash.swf » /]
[/object]
Ce qui revient au même pour la maintenance que de passer par une solution javascript type SwfObject ou autre.
Flash Satay pose juste un pb de compatibilité avec les anciennes versions de Safari, comme c’est expliqué ici :http://www.alistapart.com/articles/flashembedcagematch/
Pour le reste, les 2 solutions se valent. Ca dépend si tu veux rendre tes swf accessibles aux utilisateurs qui n’ont pas javascript – qui sont très peu nombreux quand même. De toute façon, on peut penser qu’un gars qui n’a pas javascript d’activé n’a pas non plus de plugin flash (je pense aux terminaux mobiles).
Ce qui me gène avec un script pour l’intégration de flash c’est : « pourquoi rajouter une couche javascript lorsqu’on peut le faire simplement avec des marqueurs classiques ».
Oups autant pour moi… effectivement tu as raison.
J’ai lu trop rapidement. Non… pas taper…
Néanmoins, la détection « externalisée » de la version du plug-in flash me semble une démarche intéressante. De même que la présence d’un texte alternatif avec la possibilité d’outrepasser la détection…
Je comprends rien. Mais j’adore le titre : Motools scrch 1, on dirait, euh, un nouveau genre de musique élecro ??
« Mootools srch1, un nouveau genre de musique électro » ça ça ferait un bon titre de billet :))
Promis la prochaine fois que je fais un billet « spécial techos » je rajouterai en rouge l’avertissement qui va bien 😉
Tu n’y es pas du tout : les avertissements « âmes sensibles » donnent encore plus envie aux non-initiés de lire les articles ;.)
Barbayellow se « gouroutise ». Cela dit il en a les moyens (profite Grégoire, c’est rare ce genre d’envolées de ma part) 🙂
Cela dit, bravo pour l’explication, même moi j’ai compris !