Apri Mike file di progetto

Usi \bidone, \ lib, \ src? Questo è Open Mike, una serie di post di discussione per gettare il gatto tra i piccioni. Questi post riguardano tutto te - vogliamo ascoltare le tue opinioni, idee e pensieri. Questo post, sospetto, sarà polarizzante? sentiamo come organizzi i tuoi file di progetto.

La Quick Tip di Daniel Apt ci ha mostrato Come per organizzare i file dei nostri progetti Flash in diverse directory. Ma c'è ancora la questione di dove dovrebbero andare tutti.


Quali file vanno dove?

Un tipico progetto Flash coinvolgerà la maggior parte o tutti questi tipi di file:

  • FLA
  • SWC
  • SWF
  • COME
  • HTML
  • JS
  • JPG, PNG
  • MP3, WAV
  • XML
  • ? e forse di più.

Come sistemare la struttura delle cartelle per memorizzare tutti questi file?

(Nota: a volte il tipo di file non determinerà la sua posizione ideale, un JPG probabilmente andrà in cartelle diverse a seconda che debba essere incorporato nel file SWF o caricato dinamicamente in fase di runtime.)


Che dire quando si costruiscono obiettivi diversi?

Come imposti le tue cartelle quando crei build differenti per scopi diversi?

Ad esempio, potresti avere build separati di 'debug' e 'deploy' o build indirizzati a piattaforme o browser diversi.


Dove tieni API e librerie?

Molte esercitazioni su questo sito utilizzano TweenMax. Hai una singola cartella contenente tutte le API e le librerie che usi spesso, impostate come classpath globale nel tuo IDE? O copi ogni libreria nella cartella del tuo progetto corrente?

Quest'ultimo sembra uno spreco, ma il primo ha dei rischi: se sovrascrivi una libreria con una nuova versione, il vecchio codice potrebbe smettere di funzionare.


Come si strutturano i percorsi di classe?

Tradizionalmente, i percorsi di classe AS3 erano strutturati in modo tale da contenere il nome di dominio dell'autore. Ad esempio, se possiedi http://yourdomain.com/, strutturerai il tuo classpath in questo modo:

\ Com \ YourDomain \ projectName \ ClassName.as

In questo modo, la definizione del pacchetto sarebbe simile a questa:

pacchetto com.yourdomain.projectName

? e la dichiarazione di importazione sarebbe simile a questa:

import com.yourdomain.projectName.ClassName;

L'idea è, dal momento che possiedi il tuo nome di dominio e hai il controllo su quali nomi di progetti sono usati, puoi fermare due diverse librerie con gli stessi percorsi di classe.

Ma sta diventando sempre più comune vedere questa convenzione rifiutata a favore di percorsi di classe arbitrari (e spesso più brevi). Vale la pena sacrificare la brevità per evitare che due classi diverse abbiano lo stesso pacchetto?