Implementacja rozszerzenia do przeglądarki

Implementacja rozszerzenia do przeglądarki

Rok akademicki 2012/2013
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA INśYNIERSKA
Jakub Janczyk
Implementacja rozszerzenia do przeglądarki
internetowej na potrzeby cyfrowego repozytorium
dokumentów
Opiekun pracy
dr inŜ. Łukasz Skonieczny
Ocena: .....................................................
................................................................
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
Kierunek:
Informatyka
Specjalność:
InŜynieria Systemów Informatycznych
Data urodzenia:
1990.10.10
Data rozpoczęcia studiów:
2009.10.01
śyciorys
Urodziłem się 10 października 1990 roku w Kielcach. W 2009 roku ukończyłem
II Liceum Ogólnokształcące im. Jana Śniadeckiego w Kielcach, gdzie uczęszczałem do
klasy z rozszerzonymi matematyką, fizyką oraz informatyką. W tym samym roku otrzymałem świadectwo dojrzałości i w październiku rozpocząłem studia na Wydziale Elektroniki i
Technik Informacyjnych Politechniki Warszawskiej. Od trzeciego roku studiów moją specjalnością jest InŜynieria Systemów Informatycznych.
............................................................
Podpis studenta
EGZAMIN DYPLOMOWY
ZłoŜył egzamin dyplomowy w dniu ............................................................................. 2013 r
z wynikiem ..............................................................................................................................
Ogólny wynik studiów: ..........................................................................................................
Dodatkowe wnioski i uwagi Komisji: ....................................................................................
.................................................................................................................................................
.................................................................................................................................................
2
STRESZCZENIE
Praca zawiera opis dodatku do przeglądarki Mozilla Firefox, które rozszerza funkcjonalność cyfrowego repozytorium dokumentów Wydziału Elektroniki i Technik Informacyjnych. Opis ten dotyczy zarówno projektu rozszerzenia, jak i jego implementacji.
Pierwsza część pracy zawiera przedstawienie sposobu tworzenia rozszerzeń do przeglądarki Firefox, z wyszczególnieniem najwaŜniejszych technologii uŜywanych w tym celu. W
dalszej części zaprezentowane zostały wymagania postawione tworzonemu rozszerzeniu
oraz ich analiza. NajwaŜniejszym z wymagań jest udostępnienie uŜytkownikom moŜliwości pobierania liczby cytowań publikacji, znajdujących się w repozytorium. W tej części
zostały takŜe opisane napotkane problemy, wraz ze sposobami ich rozwiązania. Praca kończy się opisem najwaŜniejszych elementów zaimplementowanego rozszerzenia oraz metod
jego testowania.
Słowa kluczowe: Mozilla Firefox, rozszerzenie, XUL, XPCOM, Google Scholar
ABSTRACT
Title: Implementation of a web browser extension for a digital documents repository
Thesis describes Mozilla Firefox browser add-on, which extends the functionality of
the digital documents repository of the Faculty of Electronics and Information Technology.
Description applies to both project and implementation of extension. The paper begins
with a description of how to create extensions for Firefox, detailing the most important
technologies using for this purpose. The next section contains given requirements of extension and their analysis. The most important requirement is to give users the possibility of
retrieving citations count of every paper stored in the repository. This section also presents
encountered problems, alongside with their solutions. Paper ends with the description of
the most important elements of implemented extension and its testing methods.
Keywords: Mozilla Firefox, extension, XUL, XPCOM, Google Scholar
3
Spis treści
1
2
Wstęp ................................................................................................................... 6
1.1
Cel pracy .................................................................................................... 7
1.2
Układ pracy................................................................................................ 7
Tworzenie rozszerzeń .......................................................................................... 9
2.1
Czym jest rozszerzenie? ............................................................................ 9
2.2
Elementy rozszerzenia ............................................................................. 10
2.2.1 Manifest instalacji .................................................................................. 10
2.2.2 Chrom ..................................................................................................... 11
2.3
Wykorzystywane technologie .................................................................. 13
2.3.1 XUL ........................................................................................................ 14
2.3.2 XPCOM .................................................................................................. 17
3
2.4
Typy rozszerzeń ....................................................................................... 18
2.5
Zotero ....................................................................................................... 19
Projekt rozszerzenia .......................................................................................... 20
3.1
Wymagania .............................................................................................. 20
3.2
Współpraca z repozytorium oraz interfejs uŜytkownika ......................... 21
3.3
Źródło liczby cytowań ............................................................................. 22
3.4
Metody pobierania liczby cytowań .......................................................... 25
3.4.1 Analiza strony źródłowej Google Scholar.............................................. 25
3.4.2 Wysyłanie Ŝądań HTTP w języku JavaScript ........................................ 28
3.4.3 Pobieranie danych pojedynczej publikacji ............................................. 29
3.4.4 Pobranie liczby cytowań wielu publikacji.............................................. 31
3.4.5 Ograniczenia wprowadzane przez Google Scholar ................................ 32
3.5
4
Baza danych ............................................................................................. 33
Opis implementacji............................................................................................ 36
4
4.1
Wprowadzone elementy interfejsu uŜytkownika..................................... 37
4.1.1 Modyfikacja interfejsu przeglądarki ...................................................... 37
4.1.2 Modyfikacja strony repozytorium .......................................................... 39
4.1.3 Okno z listą prac cytujących .................................................................. 40
4.2
Wykrycie repozytorium ........................................................................... 42
4.3
Pobieranie danych .................................................................................... 46
4.3.1 Obsługa błędów pobierania .................................................................... 47
4.4
Obsługa języków ..................................................................................... 48
4.5
Testy ........................................................................................................ 50
4.5.1 Scenariusze testowania ........................................................................... 50
4.5.2 Testy wydajnościowe ............................................................................. 53
5
Podsumowanie................................................................................................... 54
6
Bibliografia ........................................................................................................ 56
5
1 Wstęp
Autorzy naukowi często przytaczają w swoich pracach dzieła poprzedników, korzystając z wyników przeprowadzonych tam badań, czy negując lub udoskonalając postawione teorie. Powoływanie się na inne publikacje i zapoŜyczanie cudzych myśli bez dosłownego przytaczania, jednak ze wskazaniem dokładnego źródła, nazywane jest cytowaniem.
Początkowo cytowania słuŜyły do tego, aby m.in. uniknąć bycia oskarŜonym o plagiat czy
docenić pracę innego autora. Z czasem zaczęto rozwaŜać moŜliwości ich praktycznego
wykorzystania. Okazało się, Ŝe liczba cytowań moŜe być uŜyta, jako ocena jakości i wpływu prac naukowych [1]. Aby móc to osiągnąć, Eugene Garfield, w 1960 roku, stworzył
pierwszą współczesną bazę danych, która zawierała powiązania między publikacjami. Pozwalała ona na łatwe ustalenie, które z później napisanych prac, cytowały te wcześniejsze.
Baza tego typu jest nazywana powszechnie indeksem cytowań.
Analizą cytowań nazywane są badania częstotliwości i wzorców cytowań pojawiających się w ksiąŜkach czy artykułach. Pozwoliły one na zdefiniowanie kilku zastosowań dla
liczby cytowań:
•
Ocena pojedynczej publikacji – na podstawie sumy jej cytowań.
•
Ocena dorobku naukowego autora – na podstawie sumy cytowań lub ich
średniej liczby, uwzględniając kaŜdą pracę opublikowaną przez autora.
•
Ocena czasopisma – na podstawie średniej liczby cytowań, uwzględniając
kaŜdą pracę opublikowaną w danym czasopiśmie.
Poza przedstawionymi, prostymi sposobami wykorzystania liczby cytowań, w ostatnich latach zaproponowane zostało wiele metod, pozwalających lepiej zmierzyć dorobek i
wpływ pojedynczego autora. W 2005, Jorge E. Hirsch zaprezentował współczynnik, nazwany h-index, który moŜe zostać do tego uŜyty [2]. Korzystając z niego, autor ma współczynnik równy h, jeśli opublikował h prac, z których kaŜda była cytowana przynajmniej h
razy. Oprócz mierzenia dotychczasowego dorobku, twórca współczynnika przedstawił w
pracy [3], Ŝe moŜe on zostać takŜe wykorzystany do przewidywania przyszłych osiągnięć
autorów. Pomimo, Ŝe h-index jest powszechnie stosowany, nie jest wolny od wad i moŜe
dostarczać błędne informacje (jednak większość z wad nie odnosi się wyłącznie do tego
współczynnika). Wśród najczęstszych argumentów, wskazywanych przez krytyków, jest
to, Ŝe nie uwzględniany jest kontekst cytowania [4], a takŜe moŜe on być łatwo zmanipulowany przez auto-cytowania [5].
6
H-index nie jest jedynym tego typu współczynnikiem. Innym, często wykorzystywanym, jest zaproponowany w 2006 roku, przez Leo Egghe’a, współczynnik, który został
nazwany g-index [6]. Współczynnik ten wynosi g, w przypadku, gdy g najwięcej cytowanych publikacji autora, posiada łącznie przynajmniej g2 cytowań.
Często oceny całkowitych dorobków autorów uŜywane są na uczelniach, w stosunku
do zatrudnionych w nich pracowników naukowych. TakŜe sami pracownicy mogą być
zainteresowani łatwym znalezieniem liczby cytowań swoich publikacji. W związku z powyŜszym, konieczne jest zebranie wszystkich opublikowanych przez nich prac. Taką rolę,
w przypadku Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej,
spełnia stworzone na nim cyfrowe repozytorium dokumentów. Opracowane zostało w Instytucie Informatyki, pod kierunkiem prof. Henryka Rybińskiego, i wykorzystywane jest
do gromadzenia opisów podstawowych efektów działalności naukowo-badawczej pracowników Wydziału. Są to m.in. publikacje, prace dyplomowe, artykuły, raporty, itp.
1.1 Cel pracy
Przedstawione repozytorium nie posiada niestety w swojej bazie danych informacji,
dotyczących liczby cytowań poszczególnych publikacji. Przez to nie moŜe być ono
postrzegane jako kompletne. Głównym celem tej pracy jest stworzenie aplikacji, która
zwiększy
funkcjonalność
repozytorium.
Jego
zadaniem
będzie
umoŜliwienie
uŜytkownikom (przede wszystkim pracownikom naukowym Wydziału) pobrania, w łatwy
sposób, liczby cytowań dla interesujących ich prac, znajdujących się w repozytorium.
Narzędziem, najlepiej nadającym się do tego zadania, są rozszerzenia do przeglądarek
internetowych. W dzisiejszych czasach, wśród najpopularniejszych przeglądarek są, przede
wszystkim, Mozilla Firefox oraz Google Chrome, a jako docelowa platforma
wykorzystana zostanie pierwsza z wymienionych (chociaŜ nie moŜna odrzucić takŜe
implementacji rozszerzenia na drugą z nich). W związku z tym, pośrednim celem tej pracy,
wymaganym do zrealizowania głównego, jest zapoznanie się z przeglądarką Firefox oraz z
zasadami i moŜliwościami tworzenia jej rozszerzeń.
1.2 Układ pracy
Praca ta została podzielona na trzy części. Pierwsza z nich (rozdział 2) zawiera teorię
dotyczącą tworzenia rozszerzeń. Przedstawione zostały ich podstawowe elementy, takie
jak manifest instalacji czy pakiet chrom, a takŜe moŜna dowiedzieć się w jaki sposób prze7
glądarka obsługuje dostarczone pliki, składające się na rozszerzenie. Oprócz tego, opisane
zostały podstawowe technologie, wykorzystywane w celu ich stworzenia. Jedną z nich jest
XUL (czyt. „zul”), która jest przeznaczona do definiowania interfejsu uŜytkownika.
Druga część pracy (rozdział 3) zawiera projekt rozszerzenia, w tym, przedstawione
zostały jego wymagania oraz ich analiza. Zaprezentowane tu zostały równieŜ sposoby
pobierania wymaganych danych. Dokonano wyboru źródła, z którego będą one
uzyskiwane, a takŜe jak będą przechowywane w bazie danych repozytorium. Opisane są
takŜe wszelkie problemy, jakie napotkano podczas projektowania, wraz z ich
proponowanymi rozwiązaniami.
Trzecia, i ostatnia, część pracy (rozdział 4) zawiera opis zarówno najwaŜniejszych
elementów zaimplementowanego rozszerzenia, oraz takich, które sprawiły najwięcej problemów. Opisana została struktura dodatku, przy czym wyszczególniony został jego podział na moduły, wraz z wykonywanymi przez nie funkcjami. Oprócz tego, przedstawione
zostały elementy interfejsu uŜytkownika, które dodaje rozszerzenie. Część ta kończy się
opisem
scenariuszy
testowania
oraz
wykonanych
testów
wydajnościowych.
Praca była finansowana przez Narodowe Centrum Badań i Rozwoju w ramach
Programu Strategicznego "Interdyscyplinarny system interaktywnej informacji
naukowej i naukowo technicznej", Umowa SP/I/1/77065/10.
8
2 Tworzenie rozszerzeń
2.1 Czym jest rozszerzenie?
Twórcy przeglądarki Mozilla Firefox zaprojektowali ją w taki sposób, aby moŜliwe
było łatwe, i w bardzo szerokim zakresie, dostosowanie jej do potrzeb uŜytkownika. Dostosowanie to jest moŜliwe za pomocą tzw. dodatków. Za oficjalną stroną Mozilli [7]:
„Dodatki to niewielkie programy tworzone przez ludzi z całego świata, dzięki którym
moŜna Firefoksa wzbogacić o nowe moŜliwości i funkcje, dodając nowe wyszukiwarki,
słowniki lub zmienić jego wygląd.[…] Ogólnie ujmując, za pomocą dodatków moŜna dostosować Firefoksa do swoich potrzeb i gustów.”
Dodatki moŜna podzielić na trzy główne kategorie, którymi są: wtyczki, rozszerzenia
oraz motywy graficzne. Ostatni z nich, czyli motyw jest najmniej skomplikowany, jego
jedynym celem jest zmiana wyglądu przeglądarki. Dwa pozostałe spełniają więcej zadań.
Czasami jednak bywa, Ŝe rozszerzenia nazywane są wtyczkami, oraz na odwrót, lub nazwy
te są uŜywane zamiennie. Nie jest to poprawne ich postrzeganie, bowiem formalnie dodatki te róŜnią się od siebie znacząco, zarówno pod względem przeznaczenia, jak i sposobu
ich tworzenia.
Wtyczki to dynamiczne biblioteki, napisane w języku C++, które umoŜliwiają przeglądarce współpracę z programami zewnętrznymi, lub na wyświetlanie treści nie obsługiwanych przez nią domyślnie. Są nimi zazwyczaj zamieszczone na stronach WWW róŜnego
rodzaju filmy, gry, animacje czy dokumenty PDF. Wtyczki są przewaŜnie tworzone przez
zewnętrzne firmy, które posiadają prawa patentowe do formatów określonych treści [7].
Przykładem najpopularniejszej wtyczki jest Flash, słuŜąca do wyświetlania m.in. filmów i
stworzona przez Adobe Systems.
Wtyczki są powiązane z elementami zamieszczonymi na stronach WWW i tylko na
nich uruchamiane. Inaczej jest w przypadku rozszerzeń, które jedyne czego wymagają, to
sama przeglądarka. Głównym ich zadaniem jest dodanie do niej nowych funkcji lub modyfikację tych istniejących. Mają one zazwyczaj niewielkie rozmiary i dzięki nim przeglądarka moŜe zostać dowolnie dostosowana do potrzeb uŜytkownika, bez konieczności obciąŜania czystej aplikacji zestawem funkcjonalności, których część uŜytkowników nie potrzebuje. Stworzenie prostego rozszerzenia nie jest zadaniem skomplikowanym, czy wy9
magającym bardzo specjalistycznej wiedzy, dlatego większość z nich została napisana
przez zwykłych uŜytkowników, którym czegoś brakowało w przeglądarce. W lipcu 2012
roku istniało 150 tys. rozszerzeń stworzonych przez uŜytkowników, które były do tego
momentu pobrane ponad 3 miliardy razy.
2.2 Elementy rozszerzenia
Rozszerzenie jest zbiorem plików, które zostały skompresowane do archiwum z rozszerzeniem XPI. XPI (wym. „zippy”) to skrót od Cross-Platform Installer (Międzyplatformowy instalator), a pliki tego typu są zwykłymi archiwami ZIP ze zmienionym rozszerzeniem, które przeglądarka potrafi rozpoznać i rozpocząć instalację. Wśród wspominanego zbioru plików, składających się na rozszerzenie, znajduje się kilka plików konfiguracyjnych. Ich obecność jest wymagana, aby rozszerzenie mogło zostać zainstalowane i poprawnie działało. Muszą one zostać takŜe ułoŜone w określoną strukturę, której przykład
został zaprezentowany poniŜej.
Nazwa_rozszerzenia.xpi
|------ install.rdf
|------ chrome.manifest
|------ chrome
|-----content
|
|-----skrypt.js
|
|-----interfejs.xul
|-----locale
|
|-----pl-PL
|
|-----pakiet_językowy.dtd
|-----skin
|-----skórka.css
Pliki install.rdf oraz chrome.manifest są wspomnianymi wcześniej plikami konfiguracyjnymi i muszą zawsze znajdować się w głównym katalogu rozszerzenia. Zostały one
opisane odpowiednio w rozdziałach 2.2.1 oraz 2.2.2. Oprócz tego znajduje się tutaj takŜe
katalog chrome, wraz z podkatalogami content, locale oraz skin. Zawierają one pliki z tzw.
pakietu chrom, który został opisany w rozdziale 2.2.2.
2.2.1 Manifest instalacji
Pierwszym z wymaganych plików jest install.rdf, nazywany manifestem instalacji.
Słowo manifest zostało w tym przypadku zapoŜyczone z określenia spisu przewoŜonych
przez statek towarów, czyli manifestu okrętowego. Analogia wydaje się być odpowiednia,
bowiem plik ten jest wykazem podstawowych atrybutów rozszerzenia. Jest to dokument
10
XML w formacie RDF, który dostarcza przeglądarce informacje niezbędne, aby rozszerzenie mogło zostać poprawnie w niej zainstalowane. Zawiera on metadane pozwalające na
zidentyfikowanie rozszerzenia, takie jak: identyfikator, nazwa, informacje o twórcy, specyfikujące aplikację docelową, itp. Pełną listę atrybutów moŜna znaleźć w [8]. PoniŜej przedstawiony został krótki przykład manifestu instalacji.
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<Description about="urn:mozilla:install-manifest">
<em:id>nazwa@domena</em:id>
<em:name>Nazwa</em:name>
<em:version>1.0</em:version>
<em:description>Opis rozszerzenia</em:description>
<em:creator>Informacje o twórcy</em:creator>
</Description>
</RDF>
Listing 2.1 Przykład manifestu instalacji
2.2.2 Chrom
Aby móc w pełni zrozumieć cel, dla jakiego utworzony został plik chrome.manifest,
naleŜy wyjaśnić znaczenie słowa chrom, w kontekście produktów firmy Mozilla, w tym
przeglądarki Firefox i jej rozszerzeń. Przede wszystkim, jest to określenie na zbiór wszystkich elementów interfejsu uŜytkownika, znajdujących się poza obszarem treści okna [9].
Obszar treści jest tą częścią przeglądarki, która odpowiada za wyświetlanie odwiedzanych
stron WWW. Wspomniane elementy dostarczane są przeglądarce w tzw. pakietach chrom.
Pakiet ten dostarcza takŜe część funkcjonalną rozszerzenia. KaŜdy pakiet chrom składa się
z trzech typów dostawców chrom, nazywanych zazwyczaj sekcjami, które są następujące:
•
Zawartość (ang. content) – NajwaŜniejsza sekcja. Znajdują się tutaj głównie
pliki
XUL (technologia
uŜytkownika,
opisana
w
wykorzystywana
rozdziale 2.3.1),
przy tworzeniu
które
definiują
interfejsu
interfejs
uŜytkownika rozszerzenia oraz skrypty w języku JavaScript, które zawierają
logikę rozszerzenia.
•
Pliki lokalizacyjne (ang. locale) – Sekcja ta zawiera paczki z tłumaczeniami
uŜywanych tekstów na obsługiwane języki. Są to pliki w formacie DTD lub
pliki własności, takie same jak te uŜywane w języku Java.
11
•
Skórki (ang. skin) – Sekcja ta zawiera pliki związane z wizualizacją
interfejsu uŜytkownika. Głównie są to pliki CSS oraz dodatkowe obrazki i
grafiki.
NaleŜy zaznaczyć, Ŝe wszelkie skrypty umieszczone w pakietach posiadają specjalne
uprawnienia, co oznacza, Ŝe mogą wykonywać operacje, jakie są niedostępne dla skryptów
zamieszczanych na stronach WWW. Przykładem takiej operacji jest wykonanie między
domenowego Ŝądania HTTP. UmoŜliwia to spełnienie podstawowego wymagania postawionego tworzonemu rozszerzeniu, jakim jest pobranie danych z zewnętrznego serwera.
Dostęp do plików z pakietu jest uzyskiwany za pomocą tzw. protokołu chrom, w podobny
sposób, w jaki otwierane są pliki, znajdujące się na dysku lokalnym, z uŜyciem protokołu
file. Jego URI jest następujące:
chrome://nazwa_pakietu/sekcja/ścieŜka/do/pliku
Przeglądarka nie jest w stanie samodzielnie, dla kaŜdego rozszerzenia, określić ich
nazw pakietów oraz zlokalizować połoŜenia poszczególnych sekcji. Aby jej to umoŜliwić
uŜywany jest plik chrome.manifest. Jego zawartość mówi przeglądarce gdzie mogą być
znalezione sekcje, dla określonego pakietu chrom (czyli dla rozszerzenia). Przykład podstawowej zawartości takiego pliku:
content
locale
skin
nazwa
nazwa
nazwa
pl-PL
classic/1.0
chrome/content/
chrome/locale/pl-PL/
chrome/skin/
Listing 2.2 Przykład manifestu chrom
KaŜdy z wierszy moŜna podzielić na cztery kolumny (w przypadku pierwszego, trzecia kolumna jest pusta). Pierwsza z nich określa czego dany wiersz dotyczy. Jest to tzw.
instrukcja. W tym przypadku są to nazwy sekcji, jednak istnieją takŜe instrukcje innego
typu. Pełną listę moŜna znaleźć w [9]. Druga kolumna oznacza nazwę pakietu, do którego
wiersz się odnosi. W czwartej kolumnie znajduje się bezwzględna ścieŜka do katalogu, w
którym mogą być znalezione pliki z określonej sekcji. Trzecia kolumna jest specyficzna
dla instrukcji locale oraz skin i słuŜy do sprecyzowania jaki język lub skórka są rozszerzane przez pliki z zadanych katalogów. Rozszerzenia najczęściej zawierają wiele wierszy z
instrukcją locale, co umoŜliwia obsługę wielu języków. O ile pliki z poszczególnych sekcji
moŜna umieścić w dowolnym katalogu, przyjęte jest, aby ich nazwy były zgodne z odpowiadającymi im sekcjami.
12
2.3 Wykorzystywane technologie
NajwaŜniejszymi technologiami, wykorzystywanymi podczas tworzenia rozszerzeń są:
•
XUL (wym. „zul”)
•
JavaScript
•
XPCOM
•
CSS
XPCOM bywa nazywany mózgiem rozszerzenia. Dokładniejszy opis tej technologii
znajduje się w rozdziale 2.3.2.
XUL moŜna określić jako szkielet rozszerzenia. Technologia ta powstała na podstawie języka XML. UŜywana jest do tworzenia interfejsu uŜytkownika i to na niej w duŜej
mierze opierają się rozszerzenia. Opis tej technologii znajduje się w rozdziale 2.3.1.
JavaScript to mięśnie rozszerzenia. Jest to język skryptowy uŜywany do wykonywania logiki rozszerzenia. Jest on powszechnie stosowany takŜe na stronach internetowych, jednak w przypadku rozszerzeń, szczególnie w połączeniu z technologią XPCOM,
skrypty posiadają znacznie więcej moŜliwości. Przede wszystkim, dzięki wykorzystaniu
technologii DOM (Document Object Model) mogą one dynamicznie modyfikować wygląd
okien przeglądarki. Skrypty mogą być dołączane do rozszerzenia na dwa róŜne sposoby.
Pierwszym, i najczęściej stosowanym, jest uŜycie w dokumentach XUL znanego z HTML
elementu <script>. W takim przypadku atrybut src tego znacznika, jako wartość, ma
podawane URI do wybranego skryptu (z uŜyciem protokołu chrom). Drugim sposobem
jest stworzenie tzw. modułów kodu JavaScript (ang. JavaScript code module). UmoŜliwiają one dzielenie kodu pomiędzy dwoma zakresami, zapobiegając jego wielokrotnemu załadowaniu do pamięci. Mogą być uŜywane zarówno przez samą przeglądarkę, jak i rozszerzenia. Ponadto moŜliwe jest ich dynamiczne importowanie. Cecha ta bywa uŜyteczna w
przypadku kodu, który wykonuje się rzadko, ale ma duŜe zapotrzebowanie na pamięć. Poprzez załadowanie go w wymaganym miejscu innego kodu i usunięciu po wykonaniu odpowiednich operacji, przeglądarka nie jest niepotrzebnie obciąŜana, co skutkuje jej szybszym działaniem. DuŜa część istniejących modułów została napisana przez Mozillę, jednak
uŜytkownicy tworzący rozszerzenia mogą z łatwością konstruować swoje własne i udostępniać je innym.
13
Ostatnia z technologii, czyli CSS, określana jako skóra rozszerzenia, jest uŜywana
podobnie jak w przypadku języka HTML. MoŜe posłuŜyć do zmiany koloru tła okna, wyrównania tekstu, ustawienia rozmiarów elementów, itp. CSS wspólnie z XUL odpowiadają
za interfejs uŜytkownika rozszerzenia.
2.3.1 XUL
XUL jest skrótem od angielskiego XML-Based User-Interface Language, co moŜe
zostać przetłumaczone jako Język Interfejsu UŜytkownika Oparty o XML. Technologia ta
została stworzona przez firmę Mozilla na potrzeby ich produktów. Jak sama nazwa wskazuje, jest to język uŜywany do tworzenia interfejsu uŜytkownika, przede wszystkim, dla
przeglądarki Firefox oraz jej rozszerzeń. XUL jest językiem pochodnym od XML, ale
twórcy podczas jego projektowania mocno inspirowali się językiem HTML, co moŜna
zaobserwować w wielu podobieństwach. XUL w znacznym stopniu został jednak ulepszony, w stosunku do swojego poprzednika, dzięki czemu moŜliwe jest tworzenie bardziej
zaawansowanych interfejsów. Wzorowanie się twórców na HTML skutkuje równieŜ tym,
Ŝe język ten wspiera takie technologie, jak: CSS, JavaScript, DOM, a takŜe sam HTML.
XUL posiada m.in. zbiór podstawowych kontrolek oraz elementów graficznych uŜywanych w przeglądarce, takich jak okna dialogowe, przyciski, listy wyboru, elementy menu,
itp. Dzięki temu XUL moŜna określić, jako XML z predefiniowanymi elementami. Język
ten jest interpretowany przez wbudowany w przeglądarkę silnik wyświetlania stron internetowych, o nazwie Gecko, który równieŜ został stworzony przez Mozillę. Pliki XUL rozszerzeń dostarczane są przeglądarce w sekcji zawartości (content) pakietu chrom.
Podczas tworzenia rozszerzeń, XUL zwykle definiuje jedną z dwóch rzeczy: okna
lub dynamiczne nakładki (ang. overlay). Okna dzielą się na zwykłe, oznaczane
znacznikiem <window>, które dostarczają jedynie obramowanie, całą zawartość
programista musi dodać sam. Drugim typem są okna dialogowe, oznaczane znacznikiem
<dialog> które mają wbudowane kilka przycisków, takich jak „akceptuj” czy „anuluj”,
i za pomocą odpowiedniego atrybutu znacznika, programista moŜe wybrać, których z nich
chce uŜywać. Ponadto okna mogą być określone jako modalne. Wszystkie, niezaleŜnie od
rodzaju, otwierane są za pomocą funkcji w języku JavaScript. Przykład dokumentu XUL
zawierającego definicję okna, wraz z jego rezultatem, zostały przedstawione poniŜej
(listing 2.3 oraz rys. 2.1):
14
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="chrome://global/skin/"
type="text/css"?>
<window
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.onl
y.xul" title="Przykładowe okno">
<vbox>
<vbox align="center">
<label id="etykieta" align="center"
value="Etykieta"/>
</vbox>
<hbox >
<button id="przycisk1" flex="1"
label="Przycisk 1"/>
<button id="przycisk2" flex="3"
label="Przycisk 2"/>
</hbox>
<hbox>
<textbox flex="1" value="Pole tekstowe"/>
</hbox>
</vbox>
</window>
Listing 2.3 Przykład dokumentu XUL
Rys. 2.1 Przykład okna w języku XUL
Na powyŜszym listingu zaprezentowane zostały dwie waŜne cechy języka XUL. Po
pierwsze, wszystkie dokumenty tego typu muszą posiadać odpowiednią przestrzeń nazw,
zdefiniowaną w elemencie korzenia (w tym przypadku <window>). Po drugie, układ elementów jest oparty na tzw. „modelu pudełkowym”. Za pomocą znaczników <vbox> oraz
<hbox> moŜna zebrać dowolną ilość elementów, które na wynikowym oknie zostaną ułoŜone obok siebie, zgodnie z orientacją, którą określają litery v(pionowo) oraz h(poziomo)
w nazwach znaczników. Jest to kolejna analogia do języka HTML i uŜywanych w nim
znaczników <div>.
Drugim zastosowaniem technologii XUL jest moŜliwość definiowania nakładek na
okna. Są one kolejnym elementem, który czyni XUL bardzo potęŜnym narzędziem. Pozwalają one na dodawanie nowych elementów do istniejącego juŜ interfejsu uŜytkownika,
bez konieczności modyfikacji jego kodu źródłowego. KaŜde rozszerzenie musi posiadać
15
przynajmniej jedną nakładkę, aby mogło wykonywać jakiekolwiek zadania. Są w nich bowiem umieszczone skrypty obsługujące logikę rozszerzenia, a same nakładki zostają uruchomione wraz ze startem przeglądarki. Bez dodanych elementów interfejsu, uŜytkownik
nie ma moŜliwości otwarcia ewentualnych okien rozszerzenia, zdefiniowanych w dostarczonych dokumentach XUL. Nowe elementy nakładane są najczęściej na główne okno
przeglądarki, aczkolwiek zdarzają się takŜe nakładki na inne rozszerzenia. Dodawane są
np. nowe pozycję w menu, ikony na pasku narzędzi lub dowolne inne, istniejące elementy
zdefiniowane w języku XUL. Nakładki dostarczane są jako dokument typu XUL z elementem <overlay> jako korzeniem, czego przykład znajduje się poniŜej:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="chrome://global/skin/"
type="text/css"?>
<overlay xmlns="http://www.mozilla.org/keymaster/
gatekeeper/there.is.only.xul">
<menupopup id="menu_ToolsPopup">
<menu insertafter="devToolsSeparator"
label="Element Menu">
<menupopup>
<menuitem label="Opcja 1"
oncommand="alert('Opcja 1');"/>
<menuseparator />
<menuitem label="Opcja 2"
oncommand="alert('Opcja 2');"/>
</menupopup>
</menu>
</menupopup>
</overlay>
Listing 2.4 Przykładowa nakładka w języku XUL
Na powyŜszym przykładzie zaprezentowano sposób dodania nowej pozycji do menu,
istniejącego w głównym oknie przeglądarki. PoniewaŜ ma to być nakładka, elementem
korzenia jest <overlay>, wraz ze zdefiniowaną przestrzenią nazw. Aby rozszerzyć
istniejące elementy, naleŜy się do nich odwołać za pomocą odpowiednich identyfikatorów.
W tym przypadku jest to menu „Narzędzia”, znajdujące się na pasku menu głównego okna
przeglądarki, posiadające identyfikator "menu_ToolsPopup". Dodane zostaje nowe
podmenu, które ma dwie pozycje, a miejsce jego umieszczenia określone jest takŜe za
pomocą odwołania do innego elementu. W tym przypadku jest to po separatorze,
znajdującym
się
w
menu
„Narzędzia”,
który
ma
identyfikator
"devToolsSeparator". Analogicznie rozszerzane są inne elementy, jak na przykład
paski narzędzi czy dodatków.
16
Samo zamieszczenie pliku w pakiecie chrom nie wystarcza, aby mógł on być poprawnie obsłuŜony w przeglądarce. śeby stało się to moŜliwe, wymagane jest zasygnalizowanie jego obecności wewnątrz pliku chorme.manifest (opisanym w rozdziale 2.2.2)
poprzez dodanie następującego wiersza:
overlay
chrome://browser/content/browser.xul
chrome://nazwa/content/overlay.xul
Wiersz ten oznacza, Ŝe plik browser.xul, znajdujący się w pakiecie browser
(czyli głównym pakiecie przeglądarki) jest rozszerzany o plik overlay.xul z przykładowego pakietu.
2.3.2 XPCOM
XPCOM to skrót od angielskiego Cross Platfrom Component Object Model, co
moŜna przetłumaczyć jako Międzyplatformowy Model Komponentów. Przeglądarkę
Firefox moŜna podzielić na dwie znaczące warstwy. Pierwszą z nich jest „wewnętrzna”,
kompilowana platforma, napisana głównie w języku C++ oraz „zewnętrzna” warstwa
chrom (opisana w rozdziale 2.2.2). Funkcjonalności „wewnętrznej” warstwy nie są
dostępne dla skryptów umieszczonych w chromie (takŜe ze względu na ograniczenia
języka JavaScript), ale często występują sytuacje, kiedy w trakcie tworzenia rozszerzeń
pojawia się potrzeba wykonania operacji specyficznej dla przeglądarki. Aby nie
ograniczać, w drastyczny sposób, moŜliwości programistów, tworzących aplikacje oparte
na produktach Mozilli, funkcjonalności te zostały udostępnione za pomocą komponentów
oraz interfejsów XPCOM. Innymi słowy, XPCOM moŜna postrzegać jako sposób
komunikacji opisanych warstw lub jako warstwę, umoŜliwiającą dostęp do operacji
niedostępnych z poziomu języka JavaScript, jak np. zarządzanie pamięcią.
XPCOM moŜe być obsługiwany w wielu róŜnych językach programowania, a w
przypadku rozszerzeń jest to JavaScript. Do komunikacji pomiędzy tym językiem i
XPCOM słuŜy technologia XPConnect (Cross Platform Connect).
var preferences =
Components.classes["@mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
var value = preferences.getCharPref("nazwaPreferencji");
Listing 2.5 Przykład wykorzystania komponentu XPCOM
17
Na powyŜszym listingu przedstawiony został sposób wykorzystania komponentu
XPCOM w języku JavaScript, z uŜyciem technologii XPConnect. Aby móc korzystać z
komponentów naleŜy wykonać kilka operacji. Po pierwsze, niezbędne jest wydobycie
definicji klasy, odpowiadającej wybranemu komponentowi. Odbywa się to za pomocą
obiektu, który zawiera te definicje, czyli Component.classes. Podany tekst,
znajdujący się pomiędzy nawiasami kwadratowymi, jest identyfikatorem komponentu. W
tym przypadku jest to komponent udostępniający usługę preferencji przeglądarki.
Otrzymany tym sposobem komponent moŜe być serwisem (statycznym obiektem) lub
instancją klasy. Aby otrzymać ostateczny obiekt, na którym będzie moŜliwe wykonywanie
operacji, naleŜy wywołać metodę getService() lub getInstance(), odpowiednio
dla serwisu i instancji. Jako argument, dla tych metod, podawany jest wybrany interfejs.
Zbiór interfejsów, analogicznie jak definicje klas, dostępny jest za pomocą obiektu
Components.interfaces, a sam interfejs jest definicją zbioru atrybutów i metod,
które musi posiadać obiekt implementujący. Tutaj obiektami tymi są komponenty, a wiele
z nich implementuje kilka róŜnych interfejsów. Na otrzymanym, końcowym obiekcie,
moŜliwe jest wykonanie operacji dostępnych dla wybranego interfejsu. Największy zbiór
dostępnych interfejsów oraz komponentów, wraz z ich opisami, moŜna znaleźć w [10].
Komponenty XPCOM są bardzo potęŜnym narzędziem, które znacznie zwiększa zakres wykorzystania rozszerzeń, z których większa część nie mogłaby powstać, gdyby nie
one. Oprócz moŜliwości korzystania z wbudowanych komponentów, programista ma takŜe
do dyspozycji narzędzia pozwalające stworzyć własne implementacje.
2.4 Typy rozszerzeń
Wykorzystanie omówionych w poprzednich rozdziałach technologii jest jednym z
dwóch sposobów tworzenia rozszerzeń. Ze względu na uŜycie języka XUL, dodatki tego
typu nazywane są rozszerzeniami opartymi o XUL lub inaczej tradycyjnymi. Drugim ze
sposobów jest uŜycie zestawu bibliotek Add-on SDK, udostępnianych przez Mozillę. W
momencie powstawania tej pracy, technologia ta była dosyć nowa i nieustannie rozwijana
o kolejne elementy. Został w niej całkowicie wyeliminowany język XUL, zastąpiony przez
HTML, a oprócz niego wykorzystywane są takŜe CSS oraz JavaScript.
Pierwszym zadaniem, koniecznym do realizacji tej pracy była decyzja o wyborze
sposobu stworzenia rozszerzenia. Co jest niewątpliwą zaletą rozszerzeń opartych o SDK,
18
skrypty w nich uŜywane są w głównej mierze oparte na dostarczonych interfejsach programowania aplikacji (API). Zawierają one wiele najczęściej uŜywanych funkcji, które są
łatwe w uŜyciu i, w związku z tym, część operacji moŜna wykonać szybciej, niŜ w tradycyjnych rozszerzeniach. Mankamentem tego rozwiązania jest to, Ŝe w momencie podejmowania decyzji nie wszystkie wymagane funkcje były przez SDK wspierane, co skutkowałoby wieloma ograniczeniami. NajwaŜniejszym z nich jest tworzenie interfejsu uŜytkownika, który po rezygnacji z języka XUL został oparty na HTML, a ten nie jest wystarczająco rozbudowany, aby moŜliwe było stworzenie wszystkich wymaganych elementów
graficznych. Ponadto nie ma takŜe wbudowanej obsługi bazy danych, która jest bardzo
istotną częścią tworzonego rozszerzenia.
Ostatecznie wybór padł na tradycyjne rozszerzenie. Pomimo koniecznego większego
wkładu czasowego, wybrane rozwiązanie skutkuje moŜliwością uŜycia potęŜniejszych
narzędzi, pozwalających na spełnienie postawionych wymagań.
2.5 Zotero
Zotero to rozszerzenie do przeglądarki Firefox, które ułatwia gromadzenie, organizowanie oraz analizowanie źródeł informacji. Zostało ono zaprojektowane jako narzędzie
wspomagające pracę naukową, a przede wszystkim tworzenie bibliografii. Z jego pomocą
moŜna w łatwy sposób pobrać i zapisać na dysku obszerne dane bibliograficzne (autor,
tytuł, ISBN, ilość stron, itp.), dotyczące wybranej publikacji. Jest ono wykorzystywane
głównie przez naukowców i studentów piszących prace naukowe oraz dyplomowe.
Do tego dodatku powstało rozszerzenie o nazwie „Zotero Scholar Citations”, które
wprowadza moŜliwość pobrania liczby cytowań pracy, czego nie ma w samym Zotero.
Taka sama funkcja jest wymagana w rozszerzeniu tworzonym w ramach tej pracy, co moŜe
wydawać się niepotrzebnym duplikowaniem pracy. Istnieje jednak kilka powodów, dlaczego nie moŜna uŜyć omawianego tutaj rozszerzenia, aby spełnić postawione cele. Przede
wszystkim, nie współpracuje ono z repozytorium, dla którego mają być pobierane cytowania i nie ma moŜliwości ich powiązania. Pobierana liczba cytowań jest praktycznie tylko
do odczytu, zapisywana jest ona bowiem w bazie danych rozszerzenia Zotero. W celu ich
uzyskania i dostarczenia do repozytorium, konieczne byłoby i tak napisanie odpowiedniego rozszerzenia. Ponadto, co jest najwaŜniejsze, pobieranie liczby cytowań z serwisu Google Scholar jest nieefektywne, czego zarówno powody, jak i skutki zostały opisane w rozdziale 3.4.5.
19
3 Projekt rozszerzenia
3.1 Wymagania
Głównym wymaganiem, jakie zostało postawione przed tworzonym rozszerzeniem
jest umoŜliwienie pobrania liczby cytowań dla kaŜdej publikacji, znajdującej się w cyfrowym repozytorium dokumentów Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Oprócz samej liczby cytowań, aplikacja powinna takŜe pobierać
listę prac, w których się one znajdują (prac cytujących), wraz z odnośnikami do ich cyfrowych kopii, o ile są dostępne. Wskazane jest, aby dostępne były dwie formy pobierania
danych: zautomatyzowane uzyskanie liczby cytowań dla wielu publikacji jednocześnie, lub
ręczne, dla pojedynczej publikacji. NaleŜy takŜe zapobiec wielokrotnemu pobieraniu tych
samych danych. W tym celu musi zostać stworzona baza danych publikacji, wraz z ich
cytowaniami, z której, za kaŜdym kolejnym razem po pobraniu, będą uzyskiwane informacje. Baza ta musi równieŜ umoŜliwiać aktualizację znajdujących się w niej danych, dotyczących wybranej publikacji.
Tworzone rozszerzenie musi prezentować pobrane dane uŜytkownikom, którymi będą głównie pracownicy naukowi Wydziału. Tak jak wszystkie aplikacje wyświetlające
informacje, tak i w tym przypadku interfejs powinien być przyjazny w odbiorze oraz uŜytkowaniu. Dodatek będzie współpracować z cyfrowym repozytorium, dlatego musi się ono
wpasować w istniejący interfejs uŜytkownika, w taki sposób, aby dodatkowe informacje
były widoczne na pierwszy rzut oka, ale nie przesłaniały pozostałych elementów strony.
Muszą być takŜe spełnione poniŜsze wymagania niefunkcjonalne:
•
Rozszerzenie powinno działać na dowolnym komputerze, niezaleŜnie od systemu operacyjnego, o ile ma on zainstalowaną najnowszą wersję przeglądarki
Mozilla Firefox.
•
Dodatek powinien być jak najlŜejszy. Oznacza to, Ŝe nie powinien zajmować
duŜo miejsca w pamięci, a takŜe czasu procesora, poprzez wykonywanie niepotrzebnych operacji „w tle”.
•
Przeglądarka nie moŜe zostać zablokowana przez rozszerzenie. Wszystkie
operacje, czy to wykonywane w rozszerzeniach, czy w głównej aplikacji wy-
20
konywane są w jednym wątku, dlatego waŜne jest, aby kończyły się one najszybciej, jak to jest moŜliwe.
•
W zaleŜności od wybranego języka repozytorium, powinna istnieć moŜliwość
odpowiedniego przetłumaczenia wyświetlanych tekstów rozszerzenia.
3.2 Współpraca z repozytorium oraz interfejs uŜytkownika
Tworzone rozszerzenie będzie współpracowało z cyfrowym repozytorium dokumentów Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, a konkretnie z jego interfejsem uŜytkownika. W momencie powstawiania tej pracy, dostęp do
wyszukiwarki publikacji moŜna uzyskać, wchodząc pod jeden z dwóch adresów:
•
http://repo.pw.edu.pl/search.seam?lang=pl
•
http://www.elka.pw.edu.pl/pol/Badania-naukowe/RepozytoriumWEiTI/Publikacje-pracownikow
Na samą wyszukiwarkę rozszerzenie nie będzie w Ŝaden sposób wpływać. Istotna
jest strona otrzymana po dokonaniu wyszukania. Zawiera ona tabelę z rezultatami wyszukiwań, której fragment został przedstawiony poniŜej.
Rys. 3.1 Fragment tabeli z rezultatami wyszukiwania w repozytorium
Jak widać, tabela ta składa się w większości (poza wierszami tytułowymi) z trzech
kolumn, z których najbardziej interesująca jest ostatnia. Po analizie okazało się, Ŝe będzie
ona najlepszym miejscem, w którym moŜna dokonać zmiany w interfejsie. Widoczne są
tam dwie etykiety. Pierwsza z nich „szczegóły” prowadzi do wewnętrznej strony repozytorium, zawierającej informacje o danej publikacji. Druga, nazwana „scholar”, zawiera od21
nośnik do serwisu Google Scholar, z tytułem publikacji, jako frazą wyszukiwania. Adres
ten, po drobnej zmianie, będzie pomocny podczas pobierania cytowań, a sposób opisu jego
wykorzystania został opisany w rozdziale 3.4.3. Modyfikacja tej komórki tabeli będzie
polegała na dodaniu trzeciej etykiety. Jej tekst będzie zawierał informacje o liczbie cytowań publikacji, znajdującej się w danym wierszu tabeli. Oprócz tego, po kliknięciu na nią,
otwierane będzie dodatkowe okno, w którym znajdą się informacje dotyczące publikacji, w
tym lista prac ją cytujących, o ile takie istnieją.
Dzięki opisanemu powyŜej rozwiązaniu nastąpi modyfikacja istniejącego interfejsu
uŜytkownika, która będzie zarówno przyjazna uŜytkownikowi, jak i nie zmieniająca w
drastyczny sposób oryginalnego wyglądu. UŜytkownik w prosty sposób będzie mógł poznać liczbę cytowań publikacji. Lista prac cytujących moŜe zawierać wiele pozycji, więc
ich wyświetlenie dla kaŜdej z publikacji znajdującej się w tabeli (jest ich maksymalnie 20
na stronę) zajęłoby duŜą część okna przeglądarki. Nie jest to poŜądane zachowanie, szczególnie dlatego, Ŝe przewaŜnie uŜytkowników nie interesują informacje dotyczące wszystkich rezultatów wyszukiwania. Natomiast w proponowanym rozwiązaniu dane te są początkowo ukryte, a jeśli uŜytkownik będzie chciał dowiedzieć się więcej o wybranej publikacji, wystarczy jedno kliknięcie na odpowiednią etykietę.
Inna istotną kwestią, jaka wymagała rozwiązania, było wykrycie wejścia na stronę
zawierającą repozytorium. Dokładny sposób został opisany w rozdziale 4.2, jednak w tym
miejscu naleŜy wspomnieć, Ŝe opiera się on na adresie serwera repozytorium. W trakcie
tworzenia tej pracy, repozytorium nie było jeszcze w pełni ukończone, a jego adres się
zmieniał. Z tego powodu, konieczne było wprowadzenie opcji, która umoŜliwi uŜytkownikowi ręczne wprowadzenia aktualnego namiaru. Realizacja moŜliwości jego ustawienia
została opisana w rozdziale 4.1.1.
3.3 Źródło liczby cytowań
Istotnym aspektem, niezbędnym do zrealizowania postawionych wymagań jest
określenie źródła, z którego będzie uzyskiwana liczba cytowań. W sieci dostępnych jest
kilka baz danych zawierających publikacje naukowe, wraz podstawowymi informacjami
na ich temat (w tym właśnie liczbą cytowań). Najpopularniejszymi serwisami
umoŜliwiającymi przeszukiwanie tych baz są: Google Scholar, Scopus, Web of Science,
Scirus oraz CiteSeerX. Przyjęto pewne kryteria, których analiza posłuŜy do wyboru
22
jednego z serwisów. NajwaŜniejsze z nich to: dostępność dla uŜytkowników, łatwość w
uzyskaniu liczby cytowań oraz wielkość bazy danych.
Biorąc pod uwagę dostępność, wymienione serwisy moŜna podzielić na dwie kategorie: darmowe oraz płatne. Do pierwszej grupy zaliczają się Google Scholar, Scirus oraz
CiteSeerX i kaŜdy moŜe ich uŜywać. Scopus oraz Web of Science znajdują się w drugiej i
wymagane jest wykupienie subskrypcji, aby moŜliwe było wyszukiwanie publikacji z ich
bazy danych. Wydział Elektroniki i Technik Informacyjnych ma, na moment pisania tej
pracy, opłacony abonament na te serwisy. W związku z tym, docelowi uŜytkownicy rozszerzenia, czyli pracownicy naukowi Wydziału, mogą z nich korzystać, jednak tylko będąc
połączonym z Internetem poprzez sieć wydziałową. Ograniczenie to jest zatem powaŜnym
argumentem przeciwko uŜyciu któregoś z tych serwisów, jako głównego źródła informacji.
Kolejnym kryterium jest łatwość w uzyskaniu liczby cytowań. Przede wszystkim,
przedstawione serwisy nie udostępniają Ŝadnego interfejsu programowania aplikacji (API),
który umoŜliwiałby pobranie pełnych informacji dotyczących publikacji, lub chociaŜ samej
liczby cytowań. Jedynym sposobem jest analiza dokumentu HTML, zawierającego stronę z
rezultatami wyszukiwania. W serwisach Google Scholar, CiteSeerX, Web of Science oraz
Scopus liczba cytowań jest bardzo łatwo dostępna. Wystarczy bowiem jedynie wyszukać
odpowiednią frazę (przykładowo tytuł publikacji) i przy kaŜdym zwróconym rezultacie
widoczna jest etykieta z przedstawioną liczbą cytowań. Po kliknięciu na nią, moŜliwe jest
uzyskanie listy prac, w których te cytowania się znajdują. UŜycie tych serwisów pozwala
więc na spełnienie postawionych wymagań. Scirus z kolei nie pozwala na łatwe uzyskanie
ani liczby cytowań, ani listy prac cytujących. Ręczne pobranie odbywa się za pomocą
skryptów zamieszczonych na stronie, co całkowicie wyklucza moŜliwość uŜycia tego serwisu w tworzonym rozszerzeniu.
Ostatnim z omawianych kryteriów jest wielkość bazy danych. W tym przypadku
rozwaŜane serwisy równieŜ moŜna podzielić na dwie grupy, a podział ten opiera się na
zawartościach baz danych. W pierwszej znajdują się Google Scholar oraz CiteSeerX.
Podobnie jak najpopularniejsze wyszukiwarki internetowe, przeszukują one automatycznie
dostępne strony WWW i pobierają z nich znalezione publikacje. Ich baza danych zawiera
więc jedynie pozycje, które są zamieszone, i moŜliwe do znalezienia, w Internecie.
CiteSeerX posiada w swojej bazie ponad 2 miliony dokumentów, natomiast Google
Scholar nie udostępniło liczby posiadanych przez nich rekordów. Wiadome jest jednak, Ŝe
23
znajduje się ona w czołówce baz tego typu, o ile nie jest największa, głównie ze względu
na moŜliwość przeszukania większej liczby stron (Google Scholar korzysta takŜe z bazy
danych regularnej wyszukiwarki Google). Na potwierdzenie powyŜszego stwierdzenia,
przeprowadzone zostało porównanie znalezionej liczby cytowań na obu serwisach, dla tej
samej publikacji. Dla pracy o tytule „Fast algorithms for mining association rules”,
Google Scholar wskazał 13609 cytowań, natomiast CiteSeerX jedynie 2121 [Dane na
dzień: 13.01.2013 r].
Drugą grupę, w ramach omawianego kryterium, tworzą serwisy Web of Science oraz
Scopus. Oba posiadają własne bazy danych. Ich główną róŜnicą, w porównaniu z serwisami naleŜącymi do pierwszej grupy, jest to, Ŝe uwzględnione są w nich przewaŜnie tylko
publikacje z oficjalnych, zrecenzowanych czasopism, ksiąŜek oraz konferencji. Szczególnie moŜna w nich znaleźć takie, które nie są dostępne nigdzie indziej w sieci. Ponadto,
cytowania dostępne w tych serwisach nie są wyszukiwane automatycznie, jak w poprzednim przypadku. Web of Science posiada w swojej bazie danych prawie 50 milionów rekordów. Wśród nich znajdują się cytowane prace, które były publikowane w okresie od roku
1900 do czasów obecnych. Scopus takŜe posiada prawie 50 milionów rekordów, z czego
objętych liczbą cytowań jest 28 milionów. W tym przypadku są one datowane najwcześniej na 1996 rok. Obie te bazy zawierają takŜe większą ilość informacji dotyczących publikacji, niŜ Google Scholar (np. pełne streszczenia prac).
Autorzy pracy [11] porównują serwisy Google Scholar oraz Web of Science, wskazując przy tym ich wady. Przede wszystkim, Web of Science ogranicza cytowania do publikacji z oficjalnej listy czasopism, mimo, Ŝe pozycje spoza niej mogą równieŜ być wysokiej
jakości. Ponadto serwis ten pokrywa jedynie w małym stopniu źródła w języku innym, niŜ
angielski, tłumacząc przy tym tytuły wszystkich publikacji na ten właśnie język. Z drugiej
strony, Google Scholar nie ma dostępu do niektórych czasopism naukowych, więc nie
uwzględnia znajdujących się w nich cytowań. Nie zawiera takŜe wielu starszych publikacji, a oprócz tego, serwis ten jest zdecydowanie rzadziej aktualizowany. Zaprezentowane
zostały takŜe wyniki przeprowadzonych badań, które wykazały, Ŝe Google Scholar znajduje 2,5 razy więcej cytowań niŜ Web of Science. Podobne wyniki uzyskali równieŜ autorzy
pracy [12].
Ostatecznie, po przeanalizowaniu wszelkich argumentów, wybrany został serwis
Google Scholar. Posiada on największą darmową bazę danych publikacji, a takŜe liczba
24
cytowań jest łatwo dostępna. Biorąc pod uwagę dziedzinę nauki, w jakiej znajdują się prace w repozytorium, czyli głównie Informatykę, wady takie jak brak starszych publikacji,
czy brak dostępu do niektórych czasopism naukowych nie sprawiają duŜego kłopotu.
Większość prac z tego obszaru jest bowiem powszechnie dostępna on-line (w przeciwieństwie do np. publikacji medycznych). Ponadto, czasami w publikacjach wskazywana jest
wada Google Scholar, dotycząca problemu z wyszukiwaniem prac, uŜywając słów kluczowych. Jednak nie dotyczy on tego przypadku, bowiem wyszukiwaną frazą będzie zawsze cały tytuł publikacji. Mimo wszystko, wybór tego serwisu wprowadza ograniczenia do
tworzonego rozszerzenia, które zostały przedstawione w rozdziale 3.4.5.
3.4 Metody pobierania liczby cytowań
Kolejnym wymaganym krokiem, w kierunku poprawnego zaprojektowania rozszerzenia, jest określenie sposobu, w jaki liczba cytowań będzie pobierana z wybranego serwisu. Jak zostało wspomniane w rozdziale 3.3, Google Scholar nie posiada interfejsu programowania aplikacji, który umoŜliwiłby uzyskanie danych w bezpośredni sposób. Z tego
powodu konieczne było opracowanie innej metody, która w łatwy sposób umoŜliwi ominięcie problemu brakującej funkcjonalności.
3.4.1 Analiza strony źródłowej Google Scholar
ZałoŜone podejście zakłada analizę zawartości dokumentu HTML ze stroną wynikową wyszukiwania publikacji, z uŜyciem technologii DOM. Na rys. 3.2 przedstawiony
jest zrzut ekranu zawierający fragment strony, otrzymanej po wyszukaniu frazy „mining”.
Widoczne są cztery róŜne wyniki. Dla kaŜdego z nich, wszystkie informacje, takie jak tytuł, opis czy liczba cytowań są umieszczone w elemencie HTML <div>. Mają one ustaloną klasę, o nazwie gs_r, dzięki czemu, uŜycie wbudowanej metody technologii DOM:
getElementsByClassName(„gs_r”), umoŜliwia łatwe zebranie listy wszystkich
rezultatów. Metoda ta, w języku JavaScript, zwraca tablicę, która zawiera elementy oznaczone zadaną nazwą klasy. Wnętrze znalezionych elementów moŜe przyjmować róŜną
postać.
25
Rys. 3.2 Fragment strony Google Scholar z rezultatami wyszukiwania
Tytuły znalezionych publikacji są prezentowane na dwa sposoby. Powoduje to, Ŝe
konieczne jest opracowanie dwóch metod ich znalezienia i uzyskania. Pierwszy przypadek
dotyczy prac, dla których nie zostały znalezione cyfrowe kopie dokumentów. Znajdują się
jednak w bazie, poniewaŜ są cytowane w innych pracach. Przykładem jest pierwszy rezultat widoczny na powyŜszym zrzucie ekranu. Tytuł ten składa się zawsze z dwóch części:
etykiety „[CYTOWANIE]” oraz właściwego tekstu. Obie części zostały umieszczone
wewnątrz elementu <h3>, któremu została nadana klasa gs_rt. Aby otrzymać poprawny
tytuł naleŜy ponowne uŜyć metody getElementsByClassName(„gs_rt”) i, dla
pierwszego elementu otrzymanej tablicy, usunąć wspomnianą etykietę.
Drugi przypadek prezentacji tytułu jest stosowany zdecydowanie częściej. Dotyczy
on tych pozostałych prac, dla których znalezione zostały cyfrowe kopie dokumentów. Cały
tekst, łącznie z ewentualną etykietą (w tym przypadku są to „[PDF]” oraz
„[KSIĄśKA]”), podobnie jak poprzednio, został umieszczony wewnątrz elementu
<h3>. Jednak poniewaŜ tytuł jest prezentowany jako odnośnik, uŜyty został takŜe element
<a>, który zawiera tylko i wyłącznie właściwy tekst tytułu. Elementy te, dla kolejnych
rezultatów wyszukiwania, przyjmują róŜniące się, ale schematyczne nazwy klas i są to
kolejno: yC0, yC2, yC4, itd. Dzięki temu, wystarczające jest jedynie uŜycie metody
26
getElementsByClassName(), z odpowiednią klasą jako argumentem. Pierwszym
elementem wynikowej tablicy będzie szukany tytuł.
W ostatnim wierszu pojedynczego rezultatu wyszukiwania znajduje się element
<div>, o klasie gs_fl, który grupuje dodatkowe informacje dotyczące publikacji, w
tym, przede wszystkim, liczbę jej cytowań. Znajduje się tam kilka elementów o znacznikach <a>. Sposobem na uzyskanie liczby cytowań jest pobranie pierwszego z tych elementów. Następnie naleŜy sprawdzić, czy wartość jego atrybutu href jest zgodna z następującym schematem: „/scholar?cites=” (jest to fragment adresu URL do odpowiedniej
strony serwisu Google Scholar). Jeśli tak, to znaczy Ŝe dana publikacja jest cytowana
przynajmniej jeden raz, a odnośnik ten prowadzi do strony zawierającej listę prac, w których te cytowania się znajdują. Znaleziony element ma etykietę w formacie „Cytowane
przez 1234”. Najlepszym sposobem na pobranie dokładnej liczby cytowań, jest usunięcie z
etykiety tekstu (czyli „Cytowane przez”) i pozostawienie jedynie numeru. Przypadek, kiedy atrybut href nie ma wartości, która wpasowuje się w zadany schemat oznacza, Ŝe publikacja taka nie jest nigdzie cytowana (liczba jej cytowań wynosi 0). Przykład został
przedstawiony na rys. 3.3.
Rys. 3.3 Przykład publikacji nieposiadającej cytowań
Strona, która zawiera listę prac cytujących jest podobna do zwykłej strony z
rezultatami wyszukiwania, a jej fragment został przedstawiony na rys. 3.4. Pierwszym
widocznym wierszem, na tym zrzucie ekranu, jest tytuł publikacji, do której cytowania się
odnoszą. Następnie, kolejne wyniki są takŜe umieszczane wewnątrz elementu <div> o
klasie gs_r. W związku z czym, pobieranie tytułów przebiega tak samo, jak zostało to
opisane na początku tego rozdziału. W tym przypadku nie będzie konieczne pobieranie
liczby cytowań, a jedynie tytułów publikacji, oraz ewentualnie odnośników do ich
cyfrowych kopii. Jeśli takie istnieją, są one wartościami atrybutu href elementów <a>,
zawierających tytuł.
27
Rys. 3.4 Fragment listy publikacji cytujących
Przyjęta metoda uzyskiwania danych ze strony źródłowej Google Scholar jest szybka
i nie wymaga skomplikowanych operacji, jednak posiada pewną wadę. W przypadku
zmiany układu elementów na stronie, lub nazw ich klas, wymagana będzie modyfikacja
kodu źródłowego rozszerzenia, aby mógł on poprawnie odczytać aktualny układ strony i
pobrać z niej wymagane dane. Niestety, brak alternatyw wymusza zastosowanie opisanego
podejścia.
3.4.2 Wysyłanie Ŝądań HTTP w języku JavaScript
Posiadając sposób uzyskania wymaganych danych ze strony Google Scholar,
kolejnym krokiem jest zdefiniowanie metody, która pozwoli na pobranie odpowiedniego
dokumentu HTML z zewnętrznego serwera. Proponowane rozwiązanie zakłada
wykorzystanie wbudowanego obiektu języka JavaScript – XMLHttpRequest, który jest
powszechnie uŜywany do wykonywania Ŝądań HTTP. Jest on głównym elementem bardzo
popularnej techniki tworzenia stron internetowych – AJAX (Asynchronous JavaScript and
XML). Technika ta umoŜliwia asynchroniczną komunikację klienta z serwerem, dzięki
czemu moŜliwe jest wyświetlanie nowych treści na stronie, bez potrzeby przeładowywania
całego dokumentu HTML. Jest to potęŜna technologia, która w znacznym stopniu
przyczyniła się do tego, jak wygląda dzisiaj sieć WWW (uŜywają jej takie serwisy, jak
Gmail, Google Maps czy Facebook). Została ona jednak z powodów bezpieczeństwa
28
znacznie ograniczona. Mianowicie, zabroniona została moŜliwość wysyłania Ŝądań HTTP
do innej domeny, niŜ ta, na której zamieszczony jest skrypt wykonujący operację.
Restrykcja ta jest przestrzegana po stronie przeglądarki i nie są nią objęte skrypty
składające się na rozszerzenie. Znajdują się one bowiem w pakiecie chrom i mają wyŜszy
poziom uprawnień niŜ skrypty zamieszczane na stronach (rozdział 2.2.2). Sprawia to, Ŝe
nic nie stoi na przeszkodzie, aby wykorzystać obiekt XMLHttpRequest w tworzonym
rozszerzeniu.
Na listingu 3.1 przedstawiono przykład uŜycia obiektu XMLHttpRequest, w języku JavaScript, który po odpowiednim dostosowaniu zostanie wykorzystany w tworzonym
rozszerzeniu. Atrybut onload słuŜy do przypisania funkcji, która będzie wywoływana, w
momencie, gdy odpytywany serwer zwróci Ŝądaną stronę. W tym przypadku sprawdza
ona, czy Ŝądanie zostało zakończone (readyState===4) oraz kod odpowiedzi HTTP
jest poprawny (status===200). Jeśli oba warunki są spełnione, odpowiedź na Ŝądanie
zawiera oczekiwany dokument HTML, który moŜe zostać odpowiednio przeanalizowany.
Metoda open() jest uŜywana do ustalenia kolejno: metody Ŝądania, adresu Ŝądanej strony oraz określenia, czy Ŝądanie ma zostać wykonane asynchronicznie. Za ostateczne wysłanie Ŝądania odpowiada metoda send(), która moŜe przyjąć jako argument dodatkowe,
potrzebne dane. Pełna specyfikacja obiektu XMLHttpRequest znajduje się w [13].
var http_request = new XMLHttpRequest();
http_request.onload = function() {
if (request.readyState===4 && request.status===200){
//obsługa otrzymanej odpowiedzi
}};
http_request.open("GET", "www.example.com", true);
http_request.send(null);
Listing 3.1 Przykład uŜycia obiektu XMLHttpRequest
3.4.3 Pobieranie danych pojedynczej publikacji
Pobieranie danych pojedynczej publikacji odbywać się będzie na kilka sposobów.
Przede wszystkim, jak zostało przedstawione w rozdziale 3.2, wewnątrz okna, otwieranego
po kliknięciu na dodaną etykietę, obecny będzie przycisk, umoŜliwiający aktualizację cytowań. Pobranie pełnych danych odbywać się będzie zawsze. Jeśli dla danej publikacji
będą one juŜ obecne w bazie danych, nastąpi tylko aktualizacja daty pobierania. Po udanym wykonaniu operacji, uzyskane dane będą prezentowane uŜytkownikowi – odświeŜona
zostanie zarówno zawartość okna, jak i odpowiednia etykieta na stronie repozytorium.
29
Opisany sposób wymaga od uŜytkownika wykonania dwóch akcji, które prowadzą do uzyskania oczekiwanego rezultatu. Aby uczynić rozszerzenie bardziej przyjaznym w uŜytkowaniu, wprowadzona zostanie moŜliwość częściowego zautomatyzowania tych operacji.
UŜytkownikowi udostępniony zostanie wybór, dotyczący tego, jak rozszerzenie będzie zachowywać się w przypadku kliknięcia na dodaną przez rozszerzenie etykietę cytowań. Oprócz tego, Ŝe zawsze zostanie otwarte odpowiednie okno, w zaleŜności od wybranej opcji nastąpi takŜe pobranie brakujących danych. Będzie to albo sama liczba cytowań
danej publikacji, albo jej pełne dane (czyli dodatkowo lista prac cytujących). Opisane operacje będą jednak dostępne tylko w przypadku, gdy dane nie były wcześniej pobierane. To
znaczy, Ŝe aktualizacja danych będzie moŜliwa jedynie za pomocą wspomnianego w poprzednim akapicie przycisku.
Aby móc spełnić postawione wymagania, konieczne jest zdefiniowanie procedury,
która obejmuje pobranie danych, a zakończona zostaje wyświetleniem ich uŜytkownikowi.
Pierwszy jej etap wymaga ustalenia adresu URL do serwera Google Scholar, który
pozwoli uzyskać dokument HTML, zawierający stronę wyszukiwania zadanej publikacji.
W tym celu uŜyty zostanie element obecny w tabeli rezultatów wyszukiwania
repozytorium, oznaczony etykietą „scholar”, przypisany do danej pracy. Jest to element ze
znacznikiem
<a>,
którego
wartość
atrybutu
href
ma
następującą
postać:
scholar.google.com/scholar?q="tytuł publikacji". Adres ten, aby mógł posłuŜyć do
pobrania danych, musi zostać poddany drobnej modyfikacji. UŜyty w oryginalnym URL
parametr q zostanie zamieniony na as_q, a takŜe dodany zostanie parametr as_sauthors,
który pozwala na wyspecyfikowanie autora wyszukiwanej publikacji. Ostateczny wygląd
adresu będzie następujący:
scholar.google.com/scholar?as_q="tytuł publikacji"&as_sauthors=Autor
Zmiana ta jest podyktowana tym, Ŝe czasami istnieje kilka prac o takim samym tytule, ale napisanych przez innych autorów. Dzięki ich wyspecyfikowaniu, wyszukiwanie
będzie bardziej precyzyjne, co pozwoli na uniknięcie konieczności wykonywania dodatkowych operacji, podczas analizy dokumentu HTML.
Drugi etap składa się z dwóch kroków, a pierwszym z nich jest wysłanie Ŝądania
HTTP, metodą GET, pod opisany w poprzednim akapicie adres. Jeśli nie wystąpi Ŝaden
błąd i w odpowiedzi otrzymany zostanie odpowiedni dokument HTML, naleŜy przystąpić
do znalezienia odpowiedniego rezultatu dla szukanej publikacji. Z kolejnych wyników
30
wyszukiwania wydobywane są tytuły (według sposobów opisanych w rozdziale 3.4.1),
które następnie zostają porównane z tytułem szukanej publikacji. Ze znalezionego rezultatu pobierana jest liczba jego cytowań oraz odnośnik do prac cytujących. W tym momencie,
jeśli praca nie jest cytowana (liczba cytowań równa jest 0), następuje koniec tego etapu
procedury i przejście do następnego. Brak liczby cytowań występuje takŜe w przypadku,
gdy publikacja nie została znaleziona wśród rezultatów wyszukiwania (w szczególności,
gdy zapytanie z szukaną frazą nie zwróciło Ŝadnych wyników). Zakończenie etapu ma
takŜe miejsce teraz, gdy uŜytkownik wybrał opcję automatycznego pobrania jedynie liczby
cytowań.
Kolejny krok omawianego etapu jest wykonywany tylko wtedy, gdy warunki
zakończenia, opisane w poprzednim akapicie nie zostały spełnione. W jego trakcie
wysyłane jest Ŝądanie HTTP, metodą GET, z pobranym wcześniej adresem URL,
prowadzącym do strony z listą prac, w których znajdują się cytowania szukanej publikacji.
Ich tytuły oraz odnośniki do cyfrowych kopii dokumentów będą uzyskane w taki sposób,
jak zostało to opisane w rozdziale 3.4.1. Konieczne było jednak wprowadzenie limitu na
liczbę tak pobranych prac. Wynosi on 100 i zarówno powód takiej restrykcji oraz to, z
czego wynika podana liczba, zostały opisane w rozdziale 3.4.5.
Kolejnymi etapami jest zapisanie pobranych informacji do bazy danych oraz ich wyświetlenie uŜytkownikowi. Schemat bazy danych, wraz z wykonywanymi na niej operacjami, zostały opisane w rozdziale 3.5.
3.4.4 Pobranie liczby cytowań wielu publikacji
Zaimplementowana zostanie takŜe moŜliwość automatycznego pobrania brakującej
liczby cytowań, dla kaŜdej publikacji znajdującej się na aktualnej stronie tabeli z
rezultatami wyszukiwania w repozytorium. Pierwszym etapem masowego pobierania jest
znalezienie wszystkich prac z widocznej strony, dla których nie ma zapisanej liczby
cytowań w bazie danych. Następnie, dla kaŜdej z nich, wykonywane są operacje
analogiczne do tych, które zostały wykorzystane do pobrania danych pojedynczej
publikacji (rozdział 3.4.3). W tym przypadku celem jest uzyskanie jedynie liczby cytowań,
więc pominięty zostaje etap pobierania listy publikacji cytujących. UŜytkownik będzie
mógł rozpocząć wykonywanie opisanych operacji, za pomocą specjalnie dodanego w tym
celu elementu interfejsu przeglądarki.
31
3.4.5 Ograniczenia wprowadzane przez Google Scholar
Google Scholar niestety nie pozwala na zautomatyzowane i masowe pobieranie danych z ich serwerów. Jeśli wykryte zostanie zbyt duŜo Ŝądań, otrzymanych w krótkim czasie, Google zablokuje usługę dla adresu IP, z którego zostały one wysłane. Początkowo
blokada ta jest tymczasowa i jej zdjęcie następuje po odczekaniu pewnego, stosunkowo
niedługiego czasu lub po wpisaniu kodu CAPTCHA, dostępnego po manualnym wejściu na
stronę. Jednak w przypadku powtarzających się blokad, Google moŜe podjąć decyzję o
permanentnej blokadzie na adres IP. Jest to niewątpliwie uzasadnione podejście, mające na
celu wyeliminowanie programów, które mogą automatycznie wysyłać tysiące Ŝądań w
krótkim czasie, nie tylko pobierając dane, ale takŜe obciąŜając serwery.
Z problemem tym zetknął się twórca rozszerzenia do dodatku Zotero (rozdział 2.5),
które takŜe umoŜliwia pobranie liczby cytowań dla wielu publikacji naraz. Rozwiązanie w
tym przypadku nie zostało jednak opracowane w optymalny sposób. Polega ono na tym, Ŝe
po kaŜdym setnym wysłanym Ŝądaniu, następuje minutowa przerwa przed kolejnym. Wadą
jest to, Ŝe te 100 Ŝądań moŜe zostać wysłane w ciągu kilkunastu sekund, a to z pewnością
spowoduje blokadę usługi.
W tworzonym rozszerzeniu ograniczenie to występuje, przede wszystkim, podczas
automatycznego pobierania liczby cytowań dla wielu publikacji (pobranie danych dla pojedynczej publikacji nie jest automatyczne – wymaga interakcji uŜytkownika). Proponowane rozwiązanie zakłada utworzenie kolejki adresów, pod które mają być wysłane Ŝądania. Po otrzymaniu odpowiedzi na pierwsze z nich, i przeanalizowaniu strony, pobierany
jest kolejny adres z kolejki. Zanim jednak zostanie wysłane odpowiednie Ŝądanie, wymuszane jest pewne losowe opóźnienie. Cykl ten powtarza się aŜ do momentu, w którym kolejka zostanie całkowicie opróŜniona lub gdy wystąpi wcześniej błąd pobierania. Podejście
takie ma na celu zasymulowanie sytuacji, w której Ŝądania te byłyby wysyłane podczas
wyszukiwania wykonywanego manualnie przez uŜytkownika. Nie gwarantuje ono jednak
pełnego wyeliminowania moŜliwości wystąpienia blokady usługi, ale powoduje dosyć skuteczne i duŜe jej opóźnienie. ChociaŜ liczba Ŝądań wysłanych w krótkim czasie moŜe wynieść maksymalnie 20 (taka jest liczba rezultatów wyświetlanych na pojedynczej stronie
tabeli), to przeprowadzone badania wykazały, Ŝe wprowadzenie opisanego obejścia jest
konieczne.
32
Innym zachowaniem, który Google określa jako niepoŜądane, jest szybkie przechodzenie pomiędzy kolejnymi stronami z rezultatami wyszukiwania. W tym przypadku usługa blokowana jest szybciej, niŜ w przypadku opisanym powyŜej. W kontekście tworzonego rozszerzenia, problem ten pojawia się w momencie pobierania listy publikacji cytujących. MoŜe ich być na tyle duŜo, Ŝe zostaną rozłoŜone na wiele stron. Z tego powodu
wprowadzone zostało ograniczenie na liczbę pobranych prac. Będzie ich maksymalnie
100. Liczba ta wynika z tego, Ŝe tyle moŜe zostać wyświetlonych wyników na jednej stronie. Domyślnie jest ich 10, a do uzyskania większej liczby wykorzystywany jest parametr
num, który naleŜy dodać do adresu URL (w tym przypadku będzie to &num=100). Takim
sposobem pobrana będzie tylko pierwsza ze stron, a kolejne zostaną pominięte.
3.5 Baza danych
Wszystkie bazy danych, wykorzystywane zarówno w samej przeglądarce Firefox, jak
i w jej rozszerzeniach, są obsługiwane przez system zarządzania bazą danych o
nazwie SQLite. Biblioteka go implementująca została napisana w języku C i zajmuje
jedynie kilkaset kilobajtów. W przeciwieństwie do innych systemów tego typu, SQLite jest
integralną częścią aplikacji, która go wykorzystuje, a nie osobnym procesem. Obsługuje on
język SQL i, pomimo swoich małych rozmiarów, zaimplementowana zastała większość
standardowych operacji, moŜliwych do wykonania w tym języku. Oprócz przeglądarek,
SQLite znalazł takŜe zastosowanie m.in. w systemach operacyjnych na urządzenia
mobilne, jak Android czy iOS.
Projektowane rozszerzenie wymaga przechowywania następujących danych:
•
Tytuł publikacji;
•
Liczba cytowań publikacji;
•
Data pobrania danych;
•
Zbiór prac, w których znajdują się cytowania.
Utworzone zostaną dwie tabele. W pierwszej z nich znajdą się dane dotyczące poszczególnych publikacji, czyli tytuł, liczba cytowań oraz data pobrania. Druga będzie zawierać prace, które cytują publikacje z pierwszej tabeli. Klucz główny pierwszej tabeli
zostanie uŜyty jako klucz obcy w drugiej. MoŜe wystąpić sytuacja, Ŝe dwie prace mają ten
sam tytuł, ale róŜnych autorów. Z tego powodu, jako wspomniany klucz główny nie zosta-
33
nie uŜyty
yty tytuł publikacji, a odnośnik
odno
do Google Scholar,, zmodyfikowany poprzez wyspecyfikowanie autora, jak przedstawione
przedstawion zostało w rozdziale 3.4.3.
Do tabeli zawierającej publikacje, wprowadzona zostanie takŜe
takŜe kolumna, zawierajązawieraj
ca odnośnik do stronyy wyszukiwania listy prac cytujących.
cytuj cych. Pozwoli ona na uniknięcie
unikni
wysyłania podwójnych Ŝądań,
Ŝądań w sytuacji, gdy wcześniej została juŜ pobrana liczba cytowań,
cytowa a
uŜytkownik chce uzupełnić dane o pozycje ze wspomnianej listy.. Pełna tabela publikacji
została przedstawiona
stawiona na rys. 3.5.
3.5 Tabela publikacji
Tabela prac cytujących
ących została przedstawiona na rys. 3.6.. Oprócz klucza obcego do
tabeli publikacji, pozostałe kolumny zawierają
zawieraj tytuły kolejnych prac i odnośniki
odno
do cyfrowych kopii dokumentów.
3.6 Tabela cytowań
Na potrzeby rozszerzenia, jedyne operacje SQL, które będą wymagane to: INSERT,
I
UPDATE oraz SELECT. Wstawianie będzie
b dzie wykonywane po pobraniu danych nowej pup
blikacji, która nie znajdowała się
si wcześniej w bazie.. Aktualizacja wartości
warto
będzie przeprowadzana jedynie w przypadku, gdy uŜytkownik
u
uŜyje
yje przycisku słuŜącego
słu
do aktualizacji cytowań pojedynczej publikacji, który znajduje się
si wewnątrz otwieranego okna.
okna Uaktualniona
alniona zostanie data oraz ewentualnie liczba cytowań.
cytowa . Pobranie danych z bazy będzie
odbywało się w dwóch przypadkach. Pierwszym z nich jest wejście
wej cie na stronę
stron z repozytorium, a powodem takiego zachowania jest konieczność
konieczno wyświetlenia
wietlenia liczby cytowań
cytowa na
dodanych
nych etykietach. Drugi przypadek występuje
wyst puje w momencie otwarcia wspomnianego
okna, aby mogło ono zostać uzupełnione o pobrane wcześniej dane.. PoniewaŜ
Poniewa raz napisane
34
publikacje nie znikną z sieci, podobnie jak jej cytowania, nie jest wymagana obsługa usuwania rekordów z bazy danych.
Komunikacja z bazą danych odbywa się za pomocą wbudowanych komponentów
XPCOM. Na listingu 3.2 przedstawiony został przykład otwarcia połączenia z bazą danych. Pierwszy komponent ("@mozilla.org/file/directory_service;1")
słuŜy do otwarcia pliku na dysku lokalnym, który przechowuje schemat bazy danych. Argument "ProfD" pozwala na uzyskanie ścieŜki do katalogu, utworzonego dla aktualnie
uŜywanego profilu przeglądarki. Przyjęło się, Ŝeby wszystkie pliki tworzone przez rozszerzenia były umieszczane właśnie tam, a dzięki podaniu takiego argumentu do metody
get(), nie jest wymagane szukanie katalogu na dysku (jego lokalizacja róŜni się, w zaleŜności od systemu operacyjnego). Po wykonaniu metody append() otwarty zostanie
plik o nazwie baza_danych.sqlite, który znajduje się we wspomnianym katalogu profilowym (zostanie on utworzony, jeśli nie istniał wcześniej). Drugi uŜyty komponent
("@mozilla.org/storage/service;1") słuŜy do uzyskania odpowiedniego serwisu, który umoŜliwia otwarcie połączenia z bazą danych, znajdującą się w podanym pliku. Na tak otwartym połączeniu moŜna wykonywać podstawowe operacje, jak utworzenie
tabeli czy wykonanie asynchronicznego zapytania. Asynchroniczność zapobiega moŜliwości zablokowania przeglądarki, w przypadku gdyby wykonanie zapytania trwało długi
czas.
var plik =
Components.classes["@mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties)
.get("ProfD", Components.interfaces.nsIFile);
plik.append("baza_danych.sqlite");
var storageService =
Components.classes["@mozilla.org/storage/service;1"]
.getService(Components.interfaces.mozIStorageService);
var połączenie = storageService.openDatabase(plik);
Listing 3.2 Otwarcie połączenia z bazą danych
35
4 Opis implementacji
Biorąc pod uwagę wszystkie rozwiązania przedstawione w rozdziale 3, zaimplementowane zostało rozszerzenie spełniające postawione wymagania. Rozdział ten opisuje jej
kluczowe elementy, a takŜe napotkane trudności.
Rys. 4.1 Struktura rozszerzenia
Na rys. 4.1 przedstawiona jest struktura plików i katalogów, które zostały stworzone.
Logika rozszerzenia, napisana w języku JavaScript, została podzielona na kilka modułów
(plików źródłowych). KaŜdy z nich zawiera metody specyficzne dla konkretnych obszarów
działania rozszerzenia. Główny skrypt – main.js – zawiera deklarację globalnego obiektu
(nazwanego eitirepo), którego składnikami są zmienne i struktury danych, wykorzystywane w operacjach wykonywanych przez rozszerzenie, oraz metody będące łącznikami
pomiędzy modułami. Znajdują się tutaj takŜe operacje inicjujące składniki rozszerzenia po
otwarciu przeglądarki. Stworzone zostały następujące moduły:
36
•
listeners.js – Skrypt ten definiuje obiekt eitirepo.listener, który zawiera obserwatorów zdarzeń, jakie są powiązane z rozszerzeniem. Przede
wszystkim, wykrywane są kliknięcia na dodaną etykietę, czy przycisk znajdujący się w otwieranym oknie. Oprócz tego obserwowane są takŜe Ŝądania
wysyłane do repozytorium (opisane w rozdziale 4.2).
•
connection.js – Skrypt ten definiuje obiekt eitirepo.connection. Zawiera on metody słuŜące do wysyłania Ŝądań HTTP do serwera Google
Scholar, a takŜe przetwarzające otrzymane odpowiedzi.
•
db.js – Skrypt definiuje obiekt eitirepo.sqlite. Zawiera on metody
słuŜące do otwarcia połączenia z bazą danych oraz wykonywania na niej
wymaganych operacji.
•
ui.js – Skrypt definiuje obiekt eitirepo.ui. Jego głównym zadaniem jest
tworzenie oraz wyświetlanie elementów interfejsu uŜytkownika, czyli np.
dodanie etykiet do tabeli repozytorium.
•
translate.js – Skrypt definiuje obiekt eitirepo.translate. Zawiera on
tłumaczenia tekstów, uŜywanych w wyświetlanych elementach interfejsu
uŜytkownika, na wszystkie obsługiwane języki. (rozdział 4.4)
Na uwagę zasługuje katalog deafults/preferences, który nie został przedstawiony
podczas ogólnego opisu elementów rozszerzenia w rozdziale 2.2. Znajduje się tam skrypt,
który dodaje nowe preferencje do przeglądarki, wraz z ich wartościami domyślnymi. Dodawanie preferencji jest moŜliwe poprzez uŜycie następującej funkcji:
pref("nazwa.preferencji", "wartość domyślna");
4.1 Wprowadzone elementy interfejsu uŜytkownika
4.1.1 Modyfikacja interfejsu przeglądarki
Stworzone rozszerzenie wprowadza kilka modyfikacji w oryginalnym interfejsie
przeglądarki Firefox. Zmiany te zawiera dokument overlay.xul, który jest nakładką na
główne okno przeglądarki. Przede wszystkim, na pasku dodatków (kiedyś nazywanym
paskiem statusu), znajdującym się w dolnej części okna, dodana została ikona (rys. 4.2).
Informuje ona o tym, Ŝe rozszerzenie zostało zainstalowane i aktualnie działa, a takŜe
umoŜliwia uŜytkownikowi korzystanie z jego funkcji. Po kliknięciu na ikonę otwierane jest
37
menu, zawierające dwa elementy. Pierwszy z nich jest domyślnie niedostępny, ale słuŜy do
uruchomienia procesu pobierania liczby cytowań dla wszystkich publikacji ze strony.
Moment, w którym zostaje on udostępniony, został opisany w rozdziale 4.2. Kliknięcie na
drugi element powoduje otwarcie okna, które umoŜliwia zmianę opcji rozszerzenia. Ponadto, do menu „Narzędzia”, z głównego okna przeglądarki, dodany został element o etykiecie „EiTI Repository”, który zawiera podmenu takie samo, jak zostało opisane powyŜej.
Rys. 4.2 Ikona rozszerzenia na pasku dodatków
Okno opcji zostało stworzone przy uŜyciu elementu <dialog> języka XUL i
umieszczone jest w dokumencie options.xul. Jak pokazane zostało na rys. 4.3, uŜytkownik
ma moŜliwość ustawienia dwóch opcji. Pierwsza z nich dotyczy tego, co ma się wydarzyć,
gdy kliknięta zostanie dodana do tabeli repozytorium etykieta i moŜliwe są trzy przedstawione scenariusze. Druga opcja słuŜy do ustawienia adresu, serwera repozytorium. Sposób
jej wykorzystania opisany został w rozdziale 4.2. Obie opcje powiązane są z preferencjami, dodanymi przez rozszerzenie za pomocą skryptu eitirepopref.js. Po kaŜdym uŜyciu
przycisku „Zapisz”, ich wartości zostają odpowiednio zmienione i rozszerzenie od razu
będzie działać według nowych ustawień.
Rys. 4.3 Okno opcji rozszerzenia
38
4.1.2 Modyfikacja strony repozytorium
Rys. 4.4 Fragment zmodyfikowanej tabeli
Na rys. 4.4 przedstawiony został fragment tabeli z rezultatami wyszukiwania, po jej
zmodyfikowaniu przez rozszerzenie. Widoczne są nowo dodane elementy z etykietą
„cytowania(X)”. Liczba w nawiasie jest liczbą cytowań danej publikacji, natomiast znak
zapytania oznacza, Ŝe dane nie były jeszcze pobierane.
Modyfikacja zaczyna się od znalezienia wszystkich odnośników (elementów <a>)
znajdujących się na stronie. Następnie wybierane są tylko te, które prowadzą do strony
Google Scholar, a więc mają odpowiedni adres oraz etykietę „scholar”. Pod kaŜdym z
nich wstawiany jest nowy element <a> (opisany wspomnianą etykietą „cytowania(X)”).
Istnieją takie rezultaty wyszukiwania, dla których nie została zamieszczona w tabeli
wspomniana etykieta „scholar”. W takim przypadku element nie jest dodawany, czyli
takie wiersze tabeli są pomijane. Opisana operacja jest jednak poprzedzona wykonaniem
zapytania do bazy danych, które zwróci listę z liczbą cytowań i datą, dla tych z widocznych publikacji, których dane zostały juŜ pobrane. Dzięki temu moŜliwe jest natychmiastowe ustawienie odpowiedniej liczby w etykiecie dodawanego elementu. W celu usprawnienia późniejszych operacji, kaŜdy z elementów ma ustawianą jedną z dwóch klas:
eitirepo-citations, jeśli cytowania dla danej publikacji zostały juŜ pobrane, oraz
39
eitirepo-no-citations w przeciwnym wypadku. Kliknięcie na wstawiony element powoduje otwarcie okna z większą ilością informacji. Okno to zostało opisane w
rozdziale 4.1.3. Do kaŜdego elementu dodana została podpowiedź typu tooltip, dzięki
czemu, po najechaniu na niego kursorem, pojawi się informacja o dacie pobrania aktualnych danych. (rys. 4.5)
Rys. 4.5 Tooltip zawierający datę pobrania
4.1.3 Okno z listą prac cytujących
Rys. 4.6 Okno otwierane po kliknięciu na etykietę cytowań
40
Na rys. 4.6 przedstawiony został wygląd otwieranego okna, wraz z jego przykładową
zawartością. Zostało ono stworzone przy pomocy elementu języka XUL, o znaczniku
<panel>. Element ten moŜe przyjmować róŜne postacie, w zaleŜności od nadanego mu
typu (wartości atrybutu type). W tym przypadku, typem tym jest arrow, co powoduje
dodanie strzałki wskazującej na element, którego kliknięcie spowodowało otwarcie okna.
Wewnątrz okna znajduje się ramka, do której załadowany został dokument HTML, znajdujący się w pliku popup.html. Okno takie pozostaje otwarte, aŜ do momentu, gdy uŜytkownik kliknie myszką poza jego obszarem.
Po kliknięciu na etykietę, zanim okno zostanie otwarte, następuje zapytanie do bazy
danych, w celu wyszukania informacji o wybranej publikacji. Jeśli zostały one wcześniej
pobrane z serwisu Google Scholar, zapytanie zwróci odpowiednie dane, które będą mogły
zostać od razu wyświetlone uŜytkownikowi. Dane te są zapamiętywane w programie, aŜ do
otwarcia kolejnego okna. Z tego powodu, jeśli uŜytkownik będzie chciał otworzyć okno
dla tej samej publikacji dwa razy pod rząd, nie będzie konieczności wykonywania kolejnego zapytania do bazy.
Jeśli nie ma danych dotyczących wybranej publikacji oraz opcja automatycznego
pobierania została włączona, po otwarciu okna następuje wysłanie odpowiednich Ŝądań
HTTP (rozdział 3.4.3). NiezaleŜnie od tego, czy dane zostały pobrane (z bazy lub serwera),
zawartość okna zostaje odpowiednio uzupełniona. Tabela widoczna na rys. 4.6 zawiera
listę prac, które cytują wybraną publikację. W jej drugiej kolumnie znajdują się odnośniki
do cyfrowych kopii tych dokumentów. Kliknięcie na zawarty w nich tekst powoduje
otwarcie w przeglądarce nowej zakładki, ze stroną spod zadanego adresu. Na rys. 4.7 zaprezentowany został wygląd okna w przypadku, gdy pobrano dane, ale publikacja nie była
ani razu cytowana. MoŜna zauwaŜyć, Ŝe tabela z listą prac jest tworzona dynamicznie i nie
pojawia się, gdy nie ma w niej nic do wyświetlenia. Na rys. 4.8 przedstawiony został z
kolei przykład okna, które zostało otwarte dla publikacji, dla której nie pobierano jeszcze
danych.
41
Rys. 4.7 Okno otwarte dla publikacji bez cytowań
Rys. 4.8 Okno otwarte dla publikacji bez pobranych danych
4.2 Wykrycie repozytorium
Jedną z napotkanych trudności, jakie wystąpiły podczas implementacji rozszerzenia,
było wykrycie wszystkich moŜliwych sytuacji, w których powinna nastąpić modyfikacja
tabeli repozytorium. Są to: wejście na stronę z rezultatami wyszukiwania, przechodzenie
pomiędzy kolejnymi stronami tabeli oraz zmiana zakładki. Najczęściej uŜywanym, w rozszerzeniach, sposobem wykrycia wejścia na daną stronę jest obserwowanie zdarzenia load, który oznacza, Ŝe przeglądarka zakończyła ładowanie dokumentu HTML strony. Po
jego otrzymaniu wystarczy porównać adres strony, której dotyczy, z załoŜonym. Jeśli się
42
zgadzają moŜna wykonać wymagane operacje na wyświetlanym dokumencie. W przypadku tworzonego rozszerzenia, rozwiązanie takie równieŜ mogłoby zostać uŜyte, gdyby nie
to, Ŝe kolejne strony z tabeli wyszukiwania pobierane są z uŜyciem techniki AJAX. Powoduje to, Ŝe po przejściu na inną stronę tabeli, dokument jest jedynie modyfikowany, a nie
ładowany od nowa, w związku z czym przeglądarka nie wysyła zdarzenia load. Konieczne było uŜycie innego rozwiązania.
Dostępne jest kilka metod pozwalających na wykrywanie podobnych sytuacji, jednak
tą, która umoŜliwiła poprawne i łatwe spełnienie wszystkich wymagań, okazało się
obserwowanie odpowiedzi na Ŝądania HTTP, wysyłanych do serwera repozytorium.
Wykorzystany został do tego tzw. Serwis Obserwatorów (ang. Observer Service),
udostępniany w postaci komponentu XPCOM. Pozwala on na dodanie obserwatora, dla
wybranego zdarzenia, którym jest obiekt implementujący metodę observe(),
uruchamianą przy kaŜdym wystąpieniu zdarzenia. Uproszczony fragment kodu,
zawierający implementację obserwatora wykorzystywanego w rozszerzeniu, został
przedstawiony na listingu 4.1. Zdarzenie otrzymania odpowiedzi HTTP ma identyfikator
http-on-examine-response.
var observerService =
Components.classes["@mozilla.org/observer-service;1"]
.getService(Ci.nsIObserverService);
observerService.addObserver(responseObserver,
"http-on-examine-response", false);
responseObserver : {
observe : function(aSubject, aTopic, aData) {
if (aTopic == "http-on-examine-response") {
aSubject.QueryInterface(Ci.nsIHttpChannel);
var url = aSubject.URI.spec;
var reg = new RegExp
(/repo\.pw\.edu\.pl\/resultList.seam/);
if (reg.exec(url) != null) {
//adres zgodny z załoŜonym
var newListener = new ResponseListener();
aSubject.QueryInterface(
Components.interfaces.nsITraceableChannel);
newListener.originalListener =
aSubject.setNewListener(newListener);
}
}
}
}
Listing 4.1 Fragment obserwatora zaimplementowanego w rozszerzeniu
43
Z powodu tego, Ŝe obserwowane są odpowiedzi na kaŜde Ŝądanie wysyłane przez
przeglądarkę, konieczne jest ich filtrowanie, które pozwoli na wydzielenie tylko tych dotyczących repozytorium (obsługa wszystkich odpowiedzi będzie niepotrzebnie obciąŜać
przeglądarkę i spowolni jej działanie). Odbywa się to na zasadzie porównywania adresu,
na które wysłane zostało Ŝądanie, z tym, jaki został zdefiniowany przez uŜytkownika w
opcji dotyczącej adresu serwera repozytorium. Interesująca z punktu widzenia rozszerzenia
jest jedynie strona, która zawiera tabele wynikową wyszukiwania, a jej URL wygląda następująco: repo.pw.edu.pl/resultList.seam. MoŜliwe jest zatem zlikwidowanie konieczności
obsługi nieistotnych Ŝądań wysyłanych do repozytorium, poprzez dodawanie tekstu:
/resultList.seam, do adresu wyspecyfikowanego przez uŜytkownika (w przedstawionym
przykładzie jest to repo.pw.edu.pl).
Niestety, uŜycie tylko przedstawionego obserwatora nie jest wystarczające. Metoda
observe() jest bowiem uruchamiana w momencie, gdy otrzymany zostanie jedynie nagłówek odpowiedzi. Przeglądarka nie otrzymała jeszcze oczekiwanej zawartości dokumentu, więc nie jest moŜliwe jego zmodyfikowanie. PoniewaŜ czas, po jakim cała zawartość
odpowiedzi zostanie odebrana jest niedeterministyczny (szczególnie zaleŜy on od szybkości łącza i czasu odpowiedzi serwera), ustawienie jedynie odpowiedniego opóźnienia nie
wystarczy. Sposobem na ominięcie tego problemu jest uŜycie komponentu XPCOM, który
implementuje interfejs nsITraceableChannel, tak jak zostało to przedstawione na
listingu 4.1, wewnątrz drugiego bloku if. Obiekt klasy ResponseListener, który jest
uŜyty jako argument metody setNewListener(), musi implementować dwa interfejsy: nsIStreamListener oraz nsIRequestObserver. Pierwszy z nich posiada
metodę onDataAvailable(), która jest wywoływana po otrzymaniu kaŜdej paczki z
zawartością, wysłaną przez serwer. Zawartość tę moŜna w tym miejscu zmodyfikować
według potrzeb. Drugi interfejs posiada metody onStartRequest() oraz onStopRequest(), które są uruchamiane odpowiednio przed otrzymaniem pierwszej paczki
oraz po ostatniej. Z punktu widzenia rozszerzenia, istotna jest jedynie metoda onStopRequest(). Oczekiwany dokument będzie w momencie jej uruchomienia juŜ w pełni
dostarczony, więc moŜliwe będzie wywołanie metody odpowiedzialnej za modyfikację
strony repozytorium. Na listingu 4.2 przedstawiony został obiekt ResponseListener.
44
function ResponseListener() {
this.originalListener = null;
}
ResponseListener.prototype = {
onDataAvailable: function(request, context,
inputStream, offset, count) {
this.originalListener.onDataAvailable(request, context,
inputStream, offset, count);
},
onStartRequest: function(request, context) {
this.originalListener.onStartRequest(request, context);
},
onStopRequest: function(request, context, statusCode) {
this.originalListener.onStopRequest(request, context,
statusCode);
//Wywołanie metody, która modyfikuje stronę
},
};
Listing 4.2 UŜycie klasy ResponseListener
Opisana powyŜej metoda pokrywa sytuacje wejścia na stronę z rezultatami
wyszukiwania oraz przechodzenia pomiędzy kolejnymi stronami tabeli. Wykrycie otwarcia
zakładki ze stroną repozytorium było mniej skomplikowanym zadaniem. Wykorzystane
zostało zdarzenie wyboru zakładki – TabSelect, wysyłane przez przeglądarkę. Po jego
odebraniu, adres URL wybranej zakładki jest porównywany z adresem pw.edu.pl. W tym
przypadku
nie
jest
moŜliwe
uŜycie
pełnego
adresu
repozytorium
(repo.pw.edu.pl/searchList.seam), poniewaŜ oczekiwany dokument moŜe znajdować się w
ramce na stronie wydziału, którego URL ma początek elka.pw.edu.pl/. Z tego powodu,
jeśli adres jest zgodny z załoŜonym, konieczne jest sprawdzenie, czy dokument HTML ze
stroną rezultatów wyszukiwania nie znajduje się w ramce i jeśli tak, konieczne jest jego
wydobycie.
Wykrycie powyŜszych sytuacji jest wymagane nie tylko ze względu na potrzebę modyfikacji strony repozytorium. Pozwala to takŜe na odblokowanie elementu menu, który
odpowiada za uruchomienie operacji pobierania liczby cytowań, dla wszystkich publikacji
ze strony. Oprócz tego, wykonana zostanie modyfikacja w interfejsie uŜytkownika. Na
pasku adresu pojawi się ikona, informująca uŜytkownika, Ŝe na obecnie przeglądanej stronie znajdują się publikacje, dla których moŜna pobrać liczbę cytowań (rys. 4.9). W przypadku opuszczenia takiej strony, zostanie ona ukryta. Kliknięcie prawym przyciskiem my-
45
szy na ikonę powoduje otwarcie takiego samego menu kontekstowego, jakie zostało przedstawione w rozdziale 4.1.1.
Rys. 4.9 Modyfikacja paska adresu
4.3 Pobieranie danych
Jak zostało opisane w rozdziałach 3.4.3 oraz 3.4.4, pobieranie danych z serwisu
Google Scholar moŜe być inicjowane na kilka sposobów. Najistotniejszą kwestią, jaka
wymaga przedstawienia jest to, Ŝe nie moŜe wystąpić sytuacja, w której wykonywane są
dwa pobierania naraz. NiezaleŜnie od sytuacji, w której zaczęto pobieranie, do momentu aŜ
się ono nie zakończy, zablokowana zostanie moŜliwość uŜycia odpowiednich przycisków
(w menu oraz oknie), a takŜe wyłączona zostanie opcja automatycznego pobierania po
otwarciu okna. W przypadku pobierania danych pojedynczej publikacji stanie się to na tyle
szybko, Ŝe uŜytkownik nie odczuje tego ograniczenia. Jednak pobieranie liczby cytowań,
dla wszystkich publikacji ze strony, moŜe trwać na tyle długo, Ŝe konieczne jest poinformowanie o tym fakcie. Dokonywane jest to za pomocą zmiany ikon na paskach dodatków
oraz adresu, jak przedstawione zostało na rys. 4.10 oraz 4.11. Pozostaną one takie do momentu, aŜ pobieranie się zakończy, kiedy to ich wygląd powróci do oryginalnego.
Rys. 4.10 Ikona pobierania na pasku adresu
Rys. 4.11 Ikona pobierania na pasku dodatków
NajwaŜniejsze decyzje implementacyjne, podjęte w kontekście pobierania plików:
•
Pobranie automatyczne po otwarciu okna następuje jedynie w przypadku, gdy
dane dla publikacji nie były pobierane wcześniej. W przypadku gdy uŜytkownik wybierze opcję pobrania pełnych danych, a w bazie znajduje się juŜ
sama liczba cytowań, wtedy jest wysyłane tylko jedno Ŝądanie. Pobrana tym
sposobem będzie jedynie lista publikacji cytujących (oczywiście tylko jeśli
liczba cytowań jest większa od zera), co zlikwiduje nadmiarowe Ŝądania. Po46
nadto, pobieranie automatyczne następuje dopiero po otwarciu i uzupełnieniu
okna, które potem jest aktualizowane.
•
Opóźnienie pomiędzy kolejnymi Ŝądaniami, w przypadku pobierania liczby
cytowań, dla kaŜdej publikacji ze strony, będzie generowane dwuetapowo.
Najpierw wylosowane zostaną dolne i górne przedziały, spomiędzy których
losowana będzie ostateczna liczba milisekund. Ostatecznie, dolny przedział
moŜe wahać się, w sekundach, od 1 do 5, natomiast górny od 5 do 15.
•
KaŜde pobranie, niezaleŜnie, czy nowych danych, czy aktualizacja istniejących, kończy się odpowiednim zapisaniem rezultatu do bazy danych.
•
Po pobraniu danych, aktualizowana będzie takŜe liczba cytowań znajdująca
się w etykiecie, dodanej do tabeli repozytorium elementu. W szczególności,
przy pobieraniu masowym, wszystkie znaki zapytania zostaną zamienione na
odpowiednie liczby.
4.3.1 Obsługa błędów pobierania
Podczas pobierania danych z serwisu Google Scholar moŜliwe jest wystąpienie błędu, który objawia się tym, Ŝe kodem odebranej odpowiedzi HTTP nie będzie 200 (co oznacza udane Ŝądanie). Sytuacja taka moŜe wystąpić niezaleŜnie od sposobu pobierania danych, a jej powodem najczęściej jest brak dostępu do sieci lub zablokowanie usługi Google
Scholar dla adresu IP uŜytkownika rozszerzenia. W momencie wystąpienia takiego błędu
konieczne jest odpowiednie poinformowanie o nim uŜytkownika. Przede wszystkim, podobnie jak na czas pobierania, zmieniane są ikony na paskach dodatków oraz adresu. Zostaną one w takiej postaci, aŜ do momentu, gdy uda się poprawnie pobrać dane. Na
rys. 4.12 oraz 4.13 zaprezentowano opisaną zmianę.
Rys. 4.12 Ikona na pasku adresu po błędzie
Rys. 4.13 Ikona na pasku dodatków po błędzie
47
Oprócz tego, w przypadku pobierania liczby cytowań pojedynczej publikacji, czy to
za pomocą przycisku, czy automatycznie, wyświetlona zostanie odpowiednia informacja
wewnątrz otwartego okna, jak jest przedstawione na rys. 4.14. Pobieranie masowe nie jest
powiązane z Ŝadnym oknem, dlatego konieczne było znalezienie innego miejsca, w którym
moŜna wyświetlić widoczną dla uŜytkownika informację o błędzie. UŜyty w tym celu został, wbudowany w przeglądarkę moduł JavaScript, który pozwala na wyświetlenie okna
powiadomień typu „popup”. Pojawia się ono zawsze na lewym końcu paska adresu, dzięki
czemu jest widoczne dla uŜytkownika. Na rys. 4.15 jest przedstawiony jego wygląd.
Rys. 4.14 Powiadomienie o błędzie podczas pobierania pojedynczej liczby cytowań
Rys. 4.15 Powiadomienie o błędzie podczas czasie masowego pobierania
4.4 Obsługa języków
W trakcie pisania tej pracy, repozytorium obsługiwało dwa języki: polski oraz
angielski i takie teŜ są zaimplementowane obecnie w rozszerzeniu. W przypadku
elementów dodanych do interfejsu przeglądarki, wszystkie znajdujące się tam teksty i ich
tłumaczenia obecne są w sekcji locale, w pakiecie chrom rozszerzenia. Dokładnie są to
pliki eitirepo.dtd z katalogów locale/pl-PL oraz locale/en-US i zawierają one odpowiednio
48
polskie oraz angielskie teksty. Wyborem, które mają zostać aktualnie wyświetlone,
zarządza przeglądarka na podstawie ustawionego przez uŜytkownika języka.
Języki pozostałych tekstów, wyświetlanych przez rozszerzenie (np. tych wewnątrz
okna, czy we wstawianych do tabeli elementach), są określane na innej zasadzie. Opierają
się one na języku, w jakim uŜytkownik uŜywa repozytorium. Adres URL repozytorium
zawiera parametr lang, który determinuje ustawiony język (jeśli parametru tego nie ma –
repozytorium jest w języku polskim). Przed wykonaniem modyfikacji strony, parametr ten
jest odczytywany i zapisywany do odpowiedniej zmiennej. Znajduje się ona w obiekcie
eitirepo.translate (obiekt ten zdefiniowany jest w skrypcie translate.js) i nazywa
się lang. Na listingu 4.3 przedstawiony został fragment tego obiektu.
eitirepo.translate = {
lang : "pl",
"pl" : {
"html.title.info" : "Tytuł publikacji:",
"html.date.info" : "Ostatnie pobranie cytowań:"
},
"en" : {
"html.title.info" : "Publication title:",
"html.date.info" : "Last update:"
}
};
Listing 4.3 Fragment obiektu eitirepo.translate
Zmienna ta jest uŜywana do wyboru odpowiedniego obiektu (w tym przypadku są to
"pl" lub "en"), który zawiera tłumaczenia tekstów. Tłumaczenia te występują w formie
identyfikator – tekst. Identyfikator musi być taki sam dla kaŜdego języka, natomiast tekst
się róŜni. Podany fragment kodu zawiera dwie takie pary. W celu dodania obsługi kolejnego języka, naleŜy utworzyć nowy obiekt, np. "es" dla języka hiszpańskiego, który zawiera wszystkie zdefiniowane wcześniej identyfikatory wraz z tłumaczeniami. Przykład uŜycia obiektu eitirepo.translate wygląda następująco:
eitirepo.translate[eitirepo.translate.lang]["html.title.info"]
PowyŜsza instrukcja zwraca tekst „Tytuł publikacji:” lub „Publication title:”, w zaleŜności od ustawionego języka. Wprowadzenie takiego rozwiązanie pozwoliło na zredukowanie liczby wykonywanych operacji oraz objętości kodu. Aktualny język jest ustawiany tylko raz na stronę i nie jest wymagane sprawdzanie warunku przed kaŜdym wyświetla49
nym tekstem. Poza tym, dodanie nowego języka jest łatwe i szybkie. Na rys. 4.16 przedstawiono zrzut ekranu takiego samego okna, jak na rys. 4.7, jednak w tym przypadku z
repozytorium uruchomionym w języku angielskim.
Rys. 4.16 Okno w angielskiej wersji językowej
4.5 Testy
Przeprowadzane testy rozszerzenia miały na celu, przede wszystkim, weryfikację
poprawności działania metod wykonujących postawione wymagania funkcjonalne. Podczas trwania prac, kaŜda z dodanych metod była na bieŜąco testowana. Pozwoliło to na
wyeliminowanie pomniejszych błędów na wczesnym etapie i zapobiegnięciu ich kumulacji, w miarę rozrastania się oprogramowania. Oprócz testów jednostkowych, kaŜda najwaŜniejsza funkcja miała przewidziany własny scenariusz testowania, których pełen zestaw był wykonywany po kaŜdej większej zmianie w rozszerzeniu. Poza opisanymi testami, przeprowadzone zostały takŜe takie, które miały na celu weryfikację spełnienia wymagań niefunkcjonalnych, przede wszystkim wydajnościowych.
4.5.1 Scenariusze testowania
Scenariusz 1
Pierwszy ze scenariuszy zakłada przetestowanie poprawności nastę-
pujących elementów: modyfikacji strony repozytorium, wyświetlenia okna, pobrania danych z uŜyciem przycisku znajdującego się w oknie oraz zapisanie ich do bazy danych.
1. Wejście na stronę repozytorium: repo.pw.edu.pl.
50
2. Przeprowadzenie wyszukiwania, z warunkami, które pozwolą na zwrócenie
przynajmniej dwóch rezultatów.
3. Sprawdzenie, czy odpowiednia komórka w tabeli, dla kaŜdego rezultatu wyszukiwania, została poprawnie zmodyfikowana poprzez wstawienie elementu
z etykietą „cytowania(X)”.
4. Wybranie publikacji, dla której nie została jeszcze pobrana liczba cytowań
(etykieta „cytowania(?)”) i otwarcie dla niej okna poprzez kliknięcie na etykietę.
5. Sprawdzenie poprawności wyświetlanych danych i uŜycie przycisku „Aktualizuj cytowania”.
6. Po pobraniu danych, oraz ich wyświetleniu, manualne wyszukanie
odpowiedniej frazy w serwisie Google Scholar i porównanie otrzymanych
informacji.
7. Pomocnicze kliknięcie na inną etykietę, w celu zresetowania zawartości okna.
8. Powtórzenie przeprowadzonego wyszukiwania w repozytorium. Po uzyskaniu strony z rezultatami, otwarcie okna dla tej samej publikacji, która została
wybrana w punkcie 4.
9. Porównanie wyświetlonych danych, z tymi, które widoczne były w punkcie
6. Jeśli się zgadzają, zapis do bazy danych się powiódł.
Scenariusz 2
Kolejny scenariusz zakłada przetestowanie poprawności ustawienia
oraz realizacji opcji automatycznego pobrania danych pojedynczej publikacji, uruchamianego po kliknięciu na etykietę. W przypadku opcji pobierania pełnych danych zostały
przewidziane dwie sytuacje. Pierwsza zakłada uzyskanie jedynie brakującej listy prac cytujących dla publikacji, która miała juŜ wcześniej pobraną samą liczbę cytowań. Druga natomiast dotyczy zwykłego pobrania pełnych danych.
1. Wejście na stronę repozytorium: repo.pw.edu.pl.
2. Wyszukanie dwóch publikacji, które w serwisie Google Scholar są cytowane
przynajmniej raz, ale dane dla nich nie były dotąd pobierane.
3. Ustawienie opcji pobierania samej liczby cytowań przy otwieraniu okna.
51
4. Otwarcie okna dla pierwszej z publikacji. Weryfikacja poprawności pobranych i wyświetlonych danych.
5. Zmiana opcji na pobranie pełnych danych przy otwieraniu okna.
6. Ponowne otwarcie tego samego okna i weryfikacja poprawności pobranych
danych, wyświetlonych w tabeli.
7. Otwarcie okna dla drugiej publikacji. Weryfikacja poprawności pobranych i
wyświetlonych pełnych danych.
Scenariusz 3
Scenariusz ten zakłada przetestowanie masowego pobierania liczby
cytowań, dla kaŜdej publikacji znajdującej się na aktualne stronie. Sprawdzone zostaną
takŜe: blokowanie moŜliwości rozpoczęcia kolejnego pobierania, zanim nie skończy się
poprzednie, oraz odpowiednia zmiana ikon na paskach dodatków i adresu. Do pełnego
przeprowadzenia testu konieczne jest zainstalowanie dodatku o nazwie Tamper Data, który pozwala na oglądanie Ŝądań wysyłanych przez przeglądarkę. Rozszerzenie moŜe być
pobrane ze strony: https://addons.mozilla.org/pl/firefox/addon/tamper-data/
1. Wejście na stronę repozytorium: repo.pw.edu.pl.
2. Przeprowadzenie wyszukiwania, które zwróci kilka rezultatów, dla których
nie zostały wcześniej pobierane dane (zalecane przynajmniej 5 takich wyników).
3. Uruchomienie rozszerzenia Tamper Data.
4. Rozpoczęcie pobierania masowego.
5. W trakcie pobierania: weryfikacja wyglądu ikon na odpowiednich paskach
oraz próba rozpoczęcia kolejnego pobierania, które nie powinno być dostępne.
6. Po zakończeniu pobierania: weryfikacja poprawności modyfikacji etykiet dodanych elementów oraz wyglądu ikon, które powinny mieć przywrócone
pierwotną postać.
7. Przeanalizowanie przechwyconych Ŝądań przez rozszerzenie Tamper Data.
W szczególności liczbę Ŝądań wysłanych do serwera Google Scholar, która
powinna być zgodna z liczbą publikacji widocznych na stronie repozytorium.
52
8. Ponowne wyszukanie tego samego zestawu publikacji. Pozwoli to na weryfikację poprawności zapisu do bazy danych.
4.5.2 Testy wydajnościowe
Pełne przetestowanie wszystkich postawionych wymagań niefunkcjonalnych, w tym
przede wszystkim wydajności, było moŜliwe dopiero po zaimplementowaniu pełnej funkcjonalności.
Rozszerzenie zostało zainstalowane na trzech róŜnych systemach operacyjnych:
Windows 7 64-bit, Windows XP, Ubuntu 10.04 32-bit, wszystkie z zainstalowaną przeglądarką Firefox w wersji 17.0. Na kaŜdym z nich, scenariusze opisane w rozdziale 4.5.1,
zostały wykonane pomyślnie i nie zostały stwierdzone Ŝadne niepoŜądane zachowania.
W celu przetestowania wydajności rozszerzenia przeprowadzono pomiar zajętego
miejsca w pamięci. Otwarta została ta sama strona repozytorium, najpierw na przeglądarce
bez zainstalowanego rozszerzenia, a następnie z nim. Po kilku próbach, przeglądarka z
zainstalowanym rozszerzeniem zajmowała średnio o 3KB miejsca w pamięci więcej, niŜ
bez niego. Ponadto otwarcie okna z informacjami dotyczącymi publikacji wymagało takŜe
średnio 3KB miejsca w pamięci. Podczas długotrwałego uŜytkowania przeglądarki, z zainstalowanym rozszerzeniem, nie stwierdzono znaczących opóźnień przez to wywołanych.
PoniewaŜ większość operacji jest wykonywanych asynchronicznie, nie blokują one pozostałych zadań przeglądarki.
53
5 Podsumowanie
Oczekiwanym rezultatem praktycznym pracy było stworzenie rozszerzenia do przeglądarki, które pozwoli na zwiększenie funkcjonalności cyfrowego repozytorium dokumentów Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej.
Głównym udoskonaleniem, jakie dodatek ten miał wprowadzać była moŜliwość pobierania
liczby cytowań dla przechowywanych publikacji. Jego odbiorcami będą przede wszystkim
pracownicy naukowi Wydziału. Zdecydowano się na stworzenie rozszerzenia do przeglądarki Mozilla Firefox, ale nie odrzucono moŜliwości stworzenia implementacji równieŜ na
inne dostępne przeglądarki.
W ramach pracy dokonano przeglądu technik dotyczących tworzenia rozszerzeń do
przeglądarki Firefox. Wskazano, przede wszystkim, ich najwaŜniejsze elementy oraz wykorzystywane technologie. NajwaŜniejszymi z nich są JavaScript, XUL oraz XPCOM.
XUL odpowiada za dostarczenie interfejsu uŜytkownika rozszerzenia, natomiast XPCOM
jest zestawem komponentów, pozwalających na wykonywanie operacji, które nie są moŜliwe domyślnie z poziomu języka JavaScript.
W pracy przedstawiono wymagania postawione tworzonemu oprogramowaniu, a
takŜe dokonano ich analizy. Podczas niej rozwiązane zostały najistotniejsze kwestie, pozwalające na poprawne spełnienie postawionych wymagań. Jedną z nich był wybór źródła,
z którego będą pobierane wymagane dane, czyli liczba cytowań publikacji, wraz z listą
prac, w których te cytowania się znajdują. Dokonany został przegląd kilku najpopularniejszych serwisów, które umoŜliwiają wyszukiwanie publikacji oraz liczby ich cytowań. Spośród nich wybrany został serwis Google Scholar. Wybór był podyktowany tym, Ŝe serwis
ten jest darmowy, a takŜe moŜliwe jest łatwe uzyskanie wymaganych danych, jedynie na
podstawie dokumentu HTML. Z drugiej strony, wprowadził on pewne ograniczenie dla
jednego z wymagań. Wymaganie to zakłada moŜliwość automatycznego pobrania danych,
dla kaŜdej publikacji znajdującej się na aktualnej stronie repozytorium, natomiast Google
Scholar nie pozwala na wysyłanie zbyt wielu Ŝądań, w zbyt krótkim czasie, do ich serwerów. Zaproponowano rozwiązanie tego problemu, które wprowadza opóźnienie pomiędzy
kolejnymi pobraniami.
Ostatecznie, w oparciu o przegląd technik tworzenia rozszerzeń oraz analizę wymagań, zaimplementowane zostało rozszerzenie. W niewielkim stopniu modyfikuje ono inter54
fejs repozytorium, dodając elementy HTML do tabeli rezultatów wyszukiwania. Elementy
te umoŜliwiają otwarcie dodatkowego okna, które zawiera bardziej szczegółowe informacje o cytowaniach. Poza tym, spełnione zostały postawione wymagania, takie jak moŜliwość ręcznego i automatycznego pobierania danych, a takŜe obsługa wielu wersji językowych repozytorium.
Stworzone rozszerzenie ma takŜe duŜo moŜliwości dalszego rozwoju. Pierwszą z
nich jest dodanie obsługi innych serwisów, które mogłyby posłuŜyć jako źródło danych.
Wymagałoby to, przede wszystkim, ich dokładnej analizy oraz znalezienia sposobu na
łatwe i szybkie uzyskanie wszystkich potrzebnych danych, a takŜe zaimplementowania
odpowiednich metod, które wykonałyby operacje do tego prowadzące. Konieczne byłoby
takŜe udostępnienie uŜytkownikowi wyboru serwisu, z którego domyślnie miałyby być
pobierane dane. Oprócz tego, niezbędna byłaby modyfikacja bazy danych rozszerzenia,
która pozwoliłaby na identyfikację źródła informacji.
Kolejną moŜliwością rozwoju jest dodanie funkcjonalności, która pozwoli na wysyłanie pobranych danych na serwer repozytorium. W chwili obecnej, wszystkie informacje
dotyczące cytowań są przechowywane w lokalnej bazie danych na dysku i uŜytkownicy
nie mają moŜliwości ich dzielenia między sobą. ZałoŜenie jest takie, Ŝeby wprowadzić
usługę logowania do zewnętrznego serwera i, tylko dla zalogowanych uŜytkowników,
umoŜliwić wspomniane wysyłanie danych. Dzięki temu uŜytkownicy nie będą zmuszeni
pobierać wielokrotnie tych samych danych. W przypadku próby zrealizowania takiego
podejścia, konieczne jest połoŜenie szczególnego nacisku na odpowiednie zabezpieczenie
poufnych danych.
MoŜliwe jest takŜe stworzenie podobnego rozszerzenia, ale przeznaczonego na inne
popularne przeglądarki, w tym przede wszystkim przeglądarkę Google Chrome.
55
6 Bibliografia
[1]
Eugene Garfield. Citation indexes for science. a new dimension in documentation through
association of ideas. Science, 122(3159):1123–1127, 1955.
[2]
J. E. Hirsch. An index to quantify an individual’s scientific research output. Proceedings of
the National Academy of Sciences of the United States of America, 102(46):16569–16572,
Listopad 2005.
[3]
J. E. Hirsch. Does the h index have predictive power? Proceedings of the National
Academy of Sciences, 104(49):19193–19198, Grudzień 2007.
[4]
Michael C. Wendl. H-index: however ranked, citations need context. Nature,
449(7161):403, 2007.
[5]
Christoph Bartneck and Servaas Kokkelmans. Detecting h-index manipulation through
self-citation analysis. Scientometrics, 87(1):85–98, Kwiecień 2011.
[6]
Leo Egghe. Theory and practise of the g-index. Scientometrics, 69(1):131–152,
Kwiecień 2006.
[7]
Dostosowywanie Firefoksa za pomocą dodatków [online]. [dostęp: 15.01.2013] Dostępny
w Internecie:
https://support.mozilla.org/pl/kb/dostosowywanie-firefoksa-za-pomocadodatkow
[8]
Install Manifests [online]. [dostęp: 15.01.2013]
https://developer.mozilla.org/en-US/docs/Install_Manifests
[9]
Rejestracja Chrome [online]. [dostęp: 15.01.2013]
https://developer.mozilla.org/pl/docs/Rejestracja_Chrome
[10]
XPCOM API Reference [online]. [dostęp: 15.01.2013] Dostępny w Internecie:
https://developer.mozilla.org/en-US/docs/XPCOM_API_Reference
[11]
A. W. Harzing i R. Van der Wal. Google Scholar: the democratization of citation analysis,
Ethics in science and environmental politics, t. 8, nr 1, ss. 61–73, 2007.
[12]
Kayvan Kousha and Mike Thelwall. Google scholar citations and google Web-URL
citations: A multi-discipline exploratory analysis. J. Am. Soc. Inf. Sci. Technol.,
58(7):1055–1065, Maj 2007.
[13]
W3C – XMLHttpRequest [online]. [dostęp: 15.01.2013] Dostępny w Internecie:
http://www.w3.org/TR/XMLHttpRequest/
[14]
Mozilla Developer Network [online]. [dostęp: 15.01.2013] Dostępny w Internecie:
https://developer.mozilla.org/en-US/
[15]
XUL School Tutorial [online]. [dostęp: 15.01.2013] Dostępny
https://developer.mozilla.org/en-US/docs/XUL/School_tutorial
56
Dostępny
Dostępny
w
Internecie:
w
Internecie:
w
Internecie: