Publikowanie

Po skompilowaniu stron statycznych i wysłaniu ich do folderu "static" serwisu trzeba — aby je uaktywnić — opublikować lub ponownie opublikować serwis. Analogicznie, aby przywrócić funkcjonowanie serwisu z nieskompilowanymi stronami, trzeba z niego usunąć pliki statyczne, po czym go opublikować lub ponownie opublikować.

Podczas publikowania następuje przygotowanie stron statycznych (które zostały wysłane) do dostarczania. Ponieważ pliki te są kopiowane w trakcie procesu publikowania, wydajność operacji publikowania może się pogorszyć proporcjonalnie do liczby plików.

Operacja publikowania przyjmuje bieżący zestaw plików statycznych i udostępnia je do dostarczania. Pliki te mogą (lecz nie muszą) być zsynchronizowane ze zmianami, które nastąpiły w serwisie dynamicznym, i mogą (lecz nie muszą) odzwierciedlać serwis dynamiczny. Aktualizacja kolekcji plików statycznych w odpowiednim czasie jest zadaniem twórcy serwisu.

Dostarczanie serwisu statycznego — kolejność

Jeśli z serwisem są powiązane pliki statyczne, są one dostarczane dla odpowiednich adresów URL przychodzących do serwera. Jeśli przychodzący URL nie odpowiada plikowi statycznemu, to dla żądania jest zwracany plik controller.html serwisu. Jest to zgodne z istniejącym dynamicznym modelem dostarczania serwisu.

Przez serwisy Oracle Content Management mogą być także — za pomocą powiązanego pliku JSON — definiowane przekierowania 301 i 302. Jeśli przekierowania zostaną zdefiniowane, to będą mieć pierwszeństwo przed plikami statycznymi. Jeśli URL jest zgodny jednocześnie z regułą przekierowania i plikiem statycznym, to z serwera zostanie dostarczone przekierowanie.

Ocena adresu URL przy dostarczaniu serwisu jest dokonywana w następujący sposób:

  1. Czy URL jest zgodny ze skonfigurowanym przekierowaniem?

    Jeśli tak, jest wydawana odpowiedź przekierowania.

  2. Czy URL odpowiada plikowi statycznemu?

    Jeśli dla serwisu został skonfigurowana lista mobilnych agentów statycznych użytkownika i żądanie przychodzi z przeglądarki uwzględnionej na tej liście, jest dostarczany mobilny plik statyczny.

  3. W przeciwnym razie jest dostarczany plik controller.html serwisu dynamicznego.

Uwaga:

Jeśli mobilne pliki statyczne są powiązane z serwisem i klient do dostarczania używa sieci CDN, to CDN (zazwyczaj Akamai) trzeba skonfigurować tak, aby żądania z przeglądarek mobilnych były przechowywane w pamięci podręcznej osobno od standardowych żądań z przeglądarek typu Desktop.

Jeśli CDN nie zostanie skonfigurowana z osobnym buforowaniem żądań mobilnych i standardowych, to przeglądarki mobilne mogą otrzymywać odpowiedzi standardowe, a przeglądarki typu Desktop — odpowiedzi przeznaczone dla przeglądarek mobilnych.

Buforowanie nagłówków

Nagłówki HTTP, zawarte w odpowiedziach z serwerów internetowych, pomagają ustalić sposób przechowywania stron w pamięci w podręcznej. Strony statyczne są także dostarczane z odpowiednimi nagłówkami, ułatwiającymi buforowanie przez przeglądarki.

W przypadku zabezpieczonych serwisów w odpowiedziach będą wysyłane następujące nagłówki:

  • Cache-Control: no-store
  • Pragma: no-cache

W przypadku standardowych, niezabezpieczonych serwisów będą wysyłane następujące nagłówki:

  • Cache-Control: max-age=300
  • Edge-Control: !no-store,max-age=2592000,downstream-ttl=1800

    Nagłówek Edge-Control pomaga określić buforowanie w sieci CDN.

Jeśli w jednym z tych dwóch obszarów nagłówki zostały dostosowane, odpowiedź będzie zawierać nie standardowe nagłówki (tu wymienione), ale nagłówki dostosowane.

Odpowiedzi te można kontrolować na poziomie dzierżawy lub serwisu.

Strony szczegółów

Strony szczegółów, dostępne w serwisach Oracle Content Management, umożliwiają pokazywanie informacji dotyczących elementów zawartości.

Ta sama strona szczegółów może być używana do obsługi wielu adresów URL. Każdy z tych adresów URL będzie wyświetlał tę samą strukturę strony, lecz będzie pokazywać zawartość związaną z elementami zawartości, których wartości opisowe to odpowiednio item1.html, item2.html i item3.html. W takiej sytuacji kompilator szablonu cec mógłby utworzyć cztery pliki:

  • /detail/item1.html
  • /detail/item2.html
  • /detail/item3.html
  • /detail.html

Finalny plik umożliwia wyświetlanie (w serwisie internetowym) nowo opublikowanego materiału bez konieczności ponownej kompilacji i ponownego publikowania serwisu. W tym przykładzie element zawartości z wartością opisową item4.html jest publikowany po przełączeniu serwisu do trybu online. Statyczna strona /detail.html umożliwia dynamiczne wyświetlanie nowego elementu w serwisie. URL /detail/item4.html dostarczy stronę detail.html, lecz będzie na niej pokazywana zawartość związana z elementem zawartości item4.html.

Strona detail.html do wyświetlania zawartości jest generowana przez kompilator cec. Z tego powodu względne adresy URL, zawarte w skompilowanej stronie detail.html, będą mieć dodatkowe segmenty nadrzędne (../). A zatem strona detail.html, jeśli wystąpi do niej bezpośrednie odwołanie, nie zostanie wyświetlona poprawnie. Dlatego nie należy odwoływać się do strony detail.html ani dodawać jej do nawigacji po stronach.