De quoi s’agit-il ?
D’une classe permettant de charger dynamiquement des variables ou constantes (bien que l’AS2 n’ait pas vraiment de constantes…) contenu dans un fichier texte et d’y accéder facilement via un appel à la classe AppliConfig.
Comment accéder aux valeurs chargées dynamiquement:
// Recherche d’une valeur
trace(AppliConfig.MY_STRING)
If(AppliConfig .MY_BOOLEAN1){
trace('La valeur de MY_BOOLEAN est true')
}
//Comme la classe est dynamique, l’assignation de nouvelles variables globales n’est pas un problème.
AppliConfig.UNE_NOUVELLE_VARIABLE="une valeur définie lors de l’exécution"
trace(AppliConfig.UNE_NOUVELLE_VARIAB LE)
Comment structurer le fichier de configuration :
Comme la plupart des fichiers .ini (Voir le fichier exemple dans le zip)
; Fichier de configuration
[COULEURS]
COULEUR_BASE :0xff0000
COULEUR_ACTIVE :0xfffffff
[CLIP PERSO]
CLIP_PARAMS :{_x :100,_y :100,_alpha :50}
Quels sont les avantages de ce système ?
Il fonctionne aussi bien en ligne que hors ligne (en test direct sur votre ordinateur).
Il rassemble en un point central les données globales de votre application/animation, structuré d’une façon très simple à comprendre et à modifier
Il s’occupe seul de déterminer le type des variables créées
Il permet la création très simple d’objets compliqués
MON_ARRAY :["Une chaine de caractères",{_x :100,_y :100,_alpha :50},[1,2,3, 4]]
va créer un tableau accessible via AppliConfig.MON_ARRAY qui contiendra 3 lignes :
• AppliConfig.MON_ARRAY [0] : Une chaine de caractères
• AppliConfig.MON_ARRAY [1] : Un objet avec 3 pairs de clé/valeur
• AppliConfig.MON_ARRAY [2] : Un tableau de 4 lignes contenant chacune un nombre
Chaque élément du tableau pouvant être directement appelé via AppliConfig.MON_ARRAY[n]
Pourquoi ne pas stocker en dur les variables dans le script ?
Pour éviter de devoir recompiler à chaque fois l’application pour tester une nouvelle valeur, ce qui peut représenter un gain de temps pour les grosses applications.
Pour permettre la personnalisation rapide d’application (ou de portion d’application) sans devoir adapter le swf de base pour chaque cas.
Mais encore…
Imaginez que votre fichier de configuration est généré automatiquement via un script (php,asp,…) en fonction d’une base de données ou autre… ou selon un login/password
L’animation ou l’application sera personnalisée en fonction de l’utilisateur, en fonction d’une date,… enfin, tout ce qu’on peut imaginer.
Et les inconvénients ?
Cette méthode de travail n’est pas utile pour de petites animations ou application, elle va alourdir le travail de base (attente du chargement et de l’instanciation des variables, écouteur sur la classe AppliConfig)…
Cette méthode demande une plus grande préparation du travail, bien structurer ses applications, agir en fonction des variables, ce qui peut allonger le code…
Si vous définissez des variables static dans vos classes faisant référence aux valeurs contenues dans le fichier de configuration ces valeurs ne seront pas remplies
maClass{
static var COULEURCLIP=AppliConfig.COULEUR_BASE
trace(COULEUR CLIP) // retournera undefined
Mais cela est simplement contournable en réalisant une classe qui étend AppliConfig et qui va placer les valeurs static une fois les données chargées.
import net.graphit.Config.AppliConfig;
dynamic class MyAppliConfig extends AppliConfig
{
private static var _registred:Boolean=AppliConfig.register(MyAppliCon fig )
private function MyAppliConfig (){}
private static function onReady()
{
// Assignation des valeurs statiques
MA_CLASSE.COULEURCLIP=MyAppliConfig.CO ULEUR_BASE
// event dispatch pour prévenir l'application qu'on est prêt pour la suite
dispatchEvent({
type:"ConfigReady",
target:ConsoleConfig
});
}
}
N’hésitez pas à allonger la liste !!!