Методика организации командной работы над Flash-проектом
Особенности совместной работы механизмов sharing
Выше мы рассмотрели возможности применения author time sharing и runtime sharing по отдельности.
Теперь приведем два примера, когда может быть полезно использовать оба механизма совместно.
Замена путей runtime sharing с помощью author time sharing
Представьте себе такую ситуацию: вы используете только runtime sharing (без author time sharing ) для своих нужд. В один прекрасный день возникает необходимость положить библиотечные файлы не в подкаталог library, а в тот же каталог, в котором лежат все флэш-ролики.
Что делать?
Об этом нужно побеспокоиться заранее. Для всех компонентов, с которыми вы используете runtime sharing, можно настроить author time sharing из какого-нибудь центрального места. Тогда при возникновении необходимости вы просто изменяете настройки export for runtime sharing для всех компонентов в библиотеке, после чего все флэш-ролики, использующие библиотеку, получают новые параметры runtime sharing из библиотеки во время компиляции.
Правда, по имеющейся у авторов неприятной статистике, что в сложных случаях данный механизм срабатывает лишь на 90%, в остальных случаях сами символы меняются, а параметры runtime sharing - нет. В любом случае, если у вас есть достаточно много флэш-роликов, подгружающих общие компоненты во время выполнения, лучше воспользоваться данным приемом, ведь поменять 100% путей в библиотеке и 10% путей во всех флэш-роликах может все же оказаться намного дешевле, чем поменять 100% путей в библиотеке и 100% путей во всех флэш-роликах.
Насколько известно авторам, во Флэш МХ не существует другого сколько-нибудь приемлемого способа изменения этих путей2Во Flash MX 2004 для этого можно пользоваться .jsfl (JavaScript Flash)-скриптами. .
Подключение нужной комбинации runtime-загрузчиков
Рассмотрим теперь такую ситуацию. У нас есть несколько флэш-проектов, каждый из которых использует часть библиотечных компонентов, загружаемых с помощью runtime sharing. Скорее всего, мы используем runtime-загрузчики, иначе бы ничего не работало.
Но в одном проекте нам нужна одна часть библиотечных компонентов, а в другом - другая. Тем не менее, все флэш-ролики созданы на базе одного и того же шаблона, то есть в первой сцене там лежат все runtime-загрузчики.
Кроме того, мы знаем, что если во Флэш МХ на сцену положен хоть один символ, который импортируется с помощью runtime sharing, и флэш-плеер не может найти соответствующий *.swf-файл (а у нас сейчас получается именно такая ситуация), ничего вообще работать не будет.
Что же делать?
Вручную заходить в каждый флэш-ролик и удалять соответствующий runtime-загрузчик? Это плохой вариант, похожий на дублирование кода.
Есть лучшее решение: положить все runtime-загрузчики в отдельный клип (назовем его группирующим runtime-загрузчики клипом), который лежит в каждом флэш-ролике и импортируется с помощью только author time sharing. Тогда достаточно будет поменять содержимое этого клипа в библиотеке для конкретного проекта - и готово, все нужные " runtime-загрузчики " будут выкачаны автоматически, а ненужные - пропадут.
Это же решение можно (и нужно) применить к контролируемой загрузке клипов (см. выше в этой лекции): регулировать количество счетчиков в зависимости от действительно необходимого числа *.swf-модулей с помощью группирующего клипа.