ActionScript 2: программирование во Flash MX. Для профессионалов
[Заказать]
Я работаю с Flash’ем уже несколько лет и всегда испытывал легкое разочарование от того, какой html-код следует писать, чтобы встроить ролик в веб-страницу. Недавно я создал сайт на XHTML, и мое разочарование возросло: html-код, необходимый для отображения ролика на сайте, просто не соответствует стандартам. На помощь был призван новый, более аккуратный метод, который бы не конфликтовал, а дружил со стандартами XHTML.
Доверяй, но проверяй
Flash всегда поставлялся со средствами разработки, позволяющими автоматически генерировать страницы, содержащие флэш-ролики. Начиная с четвертой версии, сама программа стала создавать подобных монстров:
<object
classid="clsid:D27CDB6E-AE6D
-11cf-96B8-444553540000"
codebase="http://download.macromedia.com /pub/shockwave/cabs
/flash/swflash.cab#version=6,0,0,0"
width="400" height="300" id="movie" align="">
<param name="movie" value="movie.swf">
<embed src="movie.swf" quality="high"
width="400" height="300"
name="movie" align="" type="application/x-shockwave-flash"
plug inspage="http://www.macromedia.com
/go/getflashplayer"> </object>
Учитывая то, что такой код используется на 95% страниц, он стал стандартом де-факто.
Как нетрудно заметить любому, кто уделил внимание устрашающему html-коду выше, для отображения роликов используется два главных тэга: <object>
и <embed>
.
В то время, как Internet Explorer и все хорошие браузеры пользуются соответствующим стандартам тэгом <object>
, Netscape и браузеры, считающие себя его друзьями, вовсю развлекаются с <embed>
, полностью игнорируя <object>
. Тэг <object>
содержится в спецификации XHTML, но не совсем верно реализован в IE-дружественных браузерах: он просит браузер запустить объект флэш-плейера и загрузить в него ролик. Элемент <param>
этого тэга играет роль злого гения: передает плейеру столько параметров, сколько им (тэгом) было задано.
<embed>
не попал в спецификацию XHTML. Параметры в нем передаются через пары «имя/значение».
Элемент <embed>
Этот элемент был создан Netscape как собственный метод встраивания плагинов и плейеров в веб-страницы. Он не попал в XTHML-спецификацию и… мы же не любим нестандартные тэги, правда? Так что — прощай, <embed>
… и не забудь закрыть за собой дверь!
Элемент <object>
Мы распрощались с тэгом <embed>
и у нас на руках остался только <object>
, так что придется ему вывернуться наизнанку, стараясь нам помочь. Приятная новость — как для нас, так и для него — это то, что почти каждый браузер в наши дни так или иначе поддерживает этот элемент.
У элемента <object>
нет обязательных атрибутов, но список доступных действительно велик. Ниже приведены те, которые могут нас заинтересовать и понадобятся в дальнейших научных исследованиях.
classid (URI) — может использоваться для указания местоположения реализации объекта при помощи URI. Этот атрибут может быть применен вместо атрибута data
(рассмотрен ниже) или вместе с ним.
codebase (URI) — указывает основной путь к обработчику относительных путей, заданных атрибутами classid
, data
и archive
. Когда этот атрибут не указан явно, он принимает значение базового URI текущего документа.
data (URI) — может быть использован для указания местоположения данных, ради которых затевались все манипуляции с тэгом <object>
, или даже для проставления ссылки на серийный выпуск объекта, который сможет восстановить локальную копию.
type (content-type) — указывает тип содержания для данного «объекта».
codetype (content-type) — указывает ожидаемый тип содержания «объекта» при его открытии с помощью classid
.
Есть также другие атрибуты, которые позволяют делать то, что можно запросто реализовать и в самом flash`е, а также такие, как width
, height
, id
, class
и другие общеприменимые атрибуты. Те параметры, которые перечислены выше, являются значимыми при встраивании флэш-роликов.
Другой важной вещью, которую стоит запомнить всем разработчикам, является то, что <object>
может содержать вложенные элементы, которые будут отображаться, если отображение ролика не поддерживается компьютером (не установлен флэш-плейер). Кстати, вот объяснение, почему этот проклятый <embed>
работает в Netscape и его дружках.
Действо
Вооружившись более глубоким пониманием вопроса, я провел несколько операций, проверяя их в разных браузерах. Для начала я убрал ненавистный нам всем <embed>
, таким образом код стал соответствовать стандартам XHTML:
<object
classid="clsid:D27CDB6E-AE6D
-11cf-96B8-444553540000" codebase
="http://download.macromedia.com /pub/shockwave/cabs
/flash/swflash.cab#version=6,0,0,0"
width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
К сожалению, это не работает в не-IE браузерах, но мы ведь и не ожидали, что они сдадутся так быстро. Потратив некоторое время на поиск, я обнаружил, что атрибут classid
является специфическим для ActiveX-конфигурации браузера. Кстати, это именно он уговаривал Netscape и Mozilla игнорировать объект. Между тем, роль этого атрибута крайне важна: он сообщает браузеру, каким плейером проигрывать объект. Так что нам не удастся так же легко, как в прошлый раз, помахать ручкой и попросить закрыть за собой дверь.
К счастью, флэш-плейер откликается также на содержание с MIME
-типом application/x-shockwave-flash
. Это великолепно хотя бы потому, что есть возможность указать тип объекта, используя параметр type.
Итак, мы все-таки прощаемся с
classid="clsid:D27CDB6E-AE6D
-11cf-96B8-444553540000"
и добавляем
type="application/x-shockwave-flash"
Codebase
Предыдущие махинации все равно не привели к тому, чтобы Netscape показывал флэш-ролики. Следующим препятствием на пути отображения стал атрибут codebase
, который содержит путь к копии плагина Flash на сервере Macromedia. На самом деле, атрибут совсем не предполагался для такого использования, поскольку все пути в его значениях должны быть в том же домене по соображениям безопасности.
Во многих браузерах (и особенно в IE) этот атрибут выполняет другую функцию: в пути, который содержит его значение, записан необходимый для запуска ролика номер версии флэш-плейера. Выполнив простое сравнение, браузер может предложить пользователю скачать более свежую версию проигрывателя. Обратной стороной медали в данном случае является то, что этот атрибут останавливает проигрывание роликов в Netscape и Mozilla, если его использовать данным образом. Значит, придется пустить его в расход. Как восполнить потерю функциональности мы обсудим позже.
Итак, после того, как codebase
мы признали не жильцом, html-код наконец-то стал выглядеть более или менее изящно:
<object
type="application/x-shockwave-flash"
width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
Если попробовать открыть этот код, он все равно не отобразит ролик в Netscape. Дойдя до этой точки, я испугался, что во всей Вселенной не сыскать мне способа осуществления задуманного. Так что мне пришлось прибегнуть к обычному для таких ситуаций испытанию самых безумных идей.
Эврика!
Когда я воспользовался атрибутом data
, у меня чуть не случился удар — ролики начали внезапно проигрываться в Netscape и Mozilla. Как выяснилось, IE тоже не отказывался их показывать.
<object type="application/x-shockwave-flash"
data="movie.swf"
width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
После серии проверок с большими роликами я заметил недостаток: браузер IE под Windows не начинал проигрывание ролика, пока не скачивал его весь, от начала и до конца. Понятно, что такой недостаток приемлем для небольших роликов, но никак не может ужиться с огромными. Я пришел к выводу, что создание соответствующего стандартам кода возможно, но только после того, как Microsoft исправит свои ошибки.
Метод Satay
Несколько дней спустя я обсуждал эту проблему с Джефри Зельдманом (Jeffrey Zeldman), объясняя, насколько близок я был к решению проблемы. Он тоже заинтересовался, поскольку столкнулся с той же проблемой, разрабатывая последние проекты. Все это заставило меня задуматься, и, наконец, когда я брел к дому по пустынным ночным улицам, меня поразила догадка.
Как мы уже выяснили, проблема заключается в том, что Windows не хочет проигрывать ролик, пока не скачает его весь. А как насчет создания очень маленького ролика, который в первом же кадре будет подгружать в себя тот ролик, который мы действительно хотим показать?
Я проверил эту догадку, и она сработала. Возможно, это небольшое заигрывание со стандартами, но во вполне допустимых пределах. Самое хорошее в этом способе то, что можно создать универсальный контейнер и пользоваться им в дальнейшем для подгрузки роликов с такими же пропорциями, как и у ролика контейнера.
Образно говоря, не имеет значения, изготовлен ли ролик из ветчины, курятины или говядины, вам все равно придется сначала обмакнуть его в кетчуп, чтобы ощутить его настоящий вкус. Мы назвали это методом Satay.
Ролик-контейнер
Я создал новый ролик, в первом кадре которого разместил следующий ActionScript:
_root.loadMovie(_root.path,0);
Он указывает флэш-плейеру, чтобы тот загрузил ролик, имя которого хранится в переменной path на нулевом уровне. Осталось только динамически передавать эту переменную. Благодаря строковым параметрам и тому, что они обрабатываются Flash`ем, это даже не назовешь проблемой. Вот как решается этот вопрос: c.swf?path=movie.swf
Ролик-контейнер называется c.swf, и при таком вызове выражение, указывающее на загрузку нужного ролика, выглядит для Flash`а так: _root.loadMovie("movie.swf",0);
Можно изменять поведение контейнера, пересылать значение переменной, используя методы post
и get
, но следует всегда помнить, что размер ролика-контейнера должен быть очень маленьким.
Финальный код
Осталось только завершить начинание. Итак, мы отказались от многих атрибутов, добавили новые, перемешали и залили в судочки:
<object
type="application/x-shockwave-flash"
data="c.swf?path=movie.swf" width="400" height="300">
<param name="movie"
value="c.swf?path=movie.swf" />
</object>
Это ли не тот код, о котором я говорил с самого начала? Но не следует забывать о том, что, отбросив codebase
, мы лишили себя неплохой части функциональности. Что же делать?
Компенсация жертвам
Главная проблема при отстутствии атрибута codebase
заключается в том, что браузер просто не будет предлагать пользователям обновить флэш-плейер. Как нам с вами известно, надеяться на то, что большинство пользователей обновит свои проигрыватели собственноручно, не приходится.
Решение этой проблемы на удивление несложно: просто принесите в жертву какой-то пустой ролик в самом начале страницы. Понятно, что при его объявлении следует указать атрибут codebase
. Таким образом, жертвуя 1 КБ трафика, мы достигаем нужной функциональности. Пусть это не самый аккуратный, зато действенный способ, который не наживет вам врагов.
Альтернативное содержание
Помните, что я говорил о том, что тэг <object>
может содержать вложенные дочерние тэги, которые браузер будет обрабатывать, если у него ничего не получится с открытием объекта? Это может нам очень пригодиться.
Если просмотреть исходный код главной страницы сайта Macromedia, можно заметить, что они подставляют картинку для тех, кто не может просматривать флэш-ролики. Код определяет, установлен ли флэш-плейер на компьютере, и выполняет Java-скрипт, который динамически вписывает нужный HTML-код. Жуть как неудобно. Вот как сделал бы это я:
<object type="application/x-shockwave-flash”
data="c.swf?path=movie.swf"
width="400" height="300">
<param name="movie"
value="c.swf?path=movie.swf" />
<img src="noflash.gif"
width="200" height="100" alt="" />
</object>
Если браузер не знаком с MIME-типом application/x-shockwave-flash
, он просто покажет посетителю картинку noflash.gif.
Продолжение следует
Я написал эту статью, зная, что это исследования всего одного человека, так что научно-исследовательская работа на эту тему продолжается. Отнеситесь к приведенной информации как к научной теории: она считается доказанной, пока не доказана обратная.
Статьи по теме: