mozilla
Wyniki wyszukiwania

    Zasoby offline w Firefoksie

    UWAGA: Tłumaczenie tej strony nie zostało zakończone.
    Może być ona niekompletna lub wymagać korekty.
    Chcesz pomóc? | Dokończ tłumaczenie | Sprawdź ortografię | Więcej takich stron+.

    Firefox 3.5 wspiera standard HTML 5 umożliwiający zbieranie podręcznej pamięci zasobów internetowych offline. Dzieje się tak dzięki pamięci podręcznej aplikacji (pochodzącej z manifestu zasobów dostarczonego przez przeglądarkę internetową).

    Uwaga dotycząca Firefoksa 3

    Pewne części standardu HTML 5 były wspierane przez Firefox 3. Jednkaże, od czasu publikacji Firefox 3, standard zmienił się, dlatego też na tej stronie nie uwzględniliśmy współpracy z tą wersją przeglądarki.

    Terminologia

    W tej sekcji zostało zdefiniowane kilka terminów, które ułatwią zrozumienie dokumentacji.

    manifest pamięci podręcznej
    Plik opisujący zasoby, które powinny być zachowane do użytku w trybie offline.
    ID klienta
    ID klienta używane przez interfejs nsICacheService podczas zarządzania pamięcią podręczną aplikacji. Jest to nieprzezroczysty łańcuch znaków, tworzony podczas powstawania pamięci podręcznej nowej aplikacji.
    grupa pamięci podręcznej
    Zestaw różnych wersji dla tego samego manifestu pamięci podręcznej.
    ID grupy
    URI pliku manifestu pamięci podręcznej. Wszystkie pamięci podręczne współdzielące tą samą pamięć, są w tej samej grupie pamięci podręcznej.

    Pamięć podręczna aplikacji

    Wszystkie manifesty zasobów aplikacji internetowych posiadają własną pamięć podręczną aplikacji. Od czasu gdy programy zaczynają współdzielić zasoby (mogą także posiadać takie same manifesty URI), pamięć podręczna aplikacji oddziela kopie wszystkich dzielonych zasobów. Wersje pamięci podręcznych są zapisywane - za każdym razem, gdy dana strona jest odwiedzana online, aplikacji dołącza nową wersję do pamięci podręcznej. Powstała wersja jest używana przy kolejnej wizycie na stronie.

    Sposób działania pamięci podręcznej

    Pamięć podręczna aplikacji modyfikuje proces wczytywania dokumentu. Elementy z pamięci podręcznej są wykorzystywane bez łączenia się z internetem (inaczej niż w przypadku aktualizacji kopii aplikacji internetowej w pamięci podręcznej - przebiega to w tle i nie ma dużego wpływu na szybkość).

    Niektóre elementy pamięci podręcznej mogą być nieaktualne. Gdy manifest został usunięty z sewera, Firefox usuwa wszystkie składniki pamięci podręcznej używające tego manifestu, po czym wysyła "przestarzałe" zdarzenie do obiektu pamięci podręcznej aplikacji. Następnie, status pamięci podręcznej zyskuje wartość OBSOLETE.

    Przykład działania

    This section offers an example of the work flow of how loading a page works with the cache.  If you're an end user of the caching mechanism, you don't really need to know this, but it's useful if you're developing Firefox or embedding Gecko.

    Let's assume you have a cache manifest located at http://www.foo.com/cache.manifest, which includes two resources: test.html and test.png.  Loading test.html results in the following steps being taken:

    The HTTP channel calls the nsIApplicationCacheService method nsIApplicationCacheService.chooseApplicationCache() to select the appropriate group ID for the requested resource:

    appCache = nsIApplicationCacheService::ChooseApplicationCache("http://www.foo.com/test.html");
    

    This returns the most recent application cache in the group identified by group ID "http://www.foo.com/cache.manifest".  Then, the HTTP channel does something similar to the following:

    cacheSession = nsICacheSerivce::CreateSession(appCache.clientID, STORAGE_OFFLINE, true);
    cacheEntry = cacheSession.openCacheEntry("http://www.foo.com/test.html");
    

    This creates a cache session and opens the requested resource from within the cache.  From this point on, it loads the data from cacheEntry, but without validation.

    When test.html is loading, the docshell tells sub-loads to use the same application cache that was found by the call to chooseApplicationCache(), so that any resources loaded by test.html will also be loaded from the same cache.

    Pamięć podręczna aplikacji

    Każda pamięć podręczna aplikacji posiada status, który definiuje aktualny stan pamięci. Pamięci, które wspóldzielą ten sam manifest URI, współdzielą także ten sam status. Rodzaje statusów:

    UNCACHED
    Specjalny znacznik oznaczający, że obiekt pamięci podręcznej nie jest w pełni zainicjowany.
    IDLE
    Pamięć podręczna nie jest w trakcie procedury aktualizacji.
    CHECKING
    Manifest sprawdza bądź pobiera aktualizacje.
    DOWNLOADING
    Zasoby są pobierane, towarzyszy temu dodanie do pamięci podręćznej i zmiana manifestu zasobu.
    UPDATEREADY
    Dostępna jest nowa wersja podręcznej pamięci. Odebrano zdarzenie updateready, które jest wywoływane nawet gdy pojawi się zdarzenie cached podczas gdy aktualizacja została pobrana, lecz jeszcze nie zaaktywowana metodą swapCache().
    OBSOLETE
    Grupa pamięci podręcznej jest nieaktualna.

    Zasoby w pamięci podręcznej

    Pamięć podręczna zawsze dołącza najmniejszy zasób, identyfikowany przez URI. Wszystkie zasoby dzielą się na poniższe kategorie:

    Główne elementy
    These are resources added to the cache because a browsing context visited by the user included a document that indicated that it was in this cache using its manifest attribute.
    Manifest
    This is the resource manifest itself, loaded from the URI specified in an implicit entry's html element's manifest attribute. The manifest is downloaded and processed during the application cache update process. Implicit entries must have the same scheme, host, and port as the manifest.
    Lista elementów
    These are resources listed in the cache's manifest.
    Fallback entries
    These are resources that were listed in the cache's manifest as fallback entries.
    Uwaga: Zasoby mogą być oznaczone wieloma kategoriami, a także same mogą być wieloma elementami. Na przykład, element może być zarówno listą jak i fallback entry.

    Główne elementy

    Są to wszelkie pliki HTML zawierające atrybut manifestu wewnątrz elementu <html>. Przykładowo, załóżmy, że mamy plik HTML http://www.foo.bar/entry.html, który wygląda następująco:

    <html manifest="foo.manifest">
    <h1>Entry</h1>
    </html>
    

    Jeśli entry.html nie jest dołączony do manifestu, odwiedzenie strony entry.html spowoduje dodanie pliku entry.html do pamięci podręcznej jako główny element.

    Fallback entries

    Fallback entries are used when an attempt to load a resource fails.  For example, imagine that there is a cache manifest located at http://www.foo.bar/test.manifest, with the following contents:

    CACHE MANIFEST
    FALLBACK:
    foo/bar/ foo.html
    

    Any request to http://www.foo.bar/foo/bar/ or its subdirectories and their contents will cause a network request to attempt to load the requested resource.  If the attempt fails, either due to a network failure or a server error of some kind, the contents of the file foo.html are loaded instead.

    Biała lista online

    The online whitelist may contain zero or more URIs of resources that the web application will need to access off the server rather than the offline cache. This lets the browser's security model protect the user from potential security breaches by limiting access only to approved resources.

    Uwaga: Biała lista online jest ignorowana w wersjach Firefox wcześniejszych niż 3.1.

    This lets you ensure that, for example, scripts and other code is loaded and executed from the server instead of the cache:

    CACHE MANIFEST
    NETWORK:
    /api
    

    This ensures that requests to load resources contained in the http://www.foo.bar/api/ subtree will always go to the network without attempting to access them from the cache.

    Manifest pamięci podręcznej

    Cache manifest files must be served with the text/cache-manifest MIME type, and all resources served using this MIME type must follow the syntax for an application cache manifest, as defined here. Cache manifests are UTF-8 format text files and may, optionally, include a BOM character. Newlines may be represented by line feed (U+000A), carriage return (U+000D), or carriage return and line feed both.

    The first line of the cache manifest must consist of the string "CACHE MANIFEST" (with a single U+0020 space between the two words), followed by zero or more space or tab characters. Any other text on the line will be ignored.

    The remainder of the cache manifest must be comprised of zero or more of the following lines:

    Pusta linia
    Możesz użyć pustej linii zawierającej zero bądź tzw. "białe znaki" (spacje, tabulatory).
    Komentarz
    Comments consist of zero or more tabs or spaces followed by a single "#" character, followed by zero or more characters of comment text. Comments may only be used on their own lines, and cannot be appended to other lines.
    Nagłówek sekcji
    Section headers specify which section of the cache manifest is being manipulated. There are three possible section headers:
    Sekcja nagłówkowa Opis
    CACHE: Zmienia na sekcję list. To jest domyślna sekcja.
    FALLBACK: Switches to the fallback section.

    Uwaga dotycząca Firefoksa 3.1

    The fallback section is ignored by versions of Firefox prior to 3.1.

    NETWORK: Zmienia na sekcję białą listę online.

    Uwaga dotycząca Firefoksa 3.1

    Biała lista online jest ignorowana w wersjach Firefox wcześniejszych od 3.1.

    Linia nagłówka sekcji może zawierać białe znaki, ale musi także posiadać dwukropek w nazwie sekcji.
    Dane dla bieżącej sekcji
    The format of data lines varies from section to section. In the explicit section, each line is a valid URI or IRI reference to a resource to cache. Whitespace is allowed before and after the URI or IRI on each line.

    Cache manifests may switch back and forth from section to section at will (so each section header can be used more than once), and sections are allowed to be empty.

    Uwaga: Relative URIs are relative to the cache manifest's URI, not to the URI of the document referencing the manifest.

    Przykład manifestu pamięci podręcznej

    Przykład dla wymyślonej strony internetowej foo.com.

    CACHE MANIFEST
    # v1
    # To jest komentarz.
    http://www.foo.com/index.html
    http://www.foo.com/header.png
    http://www.foo.com/blah/blah
    

    In this example, there is no section header, so all data lines are assumed to be in the explicit section.

    The "v1" comment is there for a good reason. Because the cache is only updated when the manifest changes, if you change the resources (for example, updating the header.png image with new content), you need to change the manifest file in order to let the browser know that it needs to refresh the cache. You can do this by any tweak to the manifest, but having a version number is a good way to do it.

    Specyfikacja manifestu pamięci podręcznej

    Aby poinformować Firefoksa o używaniu pamięci podręcznej offline dla danej strony internetowej, strona ta musi posiadać atrybut manifest wewnątrz znaczników html:

    <html manifest="http://www.foo.com/cache-manifest">
      ...
    </html>
    

    Procedura aktualizacji

    1. When Firefox visits a document that includes a manifest attribute, it sends a checking event to the window.applicationCache object, then fetches the manifest file, following the appropriate HTTP caching rules. If the currently-cached copy of the manifest is up-to-date, the noupdate event is sent to the applicationCache, and the update process is complete.
    2. If the manifest file hasn't changed since the last update check, again, the noupdate event is sent to the applicationCache, and the update process is complete. Again, this is why if you change the resources, you need to change the manifest file so Firefox knows it needs to re-cache the resources.
    3. If the manifest file has changed, all files in the manifest -- as well as those added to the cache by calling applicationCache.add() -- are fetched into a temporary cache, following the appropriate HTTP caching rules. For each file fetched into the cache, a progress event is sent to the applicationCache object. If any errors occur, an error event is sent, and the update halts.
    4. Once all the files have been successfully retrieved, they are moved into the real offline cache atomically, and a cached event is sent to the applicationCache object.

    Zobacz również


     

    Autorzy i etykiety dokumentu

    Contributors to this page: Bedi, Mgjbot, Witia, zarat, teoli, Gryzzly92
    Ostatnia aktualizacja: teoli,