Как заставить роботов роботать, а людей — думать? Можно ли повысить продуктивность и без того уже, казалось бы, сверхскоростной работы? Как перестать работать и начать жить? Завеса тайны над перечисленными проблемами слегка приоткрывается в посте 0xFFFFFF о том, как сэкономить 90 процентов времени при работе с элементами библиотеки во Flash. А первый комментарий к посту добавляет ощущения реальных глубин Flash IDE, которые мы не постигли до конца.
К этой же проблеме есть большой перечень приемов по облегчению жизни флэш-разработчика — я там столько нового узнал, там столько всего понаписали — спасибо, ребята!
Включив следующие поисковые плагины для Firefox (два клика), вы получите не только самый быстрый, но и самый умный поиск по ActionSctipt 3, Flex 2, Flex 3, Adobe Labs и документаци к Flash / Flex:
Продуктивного вам поиска.
Вы наверное уже заметили, что процесс установки новых Adobe Flash CS3, Dreamweaver и т.п. слишком долог даже на быстрых машинах. При этом ничего особенного не происходит, кроме установки загадочных "Shared Components" (или как их там). Загадочных и необязательных средств интеграции, следует понимать...
Подтверждением тому есть недавно случившаяся со мной история: разыскивая в домашней локалке дитрибутив Flash CS3, я оного так и не нашел; зато обнаружил уже установленное приложение у кого-то в Program Files. Скопировал себе на машину - и вуаля, заработало как ни в чем не бывало, включая создание стандартных пользовательских каталогов при первом запуске приложения.
А с вами случалось подобное, возможно - с другими продуктами семейства CS3?
Есть у среды разработки флэша такая проблема - в библиотеке появляются "битые" символы, чаще всего это растры, и откуда они берутся битыми, загадка до сих пор. А результаты их появления - самые печальные, вплоть до невозможности нормально работать с исходным файлом: удалить битый символ не получается, так как при его выделении Флэш просто обваливается.
Застраховаться от такой ситуации невозможно, проблема всплывает у самых разных людей.
Иван Дембицкий в конференции ruFlash предложил гениальное в своей простоте решение:
> создай в либе два мувика с такими именами, чтобы они расположились > непосредственно перед битым битмапом и сразу за ним. > выдели верхний и с шифтом кликни по нижнему. > должны выделиться все три. > после этого кликай на мусорник в папке или del.
Царь. Просто царь.
Еще не зная, что весьма короткая мысль разрастется на заметку в несколько абзацев, я запостил текст "Как избежать ловушки Допосинения" в ЖЖ. Но теперь я вижу, что на страницах Ф. Потрошителя эта запись будет тоже актуальна (если не более). Поэтому даю здесь ссылку на нее, а комметариями делитесь хоть тут, хоть там. Главное -- избежать Допосинения %-P
Расширение LiveHTTPHeaders для FireFox позволяет видеть, что именно гуляет между вашим браузером и сервером. Приятным сюрпризом для меня было увидеть там "Content-Type: application/x-amf". Эх, жаль, внутренностей amf только и не показывает.
А хорошим дополнением к LiveHTTPHeaders будет кнопка очистки кэша браузера "Clear Cache", еще одно расширение для Firefox (после установки вам нужно вручную добавить ее на панель инструментов).
Вдвоем эти экстеншены помогают отлаживать клиент-серверные взаимодействия.
Я об этом еще не писал, а стоило бы. Вопрос такой: как должно происходить редактирование содержимого сайта? Ответ: а так же, как происходит правка любого документа, то есть должно править непосредственно страницу с содержимым, а не отображение этого содержимого в админ-части сайта. Админка должна быть сведена к минимуму; все, что можно ввести руками прямо на страницу, там же и должно вводиться, а изменения должны быть видны сразу и снова там же.
Страница и ее админка должны быть одним целым и находиться по одному адресу. Вот о чем я мечтал уже давно.
А что мы имеем на данный момент? В подавляющем большинстве случаев мы имеем устаревшую многоступенчатую модель действий "зашел в админку -> изменил контент -> зашел на сайт -> оценил изменения". Но свет в конце тоннеля уже виден. Его первым лучом стала флэш-система управления сайтом fCMS. Она позволяет редактировать текст и изображения на страницах флэш сайтов (знаю, для многих фраза "страница флэш-сайта" звучит дико, а часто это и выглядит дико, хехе :), не покидая этих страниц. На самом деле, это пока похоже скорее на зародыш той системы управления контентом, что должна стать Человечной Системой Управления Контентом Сайта. Но и это уже много. Через два месяца идею подхватят аяксовики (если уже не подхватили), чтобы снабдить такой же админкой любой HTML-сайт (на Фликре это уже давно частично реализовано -- там заголовок и описание любой фотки можно редактировать, просто кликнув по ним). Веселуха приближается!
Я поинтересовался, что на эту тему уже было на русском. Оказывается, ShaggySmile писал об этом, а поскольку его сайт лежит (кто знает, почему?), то вот ссылка на закэшированную Гуглом версию его страницы: Вся правда про fCMS, а вот еще одна, тоже из кэша: fCMS – система управления flash-сайта. По тем ссылкам и отзывы пользователей fCMS есть. Кстати, при поиске нашлось еще несколько мест, где люди искали разломанную fCMS, ибо стоит она уже $149.
Кстати, а почему лежит сайт ShaggySmile?
У Макромедии давно уже выложен док на их собственный, документированный, но мало раз залинкованный XPathAPI от Macromedia (пусть и не такой продвинутый, как XPath от XFactorStudio, но тоже неплохо себе работающий :)
(via injun comments)
Сегодня мы раcсмотрим еще один тип заданий, которые умеет выполнять полезный инструмент Ant. Мы увидим, как он удаляет вредные файлы, в данном случае -- кэш браузера. Послушайте меня, на самом деле, это -- не самое лучшее, что вы можете сделать (лучше дерево посадить), но бывает, что процесс отладки приложения заходит так далеко, что в вашем исходном коде все уже проверено-перепроверено, везде где только можно стоят брейкпойнты и трейсы, а все равно ничего не работает. Тогда становится ясно, что подлый баг засел в кэше браузера, и единственный шас его замочить -- это тотальная экстерминация всего кэша. Затем, когда кэш очищен, а баг снова радостно машет вам красным платочком зарождающегося разочарования в людях и технологиях, вы понимаете, что, чорт побери, действительно где-то допустили ошибку... и после этого уже за считаные минуты находите кириллическую "с" вместо латинской "c" в проверке типа "if (mcContainer._name = "mcContainerTest")", а затем еще быстрее находите оператор присваивания ("=") вместо оператора сравнения ("==") в этой же строке кода. Поэтому, что бы кто ни говорил, а очистка кэша браузера имеет важнейшее психологическое значение, заставляя мозг разработчика начинать думать -- а потому что отступать некуда; позади -- чистый кэш!
if (mcContainer._name = "mcContainerTest")
А чтобы удалить файл, нужно знать только одно: путь к нему. В моем случае (кэш браузера Firefox) это путь типа "c:\Documents and Settings\[USERNAME]\Local Settings\Application Data\Mozilla\Firefox\Profiles\[SOME_RANDOM_STRING]default\Cache". (Кстати, сегодня я совершил для себя приятнейшее открытие, обнаружив, что Firefox имеет встроенный навороченный браузер собственного кэша, и вызывается он по гениальнейшему адресу about:cache (вводите этот адрес вручную или открывайте средним кликом в новой вкладке -- иначе не сработает. А если вы еще не иcпользуете Firefox, то начните делать это прямо сейчас, -- и ничего, что коньки IEще не сносились -- на дворе уж лето, вдохните свежего воздуха полной грудью!
c:\Documents and Settings\[USERNAME]\Local Settings\Application Data\Mozilla\Firefox\Profiles\[SOME_RANDOM_STRING]default\Cache
Для очистки кэша заведем в нашем билд-файле (он был описан в предыдущей статье, посвященной сердитой компиляции, вследствие которой ваша сложная флэшка cкомпилится за секунду, и автоматически откроется не в беспомощном стэнделон-проигрывателе, а сразу в окне тестового браузера, да еще и с вашего же сервера, -- и все это по нажатию Ctrl+Enter!)
Итак, вот исходный код, который нужно добавить в билд-файл, чтобь почистить кэш браузера (изменить параметры по вкусу!):
<target name="browser.cache.clean"> <delete> <fileset includes="*" defaultexcludes="no" dir="c:\Documents and Settings\[USERNAME]\Local Settings\Application Data\Mozilla\Firefox\Profiles\[SOME_RANDOM_STRING]default\Cache" /> </delete> </target>
Обратите внимание на то, что операция удаления -- настраиваема: можно указать и шаблон имен файлов для удаления (includes), и шаблон имен для тех, кого не трогать, и, конечно, каталог с жертвами. А чтобы просто удалить нежелательный каталог со всеми потрохами, достаточно написать <delete dir="c:/Program Files/Internet Explorer" /> (нe забудьте после этого установить Firefox). И, наконец, чтобы удалить абсолютно все ненужные файлы, можно обойтись совсем короткой командой <delete dir="*" />, выключить комп навсегда и устроиться в ЖЭК кочегаром, чтобы начать приносить людям пользу.
<delete dir="c:/Program Files/Internet Explorer" />
<delete dir="*" />
На самом деле, цель этой заметки -- еще раз показать функциональность Ant, чтобы убедить еще хоть одного флэш-разработчика перейти к использованию таких повышающих продуктивность работы инструментов, как Eclipse, Ant, MTASC, ASDT/FDT, SWFObject и неконтролируемое чувство юмора. Буквально сегодня я нашел еще пару отличных страниц-путеводителей по Анту: "Apache Ant -- Википедия" и "Top 15 Ant Best Practices". Читайте, применяйте и радуйтесь новой скорости разработки!
А как вы думаете я снова нашел время для написания этих длиннющих, всем уже надоевших статей-новостей? Во всем виноваты Apache Ant, Клишин и Constantiner!
Вот.
Я уже писал, как использовать ant-скрипты для сердитой компиляции флэш-проектов, чтобы тестировать обновленный(е) скомпилированный(е) swf-файл(ы) сразу в окне браузера, содержащем открытый прямо с вашего сервера документ, а не в одиного торчащем окне standalone-flash-проигрывателя.
Сегодня мы рассмотрим, как, базируясь на том же самом билд-скрипте, передать вашему флэш-приложению дополнительные параметры через адресную строку браузера (иными словами, передать параметры через GET-запрос). Один из самых распространненых случаев, когда нам нужен это прием -- это так называемый запрет кэширования swf-файла(ов). Как вы наверняка уже знаете, чтобы загружаемый файл гарантированно обновился, а не брался из кэша браузера, существует верный способ: изменять путь к нему, приписывая к этому пути параметр с изменяющимся значением. В результате html-код будет выглядеть как: <param name="movie" value="app.swf?v=1.0.121">. В качестве изменяющегося параметра мы будем приписывать номер билда, увеличивающийся на единицу при каждой компиляции проекта. Его еще называют минорной версией и стандартно изпользуют как в Java, так и в .NET.
<param name="movie" value="app.swf?v=1.0.121">
Итак, разберемся, что нам нужно получить. Начинаем "с конца":
Всего три шага к решению задачи! Из них первый не требует никаких усилий вообще. Второй шаг тоже несложный, но нужно акцентировать внимание не том, как именно мы возьмем значение параметра из адресной строки и передадим его флэш-объекту. Для этого лучше всего подходит SWFObject, так как у него уже есть встроенный и тыщу раз протестированный метод getQueryParamValue(), который берет аргументы адресной строки браузера и приписывает их как параметры swf-объекта прямо в исходный код: so.addVariable("v", getQueryParamValue("v")); so.write("flashcontent"); этим мы и воспользуемся!
getQueryParamValue()
so.addVariable("v", getQueryParamValue("v")); so.write("flashcontent");
Кстати, если вы до сих пор не используете SWFObject для встраивания флэш-приложений в свои страницы, то вам стоит начать это делать прямо сейчас, благо есть понятная и компактная русскоязычная инструкция к SWFObject от МК. Вообще, без SWFObject лучше ничего дальше не делайте, потому что он и проблемы отображения Flash в IE решает (помните историю с Eolas-патентом, из-за которой мы до сих пор выгребаем?), и версию проигрывателя может легко определить. К поисковикам он тоже дружелюбнее всех остальных способов встраивания флэша в веб-страницу. При этом он прост и элегантен! В общем, если ваши лыжи при скольжении по асфальту до сих пор издают неприятный звук, переходите на использование SWFObject как можно скорее!
Третий шаг производится в билд-файле. Для увеличения номера билда в ant имеется спецсвойство <buildnumber />. Оно принимает аргумент "file" (по умолчанию он равен "build.number")—имя файла, в котором будет храниться номер билда. Если такого файла нет, он будет создан в корневом каталоге проекта. Если уже есть—то хранящийся в нем номер билда увеличивается на единицу (также в этом файле хранится дата/время последнего билда).
<buildnumber />
file
build.number
Используем же свойство <buildnumber /> в билд-файле из предыдущего урока, посвященного сердитой компиляции! Для этого добавим в него новую цель "build.number.increment" и обеспечим ее вызов из основной цели "build" прежде двух других целей, "mtasc.compile" и "run.html". И, наконец, в цели run.html припишем увеличенное значение из build.number к аргументу output.html,—обратите внимание, ради этого последнего действия все и затевалось: <arg line="${output.html}${build.number}" />.
build.number.increment
build
mtasc.compile
run.html
output.html
<arg line="${output.html}${build.number}" />.
Заметьте, как выглядит теперь аргумент output.html: он заканчивается строкой "/index.html?v=0.0."—таким образом, после приписывания к нему номера билда получится нечто вроде "/index.html?v=0.0.121"—и последнее число будет автоматически увеличиваться с каждой компиляцией и попадать в адресную строку браузера. А Javascript из страницы index.html будет брать этот аргумент из адресной строки и приписывать его к параметру movie swf-файла, и мы получим требуемый: <param name="movie" value="app.swf?v=1.0.121">. Кстати, флэш-приложение app.swf может затем использовать этот параметр во всех своих методах загрузки внешних данных, таким образом исключая кеширование и их тоже!
/index.html?v=0.0.
/index.html?v=0.0.121
movie
Вот обновленный код файла build.xml (новые строки выделены жирным):
<?xml version="1.0"?> <project default="build" basedir="."> <property name="mtasc.path" value="C:\Program Files\Mtasc\mtasc.exe" /> <property name="matsc.args" value='App -version 8 -swf "d:\projects\[PROJECT]\bin\app.swf" -cp "[DISC]:\Documents and Settings\[USERNAME]\Local Settings\Application Data\Macromedia\Flash 8\en\Configuration\Classes" -cp D:\Projects\[PROJECT]\classes -cp D:\Swf\classes' /> <property name="web.browser.path" value="c:\Program Files\Firefox\Firefox.exe" /> <property name="output.html" value="-url http://localhost/[PROJECT]/index.html?v=0.0." /> <!-- property name="flash.player.path" value="c:\Program Files\Macromedia\Flash 8\Players\Debug\SAFlashPlayer.exe" / --> <!-- property name="flashcommand.path" value="'c:\Program Files\FlashCommand\FlashCommand.exe'" / --> <!-- property name="" value="" / --> <target name="build" depends="build.number.increment, mtasc.compile, run.html" /> <target name="build.number.increment" > <buildnumber file="build.number"/> </target> <target name="mtasc.compile"> <exec executable="${mtasc.path}" > <arg line="${matsc.args}" /> </exec> </target> <target name="run.html"> <exec executable="${web.browser.path}" > <arg line="${output.html}${build.number}" /> </exec> </target> </project>
Как видите, Ant полезен во многих отношениях. И если вас интересует этот действительно мощный инструмент, то вот пара толковых ресурсов для тех, кто только начинает с ним знакомиться, и это по-русски:"Ant за 10 шагов — документация Javatech" и "Автоматизируйте процесс сборки Java программ с помощью Ant". И, конечно, бессмертная статья от Константинера: Разработка Flash-проектов с использованием Apache Ant (доклад на семинаре New Media)!
Совсем древнее: 17-20.09.2002, 23-30.09.2002, 01-04.10.2002, 07-11.10.2002, 14-19.10.2002, 20-26.10.2002, 27.10-02.11.2002, 04-08.11.2002, 11-16.11.2002, 18-23.11.2002 25-30.11.2002, 02-07.12.2002, 09-14.12.2002 Сайт заработал 17.09.2002