Share
Utilises tu \poubelle, \ lib, \ src? Ceci est Open Mike, une série de messages de discussion pour jeter le chat parmi les pigeons. Ces messages parlent de vous - nous voulons connaître votre opinion, vos idées et vos réflexions. Je soupçonne que cet article va se polariser? Ecoutons comment vous organisez vos fichiers de projet.
Le conseil rapide de Daniel Apt nous a montré Comment organiser les fichiers de nos projets Flash dans différents répertoires. Mais il y a toujours la question de où ils devraient tous aller.
Un projet Flash typique impliquera la plupart ou la totalité de ces types de fichiers:
Comment organisez-vous votre structure de dossiers pour stocker tous ces fichiers?
(Remarque: il arrive que le type d'un fichier ne détermine pas son emplacement idéal. Un fichier JPG sera probablement placé dans des dossiers différents selon qu'il doit être incorporé au fichier SWF ou chargé dynamiquement au moment de l'exécution.)
Comment configurez-vous vos dossiers lorsque vous créez différentes versions à différentes fins?
Par exemple, vous pouvez avoir des versions distinctes de 'débogage' et de 'déploiement', ou des constructions ciblant différentes plates-formes ou navigateurs..
Beaucoup de tutoriels sur ce site utilisent TweenMax. Avez-vous un seul dossier contenant toutes les API et les bibliothèques que vous utilisez souvent, défini comme chemin de classe global dans votre IDE? Ou copiez-vous chaque bibliothèque dans le dossier de votre projet actuel?
Le dernier semble inutile, mais le premier comporte des risques: si vous écrasez une bibliothèque avec une nouvelle version, l'ancien code risque de ne plus fonctionner..
Traditionnellement, les chemins de classes AS3 étaient structurés de manière à contenir le nom de domaine du créateur. Par exemple, si vous possédez http://votredomaine.com/, vous structurez votre chemin de classe comme suit:
\ com \ votredomaine \ nomprojet \ NomClasse.as
De cette façon, la définition du paquet ressemblerait à ceci:
package com.votredomaine.nomprojet
? et la déclaration d'importation ressemblerait à ceci:
importer com.votredomaine.nomprojet.nomClasse;
L'idée est que, puisque vous possédez votre nom de domaine et que vous avez le contrôle sur les noms de projet utilisés, vous pouvez arrêter deux bibliothèques différentes ayant les mêmes chemins de classes..
Mais il est de plus en plus courant de voir cette convention rejetée au profit de chemins de classes arbitraires (et souvent plus courts). Vaut-il la peine de sacrifier la brièveté pour éviter que deux classes différentes aient le même paquet??
Accentsconagua