Чудо{вищные} заметки

jquery обзавёлся собственной promote-кнопочкой.
Сам за неё голосовал – симпатичная и ненавязчивая:

В догонку: у jquery есть наглядный мануал

Update:
нашёлся русский перевод руководства по jquery для новичков – может кому-нибудь пригодиться…
Technorati Tags: web, dev, js, jquery

Ещё немного о jquery:
замечательный метод ready в IE в некоторых случаях не желает работать.
Документация честно предупреждает о том, что если для body уже есть onload-handler, то метод может не сработать. Но обработчиков нет, а ready срабатывает 2 раза из 10 попыток. При этом иногда IE ещё не успевает обсчитать некоторые свойства объектов (замечено на offsetTop).
А если отложить выполнение даже на 1 миллисекунду (через setTimeout), то всё выполняется так как задумано.
На помощь приходит функция из БазыЗнанийXpoint-а о которой я писал раньше. Работает как часы (но без timeout-ов).

Как же достал этот IE…

Technorati Tags: web, dev, js, ie, onload, jquery

Нашёл две интересные утилитки, которых “так давно не хватало” – jslint и jspacker.

Как ясно из названий, первая проверяет “скармливаемый” файл на наличие ошибок и ругается warning-ами на всевозможные недочёты (тчк-зпт не поставил, не указал явно тип переменной и т.п.), а вторая (perl-версия), соответственно “пожимает” файл весьма интересным способом – суть объяснить не могу – это надо видеть (оценить полёт мысли можно сходив по ссылке выше).
Скрипты стали “лучше”, “чище” и загружаются быстрее, что не может не радовать.

Поскольку полезность утилиток неоспорима, я создал на их основе два task-а для phing-а(подробнее о нём в следующем посте), автоматизировав сборку проектов перед подачей на стол выкладыванием на production-сервер.

Upd:
пару дней назад (04.11.06) в транке phing-a появился JsLinkTask – использует именно jsl. Видимо идея витала в воздухе…
P.S.
неплохо бы было найти ещё и csspacker – стало б вообще замечательно…

Technorati Tags: web, dev, js, tools

Исходные данные:

• есть html с swf-ками
• есть IE
• есть рамка вокруг swf-ок и hint с напоминанием о том что для использования объекта надо сначала его активироваит кликом
• есть вполне себе самодостаточный инструмент для внедрения флеша в html, который помимо того что замечательно детектит версию плеера, показывает альтернативный контент для тех у кого не обнаружилось необходимого плеера и вообще супер-комбайн – SWFObject, заодно избавляет от этих злосчастных рамок.
• ну и наконец есть “сто тыщ милёнов” уже созданных страниц со флешем.

Имея эти данные и не имея желания переписать все уже созданные страницы для использования SWFObject я задался целью найти менее трудоёмкий путь к избавлению от “рамок”.

“Путь” желающие могут изучить по предыдущим постам, а я лишь резюмирую случившееся:

1. В первый же день когда я обнаружил рамки, нашёлся неочевидный выход – если через document.write(‘<object … ><param…./></object>’) IE отображает объект без уродской рамки, то разработчики IE в попыхах сделали заплатку,которая рисует рамку только вовремя рендринга страницы, проверка “на вшивость” показала, что конструкция object.outerHTML=object.outerHTML; даёт тот же эффект, что позволило пройтись по всем getElementsByTagName(‘object’) и провернуть над ними “экзекуцию”.
2. Но выяснилось что при этом теряются flashvars (в наших проектах весьма часто используемых) – пришлось весьма шаманским способом их “сохранять” при “магическом переписывании”.
3. Далее выяснилось что подобная операция приводит к утечке памяти и краху IE. Попытки бороться с этим только “оттягивали конец” (гусары – молчать!)

Тем временем в новых проектах я уже использую SWFObject, максимально упростив работу по его внедрению посредством плагина к smarty, publish extension-а к Flash-у и матерного слова.

А мысль о том как же бороться с проклятым IE меня не покидает…

В итоге решение оказалось на поверхности – использовать swfobject для переписывания уже внедрённых флешек:

1. берём object, добавляем перед ним div
2. создаём swfobject, копируем необходимые данные из object
3. удаляем object из DOM-дерева
4. Повторяем до потери пульса

Итоговый код можно скачать по прежнему адресу flash_replacer (v 0.7) (особо отмечу что для работы НЕОБХОДИМ swfobject.js, который надо включать в html до flash_replacer-а)
В нём в данный момент нехватает аналогичного “прогона” по embed-ам, а в остальном вполне рабочий код, который на тестовых системах не вызывает падения IE.

Upd: “Это” скоро кончиться

Technorati Tags: flash, ie, activex, swfobject

Про Selenium я уже писал и не раз.. В очередной раз решил узнать на чём остановилась разработка этого проекта.

Оказалось она вовсе не остановилась… – движется семимильными шагами в сторону автоматизации автоматизированного ;o)
Новое детище товарищей из OpenQA Team – Selenium Remote Control. Это сервер, который в ответ на HTTP запросы может запускать-прибивать браузер, выполнять команды(тесты) selenium-а,выдавать результат,сохранять результат в файл .

Кто-то скажет (кто-то уже сказал) “- и на кой ляд это нужно?” – а нужно это в первую очередь для автоматизированной проверки работы “сложных” UI на рабоспособность в разных браузерах. В комплекте с сервером идут примеры коннекторов на ruby, .NET, python, perl (из последнего легко понять как можно на ходу посылать команды разным браузерам и проверять результат.

Видимо отсутствие коннектора для php “вынудило” товарища Shin Ohno исправить эту оплошность и он “зачал” своё детище – PEAR::Selenium

пример использования это чуда инженерной мысли можно посмотреть здесь.

О себя хочу сказать что использование этой связки в тестовом окружении вызвало дикие тормоза. Похоже проблема кроется где-то глубоко в исходниках сервера(Shin похоже об этом писал , но я в ипонском не силён), поэтому пока использую selenium-rc в batch-режиме – скармливаю ему файл со списком тестов и прогоняю их 3 раза (в IE, FF и Opera) :

>selenuim-rc.cmd project
java -jar selenium-server.jar -htmlSuite “*firefox” “http://project.lan” “Z:\project\public_html\.tests\.cases\htmlSuite.html” “Z:\project\public_html\.tests\.cases\result_firefox.html”
[..]
Killing Firefox…
Tests failed
Shutting down…
[..]
Killing Opera…
Tests failed
Shutting down…
[..]

Некогда “простенький” инструмент потихоньку обрастает “фичами”, буду надеятся что не зря…

Technorati Tags: web, dev, selenium

Эпопея с рамками вокруг флеша продолжается…

Сперва обнаружилось, что код, который я приводил в прошлом посте не работает в IE версий ниже 6-ой (точнее он работал, но не совсем так как задумано ;o) ) . Пришлось его немного подточить – flashvars теперь беруться не из тега PARAM, а из свойства altHTML у тега OBJECT (это свойство доступно только в IE и содержит html код с тегом EMBED), и вот код работает в IE 5.5 и IE5… но…

Но были замечены падения браузеров (5-го и 5.5) после переписывания outerHTML…
С другой стороны рамки вокруг ActiveX в этих браузерах мною замечены не были… посему код flash_replacer.js теперь исполняется только в IE6 (седьмой покамест beta – на него не рассчитываю).

Собственно код находиться здесь. (v.0.3.1) (v.0.4)(v.0.4.1)(v.0.5)(v.0.5.1)(v.0.6)(v.0.7)

Нуждающиеся в нём могут качать и пользоваться.
Знающие могут помочь мне с ответом на вопрос – в IE версий ниже 6-ой рамки есть или нету?
Баги и вообще любые фидбеки приветствуются…

UPDATE:
Исправил маленький “глюк”, переименовал файл – теперь последняя версия называется flash_replacer_latest.js (находится по ссылке выше). Просьба к товарищам ссылающимся на данный файл поменять ссылку на файл (заранее спасибо за изменения и за ссылку вообще ;o) )

27.04 – Поправил проверку classid и сделал аналогичный прогон по embed-ам вне object-а

11.05 – Поправил регулярку, с помощью которой вытаскивались flashvars(они могут быть многострочными)

23.05 – удаляю outerHTML на window.unload (ie иногда падал из-за memory leak), flash_replacer теперь запускается только в winxp ie6+. Подробнее чуть позже опишу в третьей части “эпопеи”…
24.05 – workaround для flashvars, которые вставляются как get-параметры в src мувика

30.06 – теперь используется SWFObject для внедрения “переписанных флешек”, в связи с этим баги с падением IE исчезли, но “маленько” уменьшилась функциональность – восстановлю на днях работу c embed и flashvars, которые передаются get-параметрами в src мувика

Уже месяц висит draft-пост про “завершение эпопеи”… но похоже конца этой “эпопеи” нет и не предвидится ;o)
Продолжение следует…

Technorati Tags: flash, ie, activeX

Что ни день, то сюрприз…
Оказывается XmlHttpRequest в этой самой Opera живёт своей собственной жизнью – он существует отдельно от браузера, не знает о существовании cookies и настроек способных "отрегулировать" такое поведение объекта я не нашёл.

Может оно конечно так и задумано (из соображений безопастности, желания отличиться и т.п.), но тогда почему в других браузерах (в частности FF,SM, IE) XMLHttpRequest вместе с запросами отсылает доступные cookies (хранимые и сессионные) ? Они действуют неправильно ? Это небезопастно ? Или где?

Выходов вижу несколько:

1. Передавать идентификатор с URL-ом (ну нах)
2. Делать альтернативный интерфейс без XMLHttpRequest (ну о-о-очень лениво…)
3. Писать идентификатор в javascript и потом для Opera добавлять xmlhttprequestObj.setRequestHeader('Cookie',from_js_session_name + '='+from_js_session_value);
4. Забить на Opera

Почему мне наиболее симпатичен четвёртый вариант ? До смерти надоело подстраиваться под каждый релиз этой самой злоеб Оперы. Хватает гемороя с IE.

P.S.
И мне не будет стыдно смотреть в глаза пользователям Opera. Вот такое я Чудовище.

20.05.2006 UPDATE:
Спасибо всем откликнувшимся. Проблема решилась…
2WebAngel Да спасибо, действительно дело было не совсем в кукисах (не совсем в XHR). точнее не только в них.
(Опера скачивала favicon.ico, которого не было, далее mod_rewrite -> обработчик.php и т.д. и в общем вызывался нужный файл, в котором требовались треклятые куки.
НО запрос к favicon.ico в опере не передаёт COOKIE.
Что к чему и почему я не знаю. но поскольку все другие-остальные браузеры их передаёт считаю это ненормальным)

Technorati Tags: dailyWTF, opera, favicon