Вы используете \bin , \lib , \src ? Это Open Mike, серия дискуссионных сообщений, чтобы бросить кота среди голубей. Эти сообщения все о вас — мы хотим услышать ваши мнения, идеи и мысли. Этот пост, я подозреваю, будет поляризованным … давайте послушаем, как вы организовываете файлы вашего проекта .
Быстрый совет Дэниела Апта показал нам, как организовать файлы наших проектов Flash в разные каталоги. Но все еще остается вопрос, куда они все должны пойти.
Какие файлы идут куда?
Типичный проект Flash будет включать большинство или все эти типы файлов:
- FLA
- МЖК
- SWF
- В КАЧЕСТВЕ
- HTML
- JS
- JPG, PNG
- MP3, WAV
- XML
- … а может и больше.
Как вы организуете структуру папок для хранения всех этих файлов?
(Примечание: иногда тип файла не определяет его идеальное местоположение; JPG, вероятно, будет находиться в разных папках в зависимости от того, будет ли он встроен в SWF или динамически загружен во время выполнения.)
А как насчет того, чтобы строить для разных целей?
Как вы настраиваете свои папки, когда вы создаете разные сборки для разных целей?
Например, у вас могут быть отдельные сборки ‘debug’ и ‘deploy’ или сборки, предназначенные для разных платформ или браузеров.
Где вы храните API и библиотеки?
Многие учебники на этом сайте используют TweenMax . У вас есть одна папка, содержащая все API-интерфейсы и библиотеки, которые вы часто используете, настроенная как глобальный путь к классам в вашей IDE? Или вы копируете каждую библиотеку в папку вашего текущего проекта?
Последнее кажется расточительным, но у первого есть риск: если вы перезапишите библиотеку новой версией, это может привести к тому, что старый код перестанет работать.
Как вы структурируете свои классовые пути?
Традиционно пути классов AS3 были структурированы таким образом, чтобы они содержали доменное имя создателя. Например, если вы владеете http://yourdomain.com/, вы должны структурировать свой путь к классам следующим образом:
\com\yourdomain\projectName\ClassName.as
Таким образом, определение пакета будет выглядеть так:
package com.yourdomain.projectName
… и оператор import будет выглядеть так:
import com.yourdomain.projectName.ClassName;
Идея состоит в том, что, поскольку вы являетесь владельцем вашего доменного имени и контролируете, какие имена проектов используются, вы можете остановить две разные библиотеки, имеющие одинаковые пути к классам.
Но становится все более и более обычным видеть, что это соглашение отклонено в пользу произвольных (и часто более коротких) путей к классам. Стоит ли жертвовать краткостью ради предотвращения того, чтобы два разных класса имели одинаковый пакет?