Hypermedian ohjelmointi, kevät 2009 (http://hlab.ee.tut.fi/hmopetus/hmohj-2009) Luento 5. Julkaisujärjestelmän toteuttaminen Jukka Huhtamäki, Hlab (http://tut.fi/hypermedia) Julkaisujärjestelmän toteuttaminen Julkaisujärjestelmä automatisoi julkaisuprosessin toiminnallisuuden: sijoittaa sisällön sivupohjiin, tuottaa rakenteelliset ja assosiatiiviset linkit ja niin edelleen. Sivupohjamekanismi on keskeinen osa julkaisujärjestelmän toiminnallisuutta. Vastaavaa mekanismia voidaan soveltaa missä tahansa vuorovaikutteisessa verkkopalvelussa. Julkaisujärjestelmä on usein osa laajemman sisällönhallintajärjestelmän (Content Management System, CMS) toiminnallisuutta. Nyt tavoitteena on perehtyä julkaisujärjestelmän toteuttamisen käytäntöihin sekä mukauttamisen perusteisiin.
Julkaisujärjestelmän toiminnallisuus Ulkoasu: ulkoasun irrottaminen esimerkiksi tyylitiedostojen avulla Sivupohjat: Asettelun määritteleminen sivupohjilla, joiden muokkaaminen onnistuu ilman teknistä osaamista. Jopa WYSIWYG-käyttöliittymä sivupohjien muokkaamiseen? Laajennettavuus: Järjestelmän on mahdollistettava jatkuva kehitystyö. Uusien julkaisemiseen liittyvien toimintojen toteuttamisen on oltava helppoa Julkaisumuodot: Tiedon julkaiseminen eri muotoihin on oltava mahdollista. Mahdollisuus uusien julkaisumuotojen lisäämiseen on tärkeä Personointi: tiedon julkaiseminen käyttäjän käyttäjäryhmän perusteella mukautettuna (=> mukautuva hypermedia) Käytön tilastointi: Käytön lokidatan tallentaminen tietokantaan ja erilaisten raporttien muodostaminen. Esimerkkejä: suosituimmat sivut, päivittäinen käyttö tai hakutoiminnon käyttö (virheelliset haut => käytettävyyden edistäminen) Muista myös nämä: käytettävyys, saavutettavuus, selainriippumattomuus, yksinkertainen asiakas, käytön nopeus, validi HTML ja CSS, navigaation apuvälineet ja metatiedon julkaiseminen
Tiedon tyyppi ja tallentaminen Verkkopalvelun sisältö on tietoa. Tieto voidaan jakaa kahteen tyyppiin: Datakeskeinen tieto on jäsennettävissä pieniin palasiin, jotka voidaan esimerkiksi tallentaa relaatiotietokantaa. Esimerkkejä: reseptit, levyn tiedot, henkilötiedot,... Dokumenttikeskeinen tieto muodostuu jotakin tiettyä asiaa käsittelevistä kokonaisuuksista. Tiedon tallentaminen onnistuu parhaiten dokumenttitietokantaan. Esimerkkejä: kirja, raportti, käyttöohje, oppimateriaali,... Esimerkki datakeskeisestä tiedosta: Laika & the Cosmonauts;Absurdistan;1997;surf Esimerkki dokumenttikeskeisestä tiedosta: <p><img src="laika-in-space.png" alt="laika the Space Dog"/> Laika & the Cosmonauts on <dfn>visuaalista avaruussurfia</dfn>... </p> Tiedon tyypillä on keskeinen vaikutus tiedon muokkaamiseen ja tallentamiseen käytettävän menetelmän valinnassa
Tiedon tallentaminen: vaihtoehtoja Sisällönhallintajärjestelmän tietovarasto voidaan toteuttaa monella eri tavalla: Määrämuotoinen tekstitiedosto (flat file): Tiedot tallennetaan tekstitiedostoon esimerkiksi Comma Separated Value (CSV) -muodossa. Osa ASCII-merkeistä on varattu tietojen jäsentämiseen Rakenteinen dokumentti: Tallennusmuotona käytetään jotakin XMLkieliopin (miksei myös SGML-kieliopin) mukaista merkkauskieltä. Mahdollistaa tietojen suoraviivaisen siirtämisen ja uudelleenkäytön Relaatiotietokanta: Tiedot tallennetaan relaatiotietokannan tauluihin riveinä. Erilaisiin tekstitiedostoihin verrattuna merkittävästi tehokkaampi ja siten skaalautuvampi vaihtoehto Dokumenttitietokanta: Järjestelmään tuodut dokumentit, esimerkiksi mediaelementit, voidaan tallentaa sellaisenaan dokumenttitietokantaan. Myös osa relaatiotietokannoista tukee vastaavaa toiminnallisuutta. Relaatiotietokanta on suositeltavin vaihtoehto, kun tarkoituksena on toteuttaa sisällönhallintajärjestelmä suurelle joukolle käyttäjiä. Tekstitiedostoihin perustuvien vaihtoehtojen etuna on parempi siirrettävyys.
Tiedon siirtäminen järjestelmien välillä Määrämuotoiset tekstitiedostot ja rakenteiset dokumentit soveltuvat erityisen hyvin tiedon siirtämiseen järjestelmien välillä Esimerkki: levykokoelman tiedot XML-muodossa: <recordcollection> <record year="1997"> <name>absurdistan</name> <artist>laika & the Cosmonauts</artist> </record> </recordcollection> Esimerkki: levykokoelman tiedot CSV-muodossa: Laika & the Cosmonauts;Absurdistan;1997;surf XML ja CSV soveltuvat molemmat sekä tiedon julkaisemiseen että siirtämiseen sisään sisällönhallintajärjestelmään PHP tukee XML-muotoisen tiedon jäsentämistä. CSV-lukijan toteuttaminen on suoraviivaista. PHP-ohjelmalla voi HTML-kielen ohella mainiosti tulostaa esimerkiksi CSV- tai XML-muotoisia tiedostoja
Julkaisuprosessin automatisointi Ohjelmointikieliä voidaan hyödyntää myös muussa käytössä kuin vuorovaikutuksen toteuttamisessa. Julkaisujärjestelmät automatisoivat osan hypermediasovelluksen toteuttamisen mekaanisista työvaiheista Hypermediasovelluksen toteuttamiseen liittyy muun muassa seuraavia mekaanisia työvaiheita (vrt. Relationship Management Methodology, RMM): Sovelluksen yleinen sivupohja kopioidaan jokaiseen näkymään ja näkymäkohtainen sisältö sijoitetaan sivupohjaan. Näkymäkohtaisen sisällön lisäämisen jälkeen sivupohjan järjestelmällinen muuttaminen on mahdotonta Rakenteelliset linkit tehdään sivuston rakenteen perusteella. Esimerkiksi valikko voidaan sijoittaa sivupohjaan, mutta käyttäjän sijainnin näyttäminen edellyttää näkymäkohtaisten muutosten tekemistä Assosiatiivisten linkkien toteuttaminen on yleensä suuren työmäärän takia mahdotonta käsityönä Aidon laiteriippumattomuuden ja mukautuvan hypermedian toteuttaminen vaatii aina ohjelmointia ja dynaamista toteutusta. Myös monikanavajulkaiseminen on suuren työmäärän takia käytännössä mahdotonta ilman automatisointia
Julkaisujärjestelmän toimintaperiaate Julkaisujärjestelmät voidaan jakaa toimintaperiaatteen perusteella kolmeen luokkaan: Yksi versio kaikille: Hypermediasovelluksesta julkaistaan yksi versio, jonka on sovelluttava kaikkiin käyttötarkoituksiin. Tavoitteena One size fits all, tuloksena usein One size fits nobody Räätälöity julkaiseminen: Tässä lähestymistavassa julkaistaan lueteltu joukko versioita, joista valitaan kuhunkin käyttötarkoitukseen parhaiten sopiva versio. Valinta suoritetaan yleensä käyttäjän toimesta, mutta versio voidaan valita esimerkiksi asiakasohjelman (selain) toimittamien tietojen perusteella automaattisesti Joustava julkaiseminen: Sovelluksesta asiakkaalle toimitettavat näkymät räätälöidään pyynnön yhteydessä välitettyjen tietojen perusteella tiettyyn julkaisukontekstiin (delivery context) sopivaksi. Joustavan julkaiseminen vastaa yleisessä tapauksessa mukautuvan hypermedian ideaa Tässä keskitytään räätälöityyn julkaisemiseen. Joustavaan julkaisemiseen palataan laiteriippumattomuuden ja mukautuvan hypermedian yhteydessä
Reunaehto: sisällön ja esitystavan erottaminen Rakenteisen hypermedian keskeinen idea on sisällön ja esitystavan erottaminen Vaihtoehtoja sisällön ja esitystavan erottamiseen: HTML ja CSS: CSS on koristeleva tyylikieli, jonka avulla voi vaikuttaa ainoastaan HTML-dokumentin ulkoasuun XML ja XSLT: tietosisältö esitetään XML-muodossa ja julkaistaan XSLmuunnosten avulla haluttuihin muotoihin Tietokanta ja ohjelmointikieli: tietosisältö sijoitetaan tietokantaan ja julkaistaan ohjelmointikielen avulla haluttuihin muotoihin Kaksi viimeistä vaihtoehtoa mahdollistavat muutokset sekä yksittäisten dokumenttien rakenteessa että koko hypermediasovelluksen navigointirakenteessa XSL-muunnosten avulla voidaan toteuttaa ainoastaan räätälöidyn julkaisemisen periaatteen mukaisia ratkaisuja. Joustavaan julkaisemiseen tarvitaan aina ohjelmointia Ainoa keino vuorovaikutuksen toteuttamiseen on ohjelmointikielen käyttäminen. XSL-muunnosten avulla voidaan kuitenkin esimerkiksi automatisoida ohjelmointikieleen perustuvan ratkaisun toteutustyöhön liittyviä mekaanisia työvaiheita
PHP: toimintalogiikan ja esitystavan erottaminen PHP on alun perin suunniteltu dokumenttien sekaan upotettavaksi ohjelmointikieleksi. Yleensä sovellukset toteutetaan kuitenkin niin päin, että PHPkoodilla tulostetaan HTML-merkkausta Esitystavan (=käyttöliittymän) ja toimintalogiikan erottaminen toisistaan selkeyttää ohjelmakoodia, mahdollistaa helpomman tavan verkkopalvelun räätälöimiseen ja helpottaa verkkopalvelun toteutustyötä ja ylläpitoa Esitystapa ja toimintalogiikka voidaan erottaa toisistaan kolmella tavalla: 1. Staattisen sivupohjan jakaminen osiin & sisällyttäminen näkymiin requirekomennolla 2. HTML-merkkauksen tulostaminen funktio- tai luokkakirjaston avulla 3. Sivupohjamoottorin (template engine) käyttäminen, esim. Smarty tai Savant Paras ratkaisu saavutetaan sivupohjamoottorin ja HTML-merkkauksen tulostamisesta vastaavan kirjaston yhdistelmällä Ratkaisuja voidaan hyödyntää sekä julkaisujärjestelmän että vuorovaikutteisen sovelluksen toteuttamisessa
Esimerkki: yksinkertainen sivupohjamoottori Yksinkertainen sivupohjamoottori voidaan toteuttaa esimerkiksi XMLnimiavaruuksien ja säännöllisten lausekkeiden avulla (etsi/korvaa). Esimerkki (ongelma: nimiavaruuden etuliite on nyt kiinnitetty, ratkaisu: sivupohjan käsittely XML-tasolla):
Rakenteelliset linkit Rakenteelliset linkit (kertausta): esimerkkejä: murupolku, valikko, lineaarinen navigaatio pääasiallinen navigointimenetelmä rakenteellisten linkkien avulla käyttäjälle esitetään sovelluksen rakenne käyttäjän sijainti sovelluksessa esitetään usein rakenteellisten linkkien avulla, vrt. mukautuva valikko tai murupolku Rakenteellisten linkkien muodostaminen voidaan automatisoida eri tavoilla: Linkit voidaan tulostaa funktiokirjaston avulla tai sisällyttää näkymään esimerkiksi PHP-kielen require-komennolla Vielä parempi vaihtoehto on rakenteellisten linkkien tulostaminen sivuston rakennekuvauksen perusteella. Rakenne voidaan esittää esimerkiksi määrämuotoisen tekstitiedostossa, XML-dokumentissa tai relaatiotietokannassa Nyrkkisääntö: Tieto sijoitetaan relaatiotietokantaan silloin, kun muokkaaminen onnistuu suoraan sovelluksen avulla, muuten käytetään asetustiedostoja
Esimerkki: rakennekuvaus ja rakenteelliset linkit Esimerkki rakenteellisten linkkien tuottamisesta PHP-kielellä XML-kuvauksen perusteella: XML-kuvauksen jäsentäminen voidaan toteuttaa PHP:n SimpeXML-rajapinnan avulla Assosiatiiviset linkit Assosiatiiviset linkit (kertausta): yhdistävät näkymiä sisällön merkityksen perusteella tarjoavat käyttäjälle vaihtoehtoisen navigointitavan vastaavat ihmisen tapaa jäsentää asioita (Vannevar Bushin Memex) Assosiatiivisten linkkien muodostaminen onnistuu näkymien tietosisällöstä kerättyjen metatietojen avulla
Metatiedosta Tiedon ja metatiedon raja on häilyvä. Erään määritelmän mukaan metatieto on tietoalkiosta ulospäin näkyvää tietoa, jota voidaan käyttää apuna tietoalkioiden hallinnassa. Käsittely: Metatieto relaatiotietokannassa: assosiatiiviset linkit muodostetaan SQLkyselykielen avulla Metatieto RDF-muodossa: assosiatiiviset linkit muodostetaan esim. SPARQL-kyselykielen avulla Assosiatiivisten linkkien toteuttaminen sääntöjen perusteella on liian työlästä käsityönä
Esimerkki: assosiatiiviset linkit ja levykokoelma Käyttäjä on löytänyt Laika & the Cosmonautsin levyn Absurdistan. Näkymässä esitetään levyn tiedot ja linkit kaikkiin levyihin, joissa on sama esittäjä (artist = "Laika & the Cosmonauts") ja joiden nimi ei ole Absurdistan (name <> "Absurdistan") Nimien sijaan tietoja kannattaa vertailla levyjen tunnisteiden perusteella, mikäli tietokanta sellaiset sisältää (pitäisi ainakin!) Julkaisujärjestelmällä onnistuu esimerkiksi näkymien mukauttaminen
Mitä mukautetaan? Verkkopalvelua voidaan mukauttaa eri tavoilla (Lähde: Authoring Techniques for Device Independence (http://www.w3.org/tr/di-atdi/) ): Tyyli (Style): Resurssin esitystavan muuttaminen ilman, että resurssi itsessään muuttuu. Tapahtuu käytännössä CSS-tyylien avulla Asettelu (Layout): Näkymän komponenttien sijoittelu ruudulle. Voidaan toteuttaa esimerkiksi sivupohjien avulla Sisältö (Content): Rakenteistetusta tietosisällöstä voidaan poimia osia käyttäjän mieltymysten tai laitteen ominaisuuksien perusteella Rakenne (Structure): Sovelluksen rakennetta voidaan mukauttaa joko näkymiä koostamalla (aggregation) tai jakamalla osiin (decomposition). Suunnitelmallisessa toiminnassa näkymiä yleensä koostetaan Navigaatio (Navigation): Navigaatiota voidaan mukauttaa sekä teknisestä että sisällöllisestä näkökulmasta Vuorovaikutus (Interaction): Mahdollisuudet syötteen tuottamiseen ja vuorovaikutteisten komponenttien käyttämiseen vaihtelevat päätelaitteittain Minkä perusteella mukautetaan? Jakelukontekstin tiedot voidaan selvittää eri tavoin: Kysytään käyttäjältä: Tiedot ovat varmasti oikein, mutta käyttäjä joutuu näkemään ylimääräistä vaivaa (vrt. google.com/pda) Selain välittää tiedot pyynnön yhteydessä esimerkiksi CC/PP- tai UAProfprotokollan avulla. Ongelmana on vielä tällä hetkellä se, että päätelaitteet eivät yleisesti tue jakelukontekstin tietojen välittämistä Eräs käyttökelpoinen keino on HTTP-pyynnön otsikkotietojen lukeminen ja analysoiminen HTTP ja jakelukontekstin aistiminen HTTP-pyynnön tapauksessa ongelmana on se, että otsikoissa välitettävien tietojen esitysmuotoa tai arvoja ei ole standardoitu Eräs keino on tarjota käyttäjälle mahdollisuus määritellä erilaiset julkaisukontekstit palvelulle: Nyt käyttämäni laite on kämmenlaite. Tiedot voidaan tallentaa esimerkiksi tietokantaan ja tunnistaa laite seuraavan kerran tietojen perusteella
Esimerkki: jakelukonteksti ja HTTPpyynnön otsikot Selaimen A välittämät tiedot: HTTP_ACCEPT_LANGUAGE: HTTP_ACCEPT: */* HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; Selaimen B välittämät tiedot: HTTP_ACCEPT_ENCODING: gzip HTTP_ACCEPT: text/html, application/xml; q=0.9, application/xhtml+xml image/png, image/jpeg, image/gif, image/x-xbitmap, */*; q=0.1 HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.9 HTTP_USER_AGENT: Opera/8.01 (J2ME/MIDP;Opera Mini/3.1.7196/1644; en; U; ssr) Selaimen C välittämät tiedot: HTTP_ACCEPT_LANGUAGE: fi,en-us;q=0.7,en;q=0.3 HTTP_ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13 Mitä tietojen perusteella voi päätellä? Voiko tietojen olemassaolosta tai esitysmuodosta tehdä oletuksia? Onko tietoja mahdollista väärentää?
Esimerkki: jakelukonteksti ja UAProf (1/2) CC/PP-protokollaan perustuva UAProf määrittelee täsmällisen tavan jakelukontekstin kuvailemiseen. Keksitty esimerkki kannettavan tietokoneen tietojen esittämisestä UAProf-muotoisesta esitystavasta N3-muotoon sarjallistettuna: @prefix : <http://hmopetus.ee.tut.fi/device-profile#>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix ccpp: <http://www.w3.org/2000/07/04-ccpp#>. @prefix uap: <http://www.wapforum.org/profiles/uaprof/ccppschema-20010330#>. :LapTop ccpp:component :Mozilla. :Mozilla a uap:browserua; uap:xhtmlversion "1.0"; uap:preferenceforframes "No"; uap:tablescapable "Yes". :LapTop ccpp:component :DefaultSW. :DefaultSW a uap:softwareplatform; uap:ccppaccept [a rdf:bag; rdf:_1 "text/png"; rdf:_2 "text/jpeg"]. :LapTop ccpp:component :DefaultHW. :DefaultHW a uap:hardwareplatform; uap:soundoutputcapable "Yes". UAProf-määritys käyttää tietojen esittämiseen Resource Description Framework (RDF) -kehystä, joka saattaa aluksi vaikuttaa monimutkaisemmalta kuin lopulta onkaan
Esimerkki: jakelukonteksti ja UAProf (2/2) Jakelukontekstin kuvaus esitettiin edellä N3-kieliopin mukaan sarjallistettuna RDF-graafina, joten käsittely onnistuu esimerkiksi RDF Query Language (RDQL) -kielellä: SELECT?browser,?xhtmlversion FROM <profile.n3> WHERE (?browser uap:xhtmlversion?xhtmlversion ) USING ccpp FOR <http://www.w3.org/2000/07/04-ccpp#> uap FOR <http://www.wapforum.org/profiles/uaprof/ccppschema-20010330#> Kysely etsii RDF-mallista uap:xhtmlversion-ominaisuuden arvon eli selaimen tukeman XHTML-version. RDQL-kyselyitä tukeva Jena-komentorivisovellus tulostaa kyselyn lopputuloksen seuraavalla tavalla: browser xhtmlversion ================================================================= <http://hmopetus.ee.tut.fi/device-profile#mozilla> "1.0" W3C:n SPARQL-suositus (http://www.w3.org/tr/rdf-sparql-query/) esittelee rikkaammat mahdollisuudet kyselyiden tekemiseen. Java-soveltajien käytössä on DELI-kirjasto (http://sourceforge.net/projects/delicon/), joka antaa mahdollistaa CC/ PP- tai UAProf-muodossa esitettyjen tietojen jäsentämisen.
Lopuksi Yleistettynä kaikki verkkopalvelut ovat sisällönhallinta- ja julkaisujärjelmiä, mutta mahdollistavat toki toisinaan enemmän vuorovaikutusta kuin mitä julkaisujärjestelmiin yleensä ajatellaan kuuluvan Sivupohjan irrottamisen ja erilaisten linkkien muodostamisen automatisoinnin ideat voidaan ottaa suoraviivaisesti käyttöön aidosti vuorovaikutteisessa sovelluksessa Käytännössä yhden kaikenkattavan SHJ:n toteuttaminen on erittäin hankalaa: Sisällöntuottajat haluavat käyttää tuttuja välineitä, mutta Word on tarkoitettu paperille tulostettavien dokumenttien tekemiseen Sisällöntuottajat ja WYSIWYG: ks. edellinen kohta. Erilaiset legacy-järjestelmät hidastavat kehitystä. Julkaisujärjestelmissä ohjelmointikielten vaihtoehtona ovat XML-kieleen ja XSLmuunnoksiin perustuvat sinänsä ilmaisuvoimaiset ratkaisut (esim. Cocoon) Nykyaikaisten Web-palvelujen sisältö (yleisesti tila) on usein hajautettu useampaan palveluun (vrt. REST).