L'outil de Macromedia offre aux développeurs un moyen simple et efficace de stocker des données sur le disque de l'utilisateur, à la manière des "cookies".
(26
janvier 2004)
Introduits avec Flash MX, les Shared Objects sont
la réponses de Macromedia à une longue attente de la part des développeurs
: pouvoir stocker des informations sous forme de "cookies" afin de les
partager facilement entre deux applications ou deux sessions. Auparavant, les
développeurs souhaitant faire usage de cookies devaient passer par des
scripts externes, et s'efforcer que l'application Flash comprenne ce qu'on lui
demande.
Notez cependant que les SharedObjects ne peuvent être utiles que dans une
application 100% Flash, étant donné qu'ils ne peuvent pas être
utilisés par d'autres types d'applications. Dans le cas d'un site mélangeant
Flash et un langage serveur pour gérer les sessions, il est probablement
préférable de s'en remettre au langage serveur...
Nous allons voir l'utilisation de ces Flash-cookies au travers de deux exemples.
Un compteur de visites
Classique des JavaScript du début du Web, ce petit script indiquera juste
au visiteur le nombre de fois où il est venu sur le site.
Dans un nouveau document, poser un champ dynamique, dont la variable sera nommée
"visites". Ensuite, sur la première image du calque en cours,
mettez le code suivant :
Ce qui vous donnera un résultat proche de celui-ci
:
Expliquons. Notre première ligne, via la
méthod getLocal()
de l'objet SharedObject, tente d'accéder à l'objet partagé
local nommé "compteur". S'il ne le trouve pas, il en créé
: nous sommes donc ainsi assurés d'avoir physiquement accès à
un objet local.
Nous testons ensuite le contenu de visites
: selon qu'il soit vide, égal à zéro ou plus, notre affichage
sera différent.
Après avoir affiché correctement le nombre de visite, on augmente
la valeur du champ visites
de notre cookie, et on écrit le cookie résultant avec la méthode
flush().
Utiliser flush()
n'est pas forcément nécessaire, mais il permet de contrôler
manuellement l'écriture du cookie - sans cela, le cookie ne serait écrit
qu'au moment où le visiteur quitte l'animation/le site... Par ailleurs,
flush() renvoyant
un booléen (true
ou false), il nous
permettrait si on le souhaitait de valider que notre objet a bien été
écrit, et dans le cas contraire d'agir en conséquence (alerter l'utilisateur,
par exemple).
Un autre avantage de flush() :
il peut prendre en argument la taille voulue pour stocker les informations. En
effet, le taille est normalement limitée à 100 Ko, mais il peut
arriver que les informations à stocker prennent plus de place - l'objet
ne pourra alors être enregistré que si l'on appelle flush(1024
* x), x
étant la taille en Ko demandée.
Notre objet s'appelant "compteur", nos
données seront stockées sur le disque de l'utilisateur, dans le
répertoire des cookies Flash. Sous Windows XP par exemple, ce sera C:\Document
and Settings\[now d'utilisateur]\Application Data\Macromedia\Flash Player\[le
domaine ou le(s) répertoire(s)]\[nom de l'animation].swf\compteur.sol
.