XML til data og konfiguration
Der findes utallige teknologier rettet imod publicering på internettet, og endnu flere pakkeløsninger og applikationer. Langt de fleste af disse applikationer benytter det samme grundlæggende koncept.
Den publicerede tekst deles op i en række elementer som overskrift, brødtekst med videre, som gemmes i en database. Applikationens rolle er så at stykke websider sammen af de forskellige dele, ud fra en skabelon. Som regel er applikationen desuden udstyret med et lag til bruger- og rolleadministration.
Set i et større perspektiv er sådan en løsning uøkonomisk, fordi informationerne indkapsles i en bestemt datamodel, som ikke har nogen fleksibilitet. Derudover er der tale om et kort informationsflow, hvor kildeteksterne skal redigeres og indsættes manuelt, og når slutproduktet, en webside, er genereret, kan der egentlig ikke gøres så meget mere med materialet.
Problemet med denne type systemer er altså, at de kræver mange ressourcer, og resultatet kan ikke genbruges. Yderligere er datastrukturen i systemet fastlåst, og det er som regel ikke så nemt at ændre på datamodellen. Det betyder også, at man kan regne med vanskeligheder, hvis eller når systemets data skal migreres.
Her kommer XML ind i billedet. Den fundamentalt smarte ting ved XML er, at formatet giver mulighed for at gøre data selvbeskrivende. XML giver uafhængighed af dataformater, og giver væsentligt højere fleksibilitet i forbindelse med datamodellen.
Disse forhold gør også, at XML ikke er kontekst-afhængig. Data fungerer - i teorien - lige så godt i den ene applikation som i den anden.
Cocoon er et Java-baseret framework, som i grundlæggende grad bygger på XML. Cocoon er udformet som en webapplikation som kan benyttes i alle nyere servlet-containere, hvilket er Javas komponent-webservere. Men Java spiller i og for sig ikke den ledende rolle i Cocoon. Det, som kendetegner Cocoon, er systemets arkitektur, og de koncepter, som Cocoon introducerer, kan sagtens bruges i mange andre programmeringsmiljøer.
Det kan i øvrigt sagtens lade sig gøre at installere og eksperimentere med Cocoon uden at have kendskab til Java, da Cocoon bygger på XML, både til data og til konfiguration.
Pipelines
Pipelines
Cocoon bygger på en simpel, intuitiv arkitektur, som helt af sig selv fjerner en stor del af den kompleksitet, som selv mindre publiceringssystemer nemt kan ende i. Behandlingen af kildedata foregår i flere tempi i såkaldte pipelines. En pipeline består af en kilde, som efterfølges af en sekvens af små komponenter, som behandler data på en eller anden måde. Når enden af pipelinen er nået, produceres det endelige resultat, som sendes af sted til klienten.
Hver enkelt lille komponent har en veldefineret opførsel og klart defineret input og output, og derfor kan disse komponenter nemt genbruges. Cocoon benytter så en XML-baseret konfigurationsfil, en sitemap, til at definere, hvordan pipelinen er stykket sammen.
- Input
Input-delen af en pipeline består af generators og readers. Readers er en speciel type pipelines til statiske data, som ikke skal behandles, for eksempel pixel-baserede billeder og andre binære elementer.Generators læser "rigtige" datakilder, som for eksempel filer og databaseforespørgsler. Cocoon indeholder et par stykker på forhånd, FileGenerator, som læser XML-filer fra systemet eller fra webbet, HTMLGenerator, som læser HTML-filer, og DirectoryGenerator, som genererer lister af filerne i en mappe.
- Behandling
Behandlingsdelen af en pipeline består af transformers og actions. En transformer skaber nye XML-datasæt ud fra de XML-datasæt, som den modtager, og den oftest anvendte transformer er XSLT Transformer, som benytter XSLT til at generere de nye datasæt, hvilket vi har gennemgået i tidligere artikler.Actions bruges til at tilføje yderligere dynamiske elementer ind i en pipeline, og de skrives ofte til specifikke formål og anvendelser.
- Output
Når data er strømmet ned i slutningen af pipelinen, skal de omsættes til en form, som klienten kan forstå. De komponenter, som tager sig af denne del kaldes for Serializers. Nogle Serializers kræver en bestemt slags XML for at skabe et slutprodukt. Eksempler er XML Serializer, som genererer XML-datasæt, HTML Serializer som genererer HTML ud fra XHTML, PDF Serializer som danner PDF-filer ud fra XML-sproget XSL-FO, og SVG Serializer, som kan danne binære JPEG- og PNG-billeder ud fra det XML-baserede grafikformat SVG. - Forgreninger
En sidste gruppe af pipeline-komponenter er forgreningsmekanismer som if-then-else sætninger inden for programmering. Den simpleste form for forgreninger er matchers, som fungerer som en simpel if-sætning: Hvis en betingelse er sand, udføres en bestemt pipeline eller en del af en pipeline.En anden type forgrening er Selectors, som virker som en case- eller switch-sætning, hvor der er flere muligheder at vælge imellem. Matchers bruges mest til at bestemme hvilken pipeline, som skal anvendes, og Selectors oftest inde i selve pipelinen til at bestemme, hvilke dele af pipelinen, som skal iværksættes.
Forgreningerne benytter parametre fra forespørgslen, så som URL'en eller brugeragentens navn eller type, til at teste med. Der kan som regel benyttes joker-tegn eller regulære udtryk (regular expressions) i udtrykket, som skal testes.
Sitemaps
En pipeline sættes i sving på følgende måde: Når Cocoon modtager en forespørgsel fra en klient, afgør en Matcher hvilken pipeline, som skal iværksættes. Pipelinen sættes sammen, og forespørgslen bliver så behandlet. Til sidst sendes det færdige resultat til klienten, og resultatet kan eventuelt gemmes i cache til senere anvendelse.
For at holde styr på Cocoons pipelines benyttes en XML-baseret konfigurationsfil, som kaldes for en sitemap. Mere konkret specificerer en sitemap to ting: Hvilke komponenter som benyttes, og pipeline-definitioner.
Tomcat
Cocoon med Tomcat
Før vi går videre med mere konkrete eksempler gennemgår vi, hvorledes Cocoon kan installeres under den seneste version af Tomcat, som er Apache-organisationens Java-webserver og servlet-container. Som tidligere nævnt kan Cocoon afvikles under alle moderne servlet-containere, men der er kan være stor forskel på, hvorledes det gøres, og der er en hel del vejledning i den medfølgende dokumentation.
Med den seneste version af Tomcat er det heldigvis ganske simpelt. Installer Tomcat, og download Cocoon fra projektets hjemmeside. Den downloadede fil pakkes ud, og inden i findes Webapp-pakken cocoon.war. Den flyttes til Tomcats webapps-mappe, som i vores tilfælde har stien C:\Programmer\Apache Tomcat 4.0\webapps.
Nu startes eller genstartes Tomcat, og så bliver Cocoon installeret helt automatisk. Efter et øjeblik kan installationen testes ved at åbne cocoon-webapp'en i en browser, og i vores tilfælde gøres det ved at åbne adressen http://localhost:8080/cocoon/ i en browser. Allerførste gang kan det tage et lille stykke tid, men så skulle der også gerne dukke en Cocoon-velkomstskærm frem i browseren.
Et godt sted at starte er at kigge på de medfølgende "Hallo verden"-eksempler, som følger med Cocoon. Kilden, en simpel XML-fil, som ser sådan ud:
<page>
<title>Hello</title>
<content>
<para>This is my first Cocoon page!</para>
</content>
</page>
- kan publiceres som HTML, PDF, JPEG via SVG, WML og andre formater.
Videre med Cocoon
Ved at kigge i Cocoons sitemap, som har stien webapps\cocoon\sitemap.xmap (ud fra Tomcats hjemmemappe), kan man et stykke nede i den ganske store fil finde en sektion med markeringen "Hello", hvor demonstrationseksemplernes Matchere befinder sig. Den, som genererer html-eksemplet, ser sådan ud:
<map:match pattern="hello.html">
<map:generate src="docs/samples/hello-page.xml"/>
<map:transform src="stylesheets/page/simple-page2html.xsl"/>
<map:serialize type="html"/>
</map:match>
Denne Matcher korresponderer kun med URL'en hello.html. Den iværksættes altså, når Cocoon modtager URL'en hello.html, og vores tilfælde bliver den fulde URL http://localhost:8080/cocoon/hello.html.
Inden for match-elementet har vi først en Generator, som henter dokumentet docs/samples/hello-page.xml (hvor stien er med udgangspunkt i Tomcat-mappen /wabapps/cocoon/). Dernæst transformeres XML-filen med et XSLT-ark, som formodentlig producerer XHTML, og til sidst tager en Serializer sig af at omskabe XHTML-koden til HTML.
Efter denne Matcher følger en række andre Matchere, som benytter den samme XML-kilde som her, men som på samme facon genererer JPEG via XML-sproget SVG, PDF via XML-sproget XSL-FO, og andre formater. Alt sammen fra den nøjagtig samme XML-kode.
Ved at kigge rundt i sitemappen kan man finde flere eksempler, og det er slet ikke så svært at gætte sig til deres virkemåde.
Eksemplet herover giver forhåbentlig ikke indtryk af, at Cocoon bare er en maskine til at generere statiske slutprodukter fra statiske filer. Ved at trække på indhold fra flere kilder kan der skabes komplekse datakilder, som nemt kan integreres og blandes, da de bygger på XML.
Videre med Cocoon
Der kan skrives væsentligt meget mere om Cocoon, end hvad der er plads til her. Cocoons egen dokumentation er, som den slags ser ud, når udviklerholdet selv har lagt pen til: Lidt uorganiseret, og svær at hitte rede i. Men der er skrevet en del bøger om Cocoon, og på IBM's DeveloperWorks-site findes der en række Cocoon-tutorials, hvoraf "Introduction to Cocoon 2" er et rigtigt godt sted at starte. DeveloperWorks kræver registrering, men er gratis.
Man kan eksperimentere videre med Cocoon, og et trick er at skabe en kopi af Cocoon, som man så kan fjolle rundt med, hvilket er beskrevet i "Introduction to Cocoon 2", hvor man også kan finde nogle uddybende begynder-eksempler til, hvorledes man selv kan snedkerere med sitemap og pipelines.
Der er ikke er indbygget noget ressource- eller brugerstyringssystem i Cocoon, men det er der en pointe i. Styringsmekanismer befinder sig logisk set i et andet lag, og det er ikke nogen god idé at skabe en tæt kobling mellem styring og generering af indhold. Cocoon-gruppen udvikler på et portal-system, som skal gøre det nemmere at administrere Cocoon, men der er ingen færdige resultater endnu.
Genistreg
Cocoon er ikke bare et proof-of-concept, hvor gyldigheden af et princip bevises. Systemet kan også bruges til produktionssites. Men det vigtigste i Cocoon er arkitekturen og virkemåden, som så kan implementeres på mange måder.
At kalde Cocoon for noget mindre end en genistreg er ganske uretfærdigt. Det simple koncept, den intuitive arkitektur og systemets åbenhed gør det til en klar vinder, og principperne i Cocoon vil helt givet få overvældende betydning for fremtidens publiceringssystemer, uanset sprog og afviklingsmiljø.
