Такой функционал можно реализовать используя связку юзерскрипт/расширение + сервер.
В более общем случае можно собирать куда более интересную статистику.
Но это будет «слежка» за пользователем, установившим данное расширение :)
Это хорошо, когда у вас есть свой сервер, на котором можно поднять прокси.
Но тут есть жирный минус — безопасность. Передача данных на сторонний сервер — это бяка. Для пользователя это один из самых первых признаков того, что его хотят наебмануть.
Ещё один минус — дополнительная зависимость.
Скрипты в Хроме и Гризманки имеют свои чёткие механизмы запросов. Основная проблема — это IE и Opera.
Для Оперы решения с доп. файлом практически всегда достаточно. К тому же, дополнительный файл — это по сути «движок» для кроссдоменных запросов, который можно использовать из любых других юзерскриптов в Опере.
У меня не возникало проблем с тем, чтобы объяснить клиентам необходимость подкладывания дополнительного файла. По большей части потому, что плагины/расширения для запуска скриптов нужны для большинства браузеров и доп. скрипт воспринимается как очередной «плагин для Оперы».
Это вообще начало и конец кода jQuery из файла jquery.min.js.
Эту строчку можно удалить полностью (а можно вообще не трогать, это комментарий), и заменить её кодом вашей библиотеки. Код нужно непосредственно копировать в тело юзерскрипта.
Я подключаю библиотеки только непосредственной инъекцией библиотеки в код скрипта, т.е. простым копированием ужатой версии библиотеки в код юзерскрипта. Посмотрите в шаблон в первой статье, там есть закомментированное место для вставки кода библиотек.
А если учитывать:
* возможность редактировать скрипты «на лету»
* версионный контроль ресурсов (возможность откатывать изменения в CSS до нужной версии)
* возможность дебажить юзерскрипты и расширения,
то я бы сказал, что Developer Tools переплюнул Firebug.
Единственный функционал, которого мне не хватает в DT, это поиск по множественным файлам.
С кроссдоменными запросами беда только в IE. Без доступа к серверу их реализовать не получится (только JSONP или easyXDM. Можно использовать сторонние сервисы-прокси).
Для начала избавьтесь от GM API в любом виде. GM_get/setValue заменяется на localStorage. С кроссдоменными запросами будет сложнее, придётся оборачивать в экстеншн (юзерскрипт выступает в роли контент-скрипта и к нему применим стандартный chrome.extension.onRequest мост).
С Xpath тоже не всё в порядке, могут возникнуть проблемы.
В крайнем случае, выложите скрипт на pastebin.com.
И не стесняйтесь стучаться в скайп по вечерам :)
Хм, действительно странная последовательность действий.
У меня процесс происходит так:
1. Если разрабатывается «голый» юзерскрипт:
а) Модифицируем скрипт.
б) Закидываем в браузер.
в) Соглашаемся на установку.
г) Рефрешаем страницу.
После рефреша работает новый скрипт. Если у вас не работает, попробуйте НЕ МЕНЯТЬ @version и @namespace.
Если всё равно скрипт не обновляется, то читайте дальше.
2. Если разрабатывается расширение, 1ый способ:
а) Модифицируем скрипт.
б) Пакуем скрипт в расширение (используя имеющийся файл-ключ).
в) Закидываем расширение в браузер.
г) Соглашаемся установить.
д) Заходим в Расширения и выключаем-включаем расширение.
е) Рефрешаем страницу
3. Если разрабатывается расширение, 2ой способ:
а) Модифицируем скрипт.
б) Ищем папку, в которую распаковано расширение.
в) Заменяем скрипт.
г) Заходим в Расширения и выключаем-включаем расширение.
д) Рефрешаем страницу
Как видите, ключевым моментом является выключение-включение расширения. При включении хром загружает расширение в память заново.
Обратите внимание, если файл-ключ будет разный, то две одинаковых версии расширения (одинаковые метаданные) будут считаться разными.
Если вы читали первую статью, то могли заметить, что директивы @require нету в таблице распространенных директив. Я специально не указывал там директивы, которые не поддерживаются кроссбраузерно.
@require поддерживается только в Firefox.
Я считаю, что любые «плюшки», которые отсутствуют в других браузерах, упоминать не стоит.Подробная информация о разработке под GreaseMonkey может занять не одну статью.
Если какой-то функционал GM API можно «эмулировать» кроссбраузерно (и я знаю такой способ), я напишу об этом в соответствующей статье.
Кстати, любую библиотеку можно инжектировать в скрипт. Я предпочитаю как раз такой способ. О его преимуществах и недостатках я напишу отдельно (на примере jQuery).
Я считаю, что на скриптах лучше учиться программисту, у которого скрипты связаны с работой.
А на юзерскриптах лучше учиться «продвинутым» пользователям и начинающим программистам. Потому что в большинстве случаев юзерскрипты пишутся под себя и результат виден и юзабелен. А ощутимый результат — очень хороший мотиватор.
Если бы я включил в статью детальную информацию о браузерах — получилось бы большое полотно.
Поэтому я решил разделить статью на две части: самые основы написания юзерскриптов и более подробный побраузерный разбор.
2. Контент скрипты связываем с background посредством механизма посылки сообщений
3. Для адаптации под другие браузеры могу порекомендовать использовать kango framework
В более общем случае можно собирать куда более интересную статистику.
Но это будет «слежка» за пользователем, установившим данное расширение :)
Большой плюс такого решения — исходники вы сможете посмотреть и поправить в случае чего.
Но тут есть жирный минус — безопасность. Передача данных на сторонний сервер — это бяка. Для пользователя это один из самых первых признаков того, что его хотят наебмануть.
Ещё один минус — дополнительная зависимость.
Скрипты в Хроме и Гризманки имеют свои чёткие механизмы запросов. Основная проблема — это IE и Opera.
Для Оперы решения с доп. файлом практически всегда достаточно. К тому же, дополнительный файл — это по сути «движок» для кроссдоменных запросов, который можно использовать из любых других юзерскриптов в Опере.
У меня не возникало проблем с тем, чтобы объяснить клиентам необходимость подкладывания дополнительного файла. По большей части потому, что плагины/расширения для запуска скриптов нужны для большинства браузеров и доп. скрипт воспринимается как очередной «плагин для Оперы».
Эту строчку можно удалить полностью (а можно вообще не трогать, это комментарий), и заменить её кодом вашей библиотеки. Код нужно непосредственно копировать в тело юзерскрипта.
Если есть вопросы — постучитесь в скайп.
* возможность редактировать скрипты «на лету»
* версионный контроль ресурсов (возможность откатывать изменения в CSS до нужной версии)
* возможность дебажить юзерскрипты и расширения,
то я бы сказал, что Developer Tools переплюнул Firebug.
Единственный функционал, которого мне не хватает в DT, это поиск по множественным файлам.
Фреймы действительно недоступны и, действительно, всё решается через проксирование.
Мои знания юзерскриптов для Оперы ограничены началом 2010 года.
Что-то мне подсказывает, что зря не пользовался.
С Xpath тоже не всё в порядке, могут возникнуть проблемы.
В крайнем случае, выложите скрипт на pastebin.com.
И не стесняйтесь стучаться в скайп по вечерам :)
В IE, в обоих плагинах юзерскрипты запускаются по window.onLoad.
Вероятно, в Ninjakit аналогично.
Добавил информацию в статью.
У меня процесс происходит так:
1. Если разрабатывается «голый» юзерскрипт:
а) Модифицируем скрипт.
б) Закидываем в браузер.
в) Соглашаемся на установку.
г) Рефрешаем страницу.
После рефреша работает новый скрипт. Если у вас не работает, попробуйте НЕ МЕНЯТЬ @version и @namespace.
Если всё равно скрипт не обновляется, то читайте дальше.
2. Если разрабатывается расширение, 1ый способ:
а) Модифицируем скрипт.
б) Пакуем скрипт в расширение (используя имеющийся файл-ключ).
в) Закидываем расширение в браузер.
г) Соглашаемся установить.
д) Заходим в Расширения и выключаем-включаем расширение.
е) Рефрешаем страницу
3. Если разрабатывается расширение, 2ой способ:
а) Модифицируем скрипт.
б) Ищем папку, в которую распаковано расширение.
в) Заменяем скрипт.
г) Заходим в Расширения и выключаем-включаем расширение.
д) Рефрешаем страницу
Как видите, ключевым моментом является выключение-включение расширения. При включении хром загружает расширение в память заново.
Обратите внимание, если файл-ключ будет разный, то две одинаковых версии расширения (одинаковые метаданные) будут считаться разными.
Если вы читали первую статью, то могли заметить, что директивы @require нету в таблице распространенных директив. Я специально не указывал там директивы, которые не поддерживаются кроссбраузерно.
@require поддерживается только в Firefox.
Я считаю, что любые «плюшки», которые отсутствуют в других браузерах, упоминать не стоит.Подробная информация о разработке под GreaseMonkey может занять не одну статью.
Если какой-то функционал GM API можно «эмулировать» кроссбраузерно (и я знаю такой способ), я напишу об этом в соответствующей статье.
Кстати, любую библиотеку можно инжектировать в скрипт. Я предпочитаю как раз такой способ. О его преимуществах и недостатках я напишу отдельно (на примере jQuery).
Оставайтесь с нами :)
Я считаю, что на скриптах лучше учиться программисту, у которого скрипты связаны с работой.
А на юзерскриптах лучше учиться «продвинутым» пользователям и начинающим программистам. Потому что в большинстве случаев юзерскрипты пишутся под себя и результат виден и юзабелен. А ощутимый результат — очень хороший мотиватор.
Если бы я включил в статью детальную информацию о браузерах — получилось бы большое полотно.
Поэтому я решил разделить статью на две части: самые основы написания юзерскриптов и более подробный побраузерный разбор.
Ждите, вторая статья на подходе :)