Przygotowanie środowiska programowania rozszerzenia

 

W tym artykule przedstawiono propozycje skonfigurowania aplikacji Mozilla w celu dostosowania jej do potrzeb programowania rozszerzeń.

Preferencje programistyczne

Ustawienie wymienionych niżej preferencji ułatwi debugowanie kodu (jednak wiązać się z tym będzie spadek wydajności).

Informacje na temat ustawiania preferencji można znaleźć w artykule Editing Configuration Files (Edytowanie plików konfiguracyjnych). Uwaga: niektórych z omawianych preferencji domyślnie nie ma liście <tt>about:config</tt> — w takim przypadku należy utworzyć nowe wpisy (typu „wartość logiczna”).

Przed dokonaniem tych zmian należy zapoznać się z instrukcją tworzenia osobnego profilu do celów testowych, przedstawioną w sekcji Profil testowy.

  • javascript.options.showInConsole = true. Włącza rejestrowanie błędów występujących w plikach chrome w Konsoli błędów.
  • nglayout.debug.disable_xul_cache = true. Wyłącza pamięć podręczną XUL, w wyniku czego modyfikacje okien i okien dialogowych nie wymagają ponownego uruchomienia przeglądarki. Warunkiem działania tego ustawienia jest Używanie katalogów zamiast archiwów JAR. Zmiany w nakładkach XUL nadal wymagają ponownego załadowania dokumentu, do którego stosowana jest nakładka.
  • browser.dom.window.dump.enabled = true. Włącza możliwość stosowania wyrażenia dump() do wyświetlania tekstu w standardowej konsoli. Więcej informacji można znaleźć w artykule window.dump. W skrypcie uprzywilejowanym można także skorzystać z interfejsu nsIConsoleService.
  • javascript.options.strict = true. Włącza restrykcyjne ostrzeżenia JavaScript w Konsoli błędów. Jako że wielu programistów nie włącza tego ustawienia, obok ostrzeżeń dotyczących tworzonego rozszerzenia wyświetlana może być duża liczba innych ostrzeżeń dotyczących problemów związanych z kodem tworzonym przez te osoby. Takie komunikaty można odfiltrować, korzystając z rozszerzenia Console2.

Rozszerzenia wspomagające programowanie

Poniższe rozszerzenia mogą być przydatne podczas programowania.

Profil testowy

Aby uniknąć spadku wydajności związanego z ustawieniem preferencji dotyczących programowania i zainstalowaniem dodatkowych rozszerzeń, a także w celu zabezpieczenia się przed utratą własnych danych, można utworzyć osobny profil przeznaczony do testów pisanego oprogramowania.

Przypisanie wartości 1 do zmiennej środowiskowej MOZ_NO_REMOTE pozwala na uruchomienie dwóch kopii programu Firefox, każdej z osobnym profilem. W systemie Windows można na przykład skorzystać z poniższego pliku wsadowego w celu uruchomienia Firefoksa z profilem testowym, niezależnie od tego, czy „zwykły” Firefox jest już uruchomiony. (Przyjęto założenie, że profil testowy nosi nazwę „dev”):

set MOZ_NO_REMOTE=1
start "" "%ProgramFiles%\Mozilla Firefox\firefox.exe" -P dev

Aby uruchomić program Firefox z domyślnym profilem wystarczy po prostu jak zwykle użyć poleceń "firefox" lub "firefox -P default".

Lokalizacja tworzonego kodu

Aby uniknąć ciągłego ponownego instalowania tworzonego rozszerzenia za każdym razem, gdy dokonane zostaną jakieś zmiany, a także w celu ochrony plików źródłowych przed przypadkowym usunięciem przy odinstalowywaniu rozszerzenia, kod źródłowy można umieścić poza profilem w wybranej przez siebie lokalizacji.

  1. Znajdź identyfikator rozszerzenia w zawartym w nim pliku install.rdf
  2. W katalogu katalog_profilu/extensions/ utwórz plik o nazwie takiej, jak powyższy identyfikator (np. `katalog_profilu/extensions/{46D1B3C0-DB7A-4b1a-863A-6EE6F77ECB58}`) (Znajdź katalog profilu)
  3. Plik ten powinien zawierać ścieżkę do folderu zawierającego plik install.rdf tworzonego rozszerzenia. (np. `/pełna/ścieżka/do/mojegoRozszerzenia`)
  4. Zapisz plik w folderze extensions używanego profilu i uruchom ponownie aplikację.

Używanie katalogów zamiast archiwów JAR

Niezależnie od tego, czy pliki chrome rozszerzenia będą docelowo przechowywane w archiwach JAR, czy w katalogach, podczas programowania zalecana jest ta druga technika ze względu na związane z nią ułatwienia. Jeżeli w finalnej wersji mają być zastosowane archiwa JAR, w czasie programowania można korzystać ze struktury katalogów, edytując plik chrome.manifest. Na przykład zamiast poleceń

content	myExtension	jar:chrome/myExtension.jar!/content/

należy użyć

content	myExtension	chrome/content/

 

 

 

 

 

 

 

Autorzy i etykiety dokumentu

 Autorzy tej strony: teoli, Mgjbot, Flaneur
 Ostatnia aktualizacja: teoli,