пятница, 16 сентября 2011 г.

"Заплатка" ("Patch") как JavaScript шаблон проектирования

Недавно пришла в голову мысль, что "Заплатка" вполне заслуживает звания JavaScript-шаблона проектирования. По-англицки можно было бы назвать "Patch". Суть его не собственно в хаке, а скорее в том, что бы отделять код, написанный в соответствии со стандартом, от кода, который приспосабливает браузер, не поддерживающий стандарты, корректно работать со стандартным кодом при помощи того или иного хака.

Сам я использую заплатки уже достаточно давно. Разумеется, основные заплатки ставятся на IE6-8, с которыми, по-видимому, ещё предстоит много возни, пока они, наконец, отомрут. Однако так же не помешает установить их и для старых версий иных браузеров.

Итак, часто JavaScript-разработчики вставляют код, направленный на совместимость, непосредственно внутрь логики основного сценария. Например, если нам нужно установить слушателя события загрузки страницы, мы могли бы написать:

function onLoadListener() {
    //some code...
}
if ('addEventListener' in window)
    addEventListener("load", onLoadListener, false);
else if ('attachEvent' in window)
    attachEvent("onload", onLoadListener)
В принципе, ничего нет плохого в том, что бы так делать, однако проблема заключается в том, что при написании сложных сценариев ваша голова итак забита сложностью решаемой задачи и Вам не захочется отвлекаться ещё и на все эти глупые браузеросовместимости - вам бы хоть как-то её решить. И потом, при отладке и чтении кода вам всё время будет попадаться на глаза этот фрагмент и мозолить глаза. С точки зрения алгоритма он не несёт никакого смысла, а на экране занимает место, которое могли бы занять более полезные смысловые фрагменты кода - видя их одновременно, без прокрутки, Вам могла бы придти в голову ценная мысль, которая не пришла бы, если бы вам пришлось вращать колесо мыши, что бы всё увидеть.

Тем не менее, сократить эту конструкцию до стандартного кода

addEventListener("load", function() {
    //some code...
}, false);
мы не можем, поскольку стандарты поддерживают не все браузеры, в которых нам хотелось бы, что бы наш сценарий успешно выполнялся. Для остальных же браузеров у нас есть многочисленные хаки. Так как же быть?

Как только я в своих проектах сталкиваюсь с несовместимостью работы того или иного браузера со стандартными методами, первая мысль у меня возникает о том, что бы вынести обеспечение совместимости в отдельный от основного код, что бы он его не захламлял. У меня уже накопилось достаточно много таких заплаток, латающих различные дыры в поддержке стандартов различным браузерами - главным образом IE. Обычно я помещаю их в отдельный файл проекта, называя его "commons.js" (есть и исключения - например в случае, если это нужно только для тестирования, я считаю не зазорным вставлять такой код просто в начало тестового файла).

В данном случае полезной была бы следующая заплатка:

(function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handlerб isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, handler);
        }
})(); //IE patch for window.addEventListener
Здесь элегантно используется то обстоятельство, что ссылка this при вызове в глобальном контексте в функции указывает на объект window. По-этому сразу же после объявления функция просто вызывается.

Здесь не могу не отметить, что заплатка получилась лишь частичная - третий параметр метода addEventListener невозможно эмулировать при помощи метода attachEvent, доступного в IE. Так что в этом случае приходится вызывать исключение, что бы при отладке или тестировании это обязательно всплыло в виде корректного сообщения.

Если необходима реализация парного метода removeEventListener, её легко написать по аналогии, реализовав через метод detachEvent.

Теперь другие элементы, которым так же нужно "привить" правильное поведение, могли бы обрабатываться следующим образом:

setAddEventListener.call(document.getElementById('id1'));
В статье "JavaScript: Реализация pattern`а Singleton" я уже приводил ещё одну заплатку - для безпроблемного объявления объекта XMLHttpRequest (который я нашёл в англоязычной Wikipedia):
// Provide the XMLHttpRequest class for IE 5.x-6.x:
if (typeof XMLHttpRequest == "undefined")
    /** @constructor */
    XMLHttpRequest = function() {
        try { return new ActiveXObject("Msxml2.XMLHTTP.6.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP.3.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP") } catch(e) {}
        try { return new ActiveXObject("Microsoft.XMLHTTP") } catch(e) {}
        throw new TypeError( "This browser does not support XMLHttpRequest." )
    };
Напоследок приведу ещё одну заплатку. Она служит для безпроблемной реализации стандартного метода window.getComputedStyle, отсутствующего в IE вплоть до 8 версии включительно. Кто не знает, это очень удобный метод, позволяющий получать ссылки на объект, содержащий информацию о "вычислимых стилях" для HTML-элемента. Вычислимым называется стиль, специально не установленный разработчиком, однако получившийся в результате вывода браузером этого элемента на странице. IE вместо него имеет свойство computedStyle, доступное у каждого элемента. К сожалению, оно не может представить вычислимый стиль для псевдоклассов, по-этому заплатку можно вставить так же, как и для addActionListener`а - лишь частичную.

Таким образом, вот как можно решить данную проблему несовместимости IE со стандартом:

//IE patch for window.getComputedStyle
if (!('getComputedStyle' in window))
    getComputedStyle = function(element, pseudoclass) {
        if (pseudoclass === null || typeof pseudoclass === 'undefined')
            return element.currentStyle;
        else
            throw new Error("We are in IE, so we haven`t way to get pseudoclass styles of element");
    };

четверг, 21 июля 2011 г.

Я скачал ЕЁ!!!

Самая лучшая книга по JavaScript всех времён и народов! Лучше неё ничего нет!
O`Reilly - Девид Фленаган, «JavaScript. Definitive Guide, 6th edition»(2011) - туда вошли все новшества от HTML5 и ECMAScript 5! :))))

Вот тут она есть - http://uploading.com/files/3735d769/Oreilly.j

Фленаган пишет очень подробно, для профессионалов.

Искал в электронном виде уже месяца два, кучу времени убил – нигде не было, хотя куча вирья всякого пыталась под её видом пролезть на манер файлов «JavaScript_Definitive_Guide,6th_edition.pdf.exe» с иконкой pdf`а... И вот, наконец, она – вот она!!!)

вторник, 31 мая 2011 г.

__proto__ во всех браузерах

Ссылка "__proto__", как известно, указывает на прототип объекта в браузерах FireFox, Google Chrome и Safari. Обычно ссылку на прототип можно получить комбинацией ссылок constructor и prototype, но когда используется классическое для JavaScript наследование:
function A(){/*...*/};
function B(){/*...*/};
B.prototype = new A();
var b = new B();
, то в этом случае вызов
b.constructor.prototype
укажет на прототип конструктора A, а не на созданный объект конструктора A, который передан прототипу:
alert(b.constructor.prototype === A.prototype);//'true'
. Как же в этом случае можно обратиться именно к прототипу объекта b (естественно, не зная, каков его конструктор)? Можно переопределить ссылку constructor у объекта, созданного по конструктору A, указав ей на B:
B.prototype.constructor = B;
, но тогда мы потеряем возможность добраться до прототипа конструктора A, что может так же понадобиться.
Так что остаётся только ссылка "__proto__" - больше никак. Но этой ссылки нет в некоторых браузерах - например, в IE и в Opera`е.
Но если чего-то нету, то можно это недостающее создать самим. Для того, что бы всё заработало везде, надо вставить конструкцию
if (!this.hasOwnProperty('__proto__'))
    /** @type A */ this.__proto__ = arguments.callee.prototype;
внутрь нашего конструктора-наследничка. И тогда всё получится:
function A(){/*...*/};
function B() {
    /*...*/
    if (!this.hasOwnProperty('__proto__'))
        /** @type A */ this.__proto__ = arguments.callee.prototype;
};
B.prototype = new A();
var b = new B();
alert(b.__proto__ === B.prptotype);//'true'
alert(b.constructor.prototype === A.prototype);//'true'

Навигация в Google Cache

Интернет - это целый мир. Сайты в нём как люди в реальном мире - рождаются, живут и умирают. Иногда то, что они умирают, может кому-то не понравиться. Тогда на помощь тем, кто "хотел, но не успел" сохранить те или иные материалы у себя, приходит Google Cache.
При поиске тех или иных страниц в интернете Вы наверняка замечали под каждой ссылкой с результатами поиска ссылочку "Сохранённая копия". Видели? Это и есть Google Cache. Если страницы уже и след простыл, она может всё ещё оказаться в этом хранилище.

Точно не знаю, сколько живут страницы в Кэше`e Google, прежде чем окончательно проститься с Internet`ом, но если хотелось их сохранить, то искать их можно там. Но вот незадача - отдельную страницу найти-то можно, но вот если пропал целый сайт и хочется погулять по этому сайту, покликать на ссылочки почитать много страниц в правильном порядке, то Вас ждёт неприятный сюрприз - все внутренние ссылки будут битые. Т.е. страницы-то в Google Cach`е есть, но вот навигация по ним очень неудобная - нужно каждую из них искать с помощью поисковика Google`а и переходить по ссылке "Сохранённая копия".

Буквально сегодня я столкнулся с тем, что великолепный сайт, посвящённый реальной медицине (а не этой дурацкой официальной, которая не лечит, а наоборот - медленно убивает людей) - http://www.revici.ru/ - исчез и теперь при наборе его адреса попадаешь на какую-то дурацкую рекламу фильмов.
На этом сайте было большое количество интересных материалов, соединённых ссылками. И при его сохранении из этого Кэша передо мной встала проблема перемещения по этим ссылкам.
Но, т.к. я программист, я быстро нашёл удобное решение. Дело в том, что страница из кэша google подгружается, если перед её адресом в адресной строке браузера вставить строку: "http://webcache.googleusercontent.com/search?q=cache:"
Так что я быстренько написал следующий коротенький скриптик:
javascript:
var l=document.getElementsByTagName('a'),
    e=l.length;
for(var i=0;i<e;)
    l[i].href=
        'http://webcache.googleusercontent.com/search?q=cache:'+
        l[i++].href.replace(/http:\/\//gi,'');
void(0);//Писать всё нужно в одну строчку, здесь я разбил для удобства восприятия
Вбил его в панель закладок Google Chrome`а и стал нажимать на эту кнопку каждый раз, как перейду на какую-то страницу с висящими ссылками. Всё заработало! Теперь спокойно могу гулять по ссылкам и сохранять страничку за страничкой :)

четверг, 5 мая 2011 г.

Список используемых программ, которые нужно купить

Приветствую!

Как и многие другие, грешен: пиратствую. Не во всём, конечно - Windows давно лицензионный (а Вы попробуйте сейчас купить ноутбук без лицензионной Wind`ы!), от MS Office`а в виду его большой дороговизны, отказался, перейдя на Open Office (ломка уже прошла))). Но другой хороший софт стоит дорого, а бесплатного на некоторые специфические задачи найти не удаётся.
Однако зарабатываю достаточно много и уже просто неприлично этим делом продолжать заниматься. И совесть всё больше по этому поводу свербит...

Решил опубликовать план по приобретению программ - вдруг кому-то пригодится:
  1. ABBYY FineRider - уже купил. Стоила в р-не полутора-двух тысяч, вроде. Распознавание отсканированных текстов на ура! Вобщем-то по-моему вообще монополист - по крайней мере для русского языка то уж точно. Нужна мне для сканирования некоторых редких старых книг, которые мне попались и теперь их нужно отсканировать и разместить в интернете.
  2. ABBYY Lingvo - нужна, http://translate.ru значительно менее удобен в повседневном использовании, да и обладает менее богатыми библиотеками, которые не всегда выдают нужный результат.
  3. Kaspersky Cristal - до конца года обеспечила контора-производитель, откуда я ушёл месяц назад. Продлять не буду, скорее куплю KIS - Kaspersky Internet Security.
  4. Sparx Systems Enterprise Architect 8.0 Professional. Хоть и не поддерживает JavaScript, для которой я его в основном использую, но прога незаменимая, подсел на неё, ещё когда работал в Лаборатории Касперского и теперь сложные объёмные решения без неё получается сильно дольше планировать и обдумывать, чем с ней - все аналоги либо намного дороже, либо намного хуже, либо и то и другое.
  5. SPKet IDE - плагин к Eclipse, платный для коммерческого использования. Очень удобная штука для JavaScript-программирования - лучшая, что я видел.
  6. Altova XMLSpy. Непревзойдённый XML-редактор, как без рук без него - все аналоги, которые видел, намного хуже.
  7. Saxon. Часто не хватает возможностей XSLT 1.0 для текущих задач, а бесплатных удобных библиотек XSLT 2.0-преобразований найти не удалось. Saxon - практически единственная полноценная библиотека для XSLT 2.0 преобразований.
  8. IntelliJ IDEA Corporate. Лучше среды для Java-разработки придумать, по-моему, просто невозможно.

среда, 12 января 2011 г.

JBoss 6 - final?

Ребята из Red Hut, конечно, жгут!.. Выпустили перед самым новым годом (28 декабря) final-версию JBoss`а 6. Подарок типа на новый год людям! А Tomcat 7, который входит в него как сервлет-контейнер, всё ещё beta!!! Нормальный "подарочек", а?.. :))))

среда, 16 декабря 2009 г.

Планы на будущее

Давно не писал, потому что был несколько нагружен работой и не успевал, а халтуру писать тоже не хочется.
То, о чём я пишу, но ещё не дописал и что, соответственно, в этом блоге будет:
  1. "Дополняем "include в JavaScript`е"". Переработанная статья Володи Колесникова "Инклюд в яваскрипте" на "Техногрете" - сайте для web-разработчиков от студии Артемия Лебедева.
  2. "Хитрость с finally-блоком" - отличный приём кодинга на JS, который, в частности, позволит немного упростить "Базовую модель" приведённую в статьях цикла "Особенности инкапсуляции на основе замыканий".
  3. "Cookies API" - удобный API для работы с Cookies.
  4. "URL advanced parsing" - переработанный в соответстви с серией статей "JavaScript: Особенности инкапсуляции на основе замыканий" вариант реализации парсинга, предложенный Kottenator`ом в статье "Парсим URL")
  5. "Targeter pattern" - придуманный мной приём для динамического создания и подцепки статических блоков контента на странице. Я не раз использовал его в своих проектах и нахожу весьма ценным.
  6. "SPKet IDE - советы". Переработанный вариант статьи и видео-лекции С.Чикуенка "Eclipse: редактирование JavaScript в Spket IDE"
  7. "JSDoc - советы". Дополнения и критика статьи А.Старшинова - "Документирование JS-кода"
  8. "Rhino и scripting API в Java SE 6 - способы применения в Java-программах (на примере JSDoc Toolkit)"
  9. "Универсализированная Обработка событий" - рабор того, что можно сделать с несовместимостью браузеров в области продвинутых моделей обработки событий.
  10. "Универсализированный метод создания DOM-узлов". Представлю свои библиотеки для создания узлов DOM-дерева. Хочу сосредоточиться на нахождении компромиса между максимальной производительностью и удобством работы с API.
  11. "Работа с замыканиями". Распишу, что представляют собой замыкания и как правильно их использовать.
  12. "Примитивы и объекты в JavaScript". Вопреки распространённому мнению, примитивы в JS есть, но они присутствуют в этом языке неявно и преобразуются на лету при попытке обратиться к ним как к объектам. Это может создать путанницу и привести к задержкам в работе кода (что явно и происходит, по моим наблюдениям, в коде у многих). В статье постараюсь подробно изложить отличия одних от других и показать верный путь для тюнинга JS-скриптов в этом отношении.
  13. "Работа с XPath на JavaScript". Описание стандартного механизма поддержки XPath в браузерах и наилучшей с моей т.з.библиотеки, которая заменяет его в браузерах, не поддерживающих данный стандарт.
  14. "Работа с XSLT на JavaScript". Описание работы с библиотекой AJAXSLT от Google.
  15. "Технологии XUL и HTA/HTC". Описание работы с данными технологиями, позволяющими создавать полноценные приложения при помощи Web-технологий.
  16. "ServerSide JavaScript". Когда-то давным-давно, впечатлившись успехом JavaScript, фирма Netscape создала и серверный вариант этого языка, но он по ряду причин не получил должного распространения, упустив рынок приложений на стороне сервера таким языкам, как Perl и PHP. Сейчас, на основе Rhino и Scripting API Java 6 можно использовать Java-сервера для программирования серверной логики на JS. В статье я постараюсь продемонстрировать, как это можно реализовать.
  17. "Технология компонентов". Дальнейшее развитие идеи паттерна Targeter, к которому добавляется аналогичный GUI-библиотекам Java (Swing) механизм обработки событий.