Kokon Apache

Kokon
Podstawowe dane

Opiekun Reinhard Poetz i in.
deweloper Fundacja oprogramowania Apache
Rok wydania 20 lutego 2006
Aktualna  wersja 2.2.0
( 15 maja 2008 )
Aktualna wersja wstępna 3.0.0-alpha-3
(8 czerwca 2011)
system operacyjny Niezależna od platformy
język programowania Jawa
Kategoria Framework sieciowy
Licencja Licencja Apache
cocoon.apache.org

Cocoon to system publikacji XML firmy Apache Software Foundation . Ta struktura została stworzona, aby zapisywać dane w formacie XML i wyświetlać je w formacie XSL . XHTML , PDF , RTF i wiele innych (patrz poniżej) mogą być używane jako produkty wyjściowe dla danych XML .

„Cocoon to 'Publishing Framework Servlet', który [...] przekształca źródłowy dokument XML na dowolny format docelowy, w zależności od żądającego klienta”.

- Tłumaczenie: cocoon.apache.org

Kod źródłowy Cocoon podlega licencji Apache, a zatem jest oprogramowaniem wolnym .

Powstanie

Cocoon został napisany (zapoczątkowany) przez włoskiego studenta Stefano Mazzocchiego w 1998 roku podczas oglądania filmu science fiction Cocoon , po którym system został nazwany.

wprowadzenie

Koncepcja Cocoon opiera się na nowym podejściu w porównaniu z innymi frameworkami internetowymi. W dokumentach HTML warstwy treści, układu i logiki programowania są zwykle trwale połączone ze sobą, często nawet zakodowane w pliku. Cocoon przyjmuje inny sposób publikowania informacji. Wymienione trzy warstwy są ściśle od siebie oddzielone i muszą być przetwarzane w osobnych plikach. Na początku oznacza to więcej pracy dla programisty podczas tworzenia strony internetowej, ponieważ musi on stworzyć i utrzymywać trzy pliki. Ten dodatkowy wysiłek można wielokrotnie kompensować w trakcie opracowywania dużych projektów, ponieważ poszczególne części logiki lub układu można łatwo wymieniać, zmieniając odpowiedni plik, integrując je z innymi projektami, a tym samym ponownie wykorzystując.

Aby zaimplementować koncepcję oddzielania poszczególnych warstw w Cocoon, wybrano XML, ponieważ XML konsekwentnie spełnia te wymagania. Zarządzanie, które kontroluje każdą część rozwoju, stoi ponad trzema warstwami.

Na przykład w projekcie Cocoon projektant może być odpowiedzialny za arkusz stylów (układ), programista za logikę i redaktor za zawartość pliku XML. Co więcej, Cocoon został opracowany w Javie, dlatego jest niezależny od platformy. Cocoon wspiera również kontrolę przepływu stron (Cocoon Control Flow), wymagania EAI oraz tworzenie portali internetowych. Ponadto bezproblemowo integruje się ze światem J2EE.

funkcjonalność

Technicznie rzecz biorąc, Cocoon jest oparty na technologii serwletów . Aplet to klasa Java, która odbiera i przetwarza żądania klientów do serwerów WWW. W ramach tego przetwarzania generowana jest odpowiedź, która jest następnie przekazywana do serwera WWW. Tomcat z Apache Software Foundation jest referencyjną implementacją tej technologii, która wykorzystuje język programowania Java firmy Sun Microsystems.

Dzięki Cocoon można nie tylko tworzyć dynamiczne aplikacje internetowe, ale także korzystać z nich lokalnie. Apache Lenya to system zarządzania treścią oparty na Cocoon.

Ponadto Cocoon oferuje silnik portalu, za pomocą którego portale mogą tworzyć.

budowa

Cocoon ma całkowicie zorientowany obiektowo model funkcjonalny. To bardzo ułatwia integrację nowych komponentów lub wymianę istniejących. Wszystkie komponenty są oparte na modelu Apache Excalibur , który określa dokładną strukturę każdego komponentu. Możliwe jest opracowanie własnych komponentów, które można zintegrować z istniejącym modelem poprzez dziedziczenie.

Kokon 2

W przypadku Cocoon 2.x programiści postanowili ponownie zaimplementować Cocoon, aby uczyć się na błędach wersji 1.x. Zmieniono architekturę wewnętrzną i koncepcję Cocoon. Dodano elastyczną mapę witryny, za pomocą której instrukcje przetwarzania można wykonywać w dowolnej kolejności. Wydajność również uległa znacznej poprawie - z jednej strony dzięki szybszej technologii buforowania, a dalej dzięki zoptymalizowanemu przetwarzaniu dokumentów XML: Zamiast budować złożone struktury drzewiaste za pomocą parsera DOM , używany jest teraz parser SAX sterowany zdarzeniami .

Dzięki tej ponownej implementacji Cocoon ma teraz dwa filary: Podczas gdy starsze koncepcje nadal istnieją, ponowna implementacja dodała wiele nowych, niezbędnych i pomocnych technik. Ze względu na kompatybilność wsteczną możliwe jest stosowanie zarówno starszych, jak i nowszych technik, a nawet łączenie ich.

Kokon 2.2

Od maja 2008 roku fundamentalnie zmieniona wersja 2.2.0 Apache Cocoon jest oznaczona jako „stabilna”. Podczas gdy poprzednie wersje były oparte na frameworku Apache Avalon, który od tego czasu został wycofany, nowa wersja jest oparta na Spring . Ponadto narzędzie do budowania Ant zostało zastąpione przez Apache Maven .

Podobnie jak jego poprzednicy, Cocoon 2.2 jest bardzo zorientowany na komponenty. Rozwój odbywa się teraz w niezależnych modułach, tzw. Blokach . Ta nowa architektura oferuje znaczące korzyści, na przykład poprzez Rapid Class Reloader , który automatyzuje kompilację kodu źródłowego JAVA, czy możliwość integracji funkcjonalności frameworka Spring. Obsługa (tworzenie bloków, komunikacja między blokami, integracja Eclipse itp.) Również została znacznie ulepszona w porównaniu do swoich poprzedników.

składniki

Cocoon jest implementowany w oparciu o framework Java Spring i może być rozszerzany o własne komponenty Java zgodnie z wymaganiami. Prawdziwa praca Cocoon odbywa się w rurociągach. Potok składa się z maksymalnie siedmiu typów komponentów, z których każdy jest używany do logiki lub przetwarzania.

Mapa strony

Mapa witryny jest głównym tematem każdej aplikacji Cocoon. Mapa witryny to plik XML o nazwie sitemap.xmap. Jest to zawsze w katalogu głównym bieżącego projektu. Podkatalogi projektu mogą zawierać mapę podstrony. Definiuje różne komponenty Cocoon i interakcje klient / serwer w tak zwanych potokach. Zadaniem mapy witryny jest określenie, co się stanie, gdy użytkownik lub system zgłosi określone żądanie, np. B. wywołanie określonej witryny internetowej.

Aby rozpoznać, jakie akcje są wykonywane po określonym żądaniu, mapa witryny ma tak zwane dopasowania .

Matcher

Żądania użytkowników (takie jak adresy URL lub pliki cookie) są testowane pod kątem dopasowania w mapie witryny do momentu znalezienia dopasowania. Odpowiedź wynika wtedy z wykonania zadań należących do dopasowującego. Same dopasowania zawierają sekwencje znaków, które odpowiadają symbolom wieloznacznym lub wyrażeniom regularnym .

Selektor

Selektor ocenia określone informacje z żądania. Nagłówek HTTP jest zwykle przesyłany, gdy żądana jest witryna internetowa. Selektor to rodzaj instrukcji przełącznika.

Dostępnych jest około 8 selektorów, tutaj tylko najważniejsze:

  • BrowserSelector (sprawdzenie używanej przeglądarki)
  • HostSelector (sprawdzenie parametru hosta żądania HTTP)
  • ParameterSelector (sprawdzenie zdefiniowanego parametru w kokonach)
  • HeaderSelector (sprawdzanie zawartości nagłówka żądania HTTP)

rurociąg

Dopasowanie i powiązane z nim zadania są znane jako potok XML . Typowy rurociąg składa się z generatora, po którym może znajdować się jeden lub więcej transformatorów i wreszcie serializator.

Zadania w potoku są przetwarzane seryjnie. Dopasowania są łącznikiem między żądaniem (przez klienta do Cocoon) a kolejnymi operacjami potoku, który ma zostać wykonany.

Poniższy rysunek ilustruje koncepcję potoku, w którym żądanie jest najpierw wysyłane do mapy witryny, następnie wywoływany jest odpowiedni matcher, a zadania są wykonywane jedno po drugim. Wspomniane już kilkakrotnie zadania są wykonywane przez tzw. Komponenty, które są zintegrowane z Cocoon. Komponenty używane w rurociągu to generator, transformator i serializator.

Odpowiedź jest generowana na podstawie żądania przez generator plików , transformator XSLT i serializator HTML . Transfer między komponentami odbywa się za pośrednictwem SAX.

Generatory

Generator jest punktem początkowym komponentu przetwarzającego rurociągu. Zadaniem generatorów jest generowanie ustrukturyzowanych danych, np. B. Dane XML lub zawartość bazy danych do konwersji na strumień SAX . To jest następnie przekazywane do transformatora. Na rurociąg może być tylko jeden generator.

Transformatory / transformatory

Transformatory konwertują elementy XML generowane przez generator. Na rurociąg może być wiele opcjonalnych transformatorów. Każdy transformator często obsługuje tylko określone elementy strumienia SAX. W celu utworzenia dokumentu z zawartością i układem można uruchomić kilka transformatorów jeden po drugim. Możliwy jest również rurociąg bez transformatorów. Transformator jest używany zwłaszcza w przypadku witryn internetowych zawierających treści wielojęzyczne (internacjonalizacja). Etap transformacji jest często wykonywany za pomocą arkusza stylów XSLT.

Serializator

Serializator przekształca dane wyjściowe transformatora, strumień SAX, na dokument docelowy, w którym można następnie przedstawić zawartość. Dane wyjściowe mają postać strumienia ( binarnego lub znakowego) i są wysyłane jako odpowiedź. Zwykle potok kończy się serializatorem.

Czytelnik

Czytnik nadaje się do bardzo prostych potoków, ponieważ pliki można zwrócić klientowi bez dalszego przetwarzania. Jest to przydatne głównie w przypadku plików innych niż XML w witrynie Cocoon.

Cocoon zawiera już dwóch czytników:

  • ResourceReader (do odczytu danych binarnych)
  • JSPReader (do odczytu danych wyjściowych ze stron JSP )

Akcja

Akcja służy do kontrolowania procesów w witrynie. Dynamiczne środowiska wykonawcze są modyfikowane lub operacje są wykonywane na serwerze. Akcja nie generuje żadnych wyświetlanych danych, ale steruje procesem w potoku.

Możliwe formaty wyjściowe

XSP

Powszechną możliwością, już wykorzystywaną w Cocoon 1.x, do tworzenia aplikacji Cocoon jest koncepcja eXtensible Server Pages (XSP). Strona serwera eXtensible to normalny i prawidłowy dokument XML. Zawiera i. re. Zwykle zawartość statyczna lub określone funkcje, które odczytują zawartość dynamiczną ze źródła danych (baza danych, tabela skrótów, plik). W przeciwieństwie do zwykłych stron JavaServer , plik XSP nie zwraca dokumentu HTML, ale dokument XML, który dostarcza zawartość do dalszych przekształceń. Dokument XSP jest przekazywany bezpośrednio do generatora, który przekształca go w stronę serwera. Funkcje zawarte w dokumencie XSP są konwertowane na kod Java. Oprócz opisanych już opcji strona XSP zawiera opcjonalny komponent logiczny. Często zawiera JavaScript (teoretycznie możliwe są inne języki programowania). Komponent logiczny jest zintegrowany bezpośrednio z dokumentem XSP i ma za zadanie sprawdzanie lub dalsze przetwarzanie parametrów przesyłanych przez żądanie POST. Wszystkie opcje są dostępne w JavaScript. Jeśli komponent logiki jest zintegrowany z dokumentem XSP, ścisłe oddzielenie logiki, układu i treści zostaje utracone. Ten problem można rozwiązać za pomocą tak zwanych arkuszy logicznych; jest to jednak przydatne tylko wtedy, gdy jest używane w dużych projektach. Kolejnym komponentem używanym razem z XSP jest eXtensible Transformer Language (XSLT). Ma to za zadanie dalsze przetwarzanie danych XML generowanych przez generator. Do tego celu służą wspomniane już transformatory. Aby sterować sekwencją generatora i transformatora, należy dostosować plik mapy witryny. W tym miejscu na pierwszy plan wysuwają się prawdziwe mocne strony Cocoon, ponieważ bardzo przejrzyste rozwiązanie można zbudować poprzez oddzielenie logiki i układu, w którym niektóre elementy można w dowolnym momencie zastąpić innymi. Na przykład możliwe jest przekazanie różnych plików XSP do generatora potoku, który zmienia zawartość strony internetowej, ale nie układ.

Kontrola przepływu

Wprowadzając koncepcję kontroli przepływu (przepływu sterowania), programista Cocoon ma opcje, które wcześniej mogły być używane tylko w aplikacji lokalnej. Tradycyjnie aplikacje internetowe działają za pośrednictwem bezstanowego protokołu HTTP, co oznacza, że ​​na każde żądanie generowana jest szybka odpowiedź bez zapisywania stanu aplikacji internetowej lub, jeśli żądanie zostanie wysłane ponownie, przepływ programu jest kontynuowany w tym samym punkcie. Podjęto próbę obejścia tego faktu za pomocą serwletów za pomocą unikalnych identyfikatorów sesji w plikach cookie i przepisywaniu adresów URL. Jednak kod programu jest wielokrotnie uruchamiany od początku i rozgałęziony na różne funkcje na podstawie identyfikatorów sesji. Może to szybko stać się zagmatwane i skomplikowane, szczególnie w przypadku większych aplikacji. Podczas pracy z formularzami i zapisanymi w nich wartościami pojawiają się problemy, zwłaszcza gdy użytkownik próbuje wrócić do jednej lub kilku stron. Wartości tam wprowadzone (przesłane za pomocą POST lub GET) często nie mogą być już ładowane. Aby deweloper mógł przede wszystkim zadbać o swoją aplikację, koncepcja kontynuacji w połączeniu z FlowScript została wprowadzona wraz z Cocoon 2.1.

FlowScript

FlowScript jest oparty na języku JavaScript, który jest szeroko stosowany w Internecie . Ponieważ jego głównym celem jest kontrolowanie procesu aplikacji, a nie integracja logiki biznesowej z aplikacją Cocoon, ograniczenia w porównaniu z Javą nie stanowią już problemu. Jeśli wymagane są złożone procesy i modele, można je zaimportować do JavaScript w postaci klas Java.

Kontynuacje

Częstym problemem w sieci jest to, że wpisy na stronie internetowej znikają bez śladu po ponownym załadowaniu tej strony. W Cocoon problem ten został całkowicie rozwiązany dzięki koncepcji kontynuacji. Kontynuacja jest tworzona w FlowScript. Odbywa się to automatycznie przez wywołanie funkcji cocoon.sendPageAndWait (). Zadaniem obiektu kontynuacji jest przechowywanie aktualnego stanu programu, w tym programu Counter (miejsce w kodzie FlowScript), wszystkich zmiennych lokalnych oraz danych wejściowych użytkownika i stosu. Po utworzeniu obiekt kontynuacji automatycznie otrzymuje unikalny identyfikator. Po utworzeniu kontynuacji jest ona przechowywana w globalnej tablicy skrótów i w razie potrzeby może zostać ponownie załadowana. W tym momencie obiekt kontynuacji jest nadal pusty. Po zapisaniu w tabeli skrótów żądana witryna jest wysyłana do użytkownika. Po wykonaniu polecenia cocoon.sendPageAndWait (), FlowScript zatrzymuje się i czeka na dane wejściowe od użytkownika. Dopiero wtedy FlowScript będzie kontynuowany. Po dokonaniu przez użytkownika wpisów - na przykład w formularzu - wysyła wprowadzone dane i żąda aktualnego obiektu kontynuacji zapisanego w tablicy hash. Zapisuje to wartości wprowadzone przez użytkownika w formularzu internetowym. Dopiero teraz obiekt kontynuacji został w pełni przetworzony i można go w dowolnym momencie ponownie załadować wartościami wprowadzonymi przez użytkownika.

Korzystanie z kontynuacji ma sens tylko wtedy, gdy istnieje rzeczywista interakcja z użytkownikiem.

Poniższy schemat blokowy na rysunku podsumowuje pełną sekwencję kontynuacji we wszystkich komponentach sterowania przepływem.

CocoonContinuation.png

Formy Kokonu (Woody)

Zdecydowanie najpotężniejszy framework formularzy dostępny obecnie w Cocoon nazywa się Cocoon Forms (cForms). Oferuje różnorodne opcje, np. B. Sprawdzanie formularzy, tworzenie wyskakujących okienek i prosta integracja wizualnych elementów graficznych. Formy są obecnie w fazie rozwoju, więc możliwe jest, że niektóre elementy ulegną zmianie. Na przykład Forms został opracowany pod nazwą kodową Woody do wersji Cocoon 2.1.4. Po przejściu do Cocoon w wersji 2.1.5 nazwa, a tym samym wszystkie nazwy i ścieżki bibliotek zostały zmienione. Formularze staną się oficjalnymi standardowymi ramami przetwarzania formularzy.

Struktura form kokonu

Koncepcja Formularzy, podobnie jak prawie wszystko w Cocoon, oddziela zawartość od logiki i układu. Z tego powodu formularz utworzony za pomocą Formularzy składa się z dwóch plików:

  • Definicje kształtów
  • Szablony formularzy

Definicje formularzy opisują poszczególne elementy wymagane w formularzu. Plik definicji formularza nie zawiera żadnych danych prezentacji. Dzięki temu można go ponownie wykorzystać razem z dowolną liczbą plików prezentacji. Elementy w pliku definicji kształtów nazywane są widgetami. Deweloper ma do dyspozycji dużą liczbę widżetów, na przykład przyciski, pola edycji lub pola kombi. Każdemu z tych widżetów można nadać indywidualny wygląd, zachowanie, a nawet funkcje. Aby widżety działały w określony sposób, istnieją bardzo złożone możliwości, począwszy od określenia oznaczenia i opisu obiektu, poprzez deklarację prostych typów danych, które widżet może zaakceptować, aż po wykonanie kodu JavaScript, który jest wyzwalany przez określone predefiniowane zdarzenia w Zostaje uruchomiony widget.

Zasadniczo szablony formularzy to pliki transformacji XSL. Zawierają logikę prezentacji i wiążą poszczególne widgety. Nie wszystkie widżety pliku definicji muszą być zintegrowane. Ponadto szablon kształtu definiuje pewne właściwości, takie jak rozmiar i kolor każdego widżetu.

Przetwarzanie formularzy

Aby stworzyć stronę internetową z formularzami, należy użyć specjalnych transformatorów formularzy i generatora formularzy. Dodatkowo cała koncepcja musi być kontrolowana przez FlowScript.

linki internetowe

Indywidualne dowody

  1. projects.apache.org . (dostęp 8 kwietnia 2020).
  2. cocoon.apache.org . (dostęp 11 marca 2020).
  3. ^ Raport zmian Cocoon 3.0