Xpoint
   [напомнить пароль]

"Сброс" записи xul-кэша для конкретного оверлея

Метки: [без меток]
2008-03-04 18:51:22 [обр] Cube(2/2)[досье]

Существует ли возможность "обнулить" запись xul-кэша для единственного оверлея ? То есть, если оверлей был изменён кодом расширения, соответствующие изменения отображались бы во вновь открываемых окнах.

Пока что в своих поисках отыскал

var os = Components. classes ["@mozilla.org/observer-service;1"]. getService (Components. interfaces. nsIObserverService);
os. notifyObservers (null, "chrome-flush-caches", null);

который сбрасывает весь xul кэш; однако, я думаю, сброс всего кэша целиком не лучшим образом скажется на производительности, кроме того, неизвестно какими сторонними эффектами это грозит для уже открытого окна.

Пробовал экспериментировать с nsICacheSession. Непонятно, какую сессию необходимо открывать с помощью createSession (и есть ли такая вообще). Я пробовал "xul", "chrome", "overlay" - безрезультатно.

С nsIFastLoadService небольшой "прогресс": метод hasMuxedDocument даёт true для нужного оверлея, но как сервисом можно воспользоваться для выполнения задачи - непонятно.

спустя 16 часов [обр] Владимир Палант(434/4445)[досье]

Не выйдет — эта функциональность реализуется в nsXULPrototypeCache, и никакой возможности выборочно удалить элемент из кеша не предусмотренно. nsICacheSession же совсем другой кеш.

А что вы такое делаете, что вам нужно динамически менять оверлеи?

спустя 6 часов [обр] Cube(2/2)[досье]
Не выйдет — эта функциональность реализуется в nsXULPrototypeCache, и никакой возможности выборочно удалить элемент из кеша не предусмотренно.

nsXULPrototypeCache как-то работает с nsIFastLoadService, но последний скудно описан на xulplanet (а в исходных текстах браузера я хоть и посмотрел, но не силён и не разобрался ) - кстати, оттуда и "chrome-flush-caches") и не понятно, можно ли с его помощью осуществить требуемую операцию, или он работает только "в одну сторону".

nsICacheSession же совсем другой кеш.

Спасибо за сведения. Предполагал нечто подобное, но не был уверен окончательно.

Может быть, есть смысл поэкспериментировать с загрузкой оверлея по другому (не chrome://) протоколу ?

А что вы такое делаете, что вам нужно динамически менять оверлеи?

Занимаюсь разработкой оригинальной ветки Custombuttons. Мне не нужно динамически менять оверлеи, но нужно, чтобы изменения в одном оверлее учитывались при открытии новых окон. Прежде чем заняться реализацией "ручной" синхронизации UI ищу методы попроще.

спустя 14 минут [обр] Владимир Палант(434/4445)[досье]

Хорошее "попроще" :)
Все-таки лучше не извращайтесь, а добавляйте кнопки через JavaScript — заодно и сможете обновлять уже открытые окна.

nsIFastLoadService тут ни при чем, nsXULPrototypeCache лишь уведомляет его о помещении файла в кеш.

Но если так уж хочется поизвращаться — можете добавлять ваш оверлей с помощью document.loadOverlay и использовать при этом URL file///..., на него кеш распространяться не должен.

спустя 29 минут [обр] Cube(2/2)[досье]
Хорошее "попроще" :)

Если есть известный легальный способ, то действительно, проще. Тогда не надо учитывать положение элементов, наличие и состояние настройки nglayout.degug.disable_xul_cache, и движок сделает обновление быстрее чем javascript.

...можете добавлять ваш оверлей с помощью document.loadOverlay...

Такая возможность рассматривалась примерно годом ранее. К сожалению, loadOverlay в данном случае не работает, так как xbl панелей инструментов удаляет toolbarpalette из документа. Можно сделать собственный xbl, расширяющий стандартный для toolbarpanel, но в этом случае есть вероятность конфликтов с другими расширениями, которые пожелают ставить собственный binding на toolbarpalette.

...и использовать при этом URL file///..., на него кеш распространяться не должен.

Я имел в виду декларацию в chrome.manifest, что-то вроде

overlay chrome://browser/content/browser.xul another_protocol://overlay.xul
спустя 20 часов [обр] Cube(2/2)[досье]

Кажется, мне удалось "обмануть" кэш. Я решил поставить эксперимент с

overlay chrome://browser/content/browser.xul custombutton://buttonsoverlay.xul

Спросил у google nsIProtocolHandler и почти сразу нашёл готовую реализацию: http://kb.mozillazine.org/Dev_:_Extending_the_Chrome_Protocol
Попробовал - получилось.

Поделитесь соображениями по поводу использования этой возможности - нет ли на этой дороге каких-нибудь "граблей" ?

Powered by POEM™ Engine Copyright © 2002-2005