Objavljeno: 14.8.2005 02:21 | Avtor: Uroš Mesojedec | Monitor Julij 2005

Groovy

Če nas zanima hitro sestavljanje testnih primerov, povezovanje različnih sistemov ali spletnih storitev, razvoj pomožnih programčkov ali pripomočkov za enkratno rabo, zna biti nov skriptni jezik, ki temelji na javi, groovy, izvrstna izbira.

Skriptni programski jeziki so vse bolj priljubljeni. Razlogov je več, povezuje pa jih seveda internet, ki je prinesel kopico novih tehnologij in izzivov pred že tako preobremenjene razvijalce. Visoka zmogljivost sodobnih računalnikov že dolgo ne zahteva več ročnega piljenja strojne kode za izžemanje zadnjih kapelj sistemske moči. Številne programske rešitve poleg tega ne trpijo več zaradi nekoč tipičnega ozkega grla računalniške zgradbe - prenosa podatkov po vodilu - saj je za sodobne, porazdeljene programe temeljno "vodilo" dejansko postalo računalniško omrežje, katerega zakasnitve so za nekaj velikostnih razredov večje. Izzivi današnjega časa so zato čim večja varnost, porazdeljenost in odpornost za strojne in programske napake ter s tem povezana čim večja razpoložljivost in stopnjevana zmogljivost sistema, ki bi v idealnem scenariju 24 ur na dan, sedem dni na teden stregel neomejenemu številu uporabnikov.

Časa za razvoj programov, ki bi se temu idealu najbolj približali, pa nikoli ni dovolj. Številni programi poleg tega že dolgo niso monolitni kosi strojne kode, temveč jih sestavljajo številni medsebojno povezani gradniki, kot so spletne strani, ki so že tako ali tako sestavljeni iz kopice različnih datotek (HTML, CSS, skripte za odjemalca ...), predmeti v programskih strežnikih, podatki v različnih zbirkah, spletne storitve ... Še posebej dinamične spletne strani so postale izjemno uspešno "gojišče" različnih skriptnih rešitev (Perl, PHP, ASP...). Tudi če program v celoti razvijemo v katerem od sodobnih programskih jezikov, kot sta java ali C#, je še vedno precej dela s preizkušanjem, namestitvami, integracijo v večje sisteme. Skratka, razlogov, da je skriptna koda vse bolj priljubljena, je veliko.

Kaj pravzaprav loči skriptno kodo od običajnega programskega jezika? Možnost hitrega razvoja, ki ne zahteva strogega spoštovanja pravil, ne zahteva najavljanja in tipiziranja spremenljivk, ponuja posebne konstrukte za hitro vzpostavitev in zapolnitev razmeroma zapletenih podatkovnih struktur, kot so npr. preslikave (map) itn. Ena od rešitev, ki je že pred desetletjem obljubljala poenostavitev razvoja programske kode, je java. Seveda je java daleč od skriptnega jezika (mnogi sicer smatrajo javascript kot tovrstno različico jave, vendar gre v resnici za dve popolnoma različni programerski orodji, ki si medsebojno delita le nekatere skladenjske značilnosti), vendar pa je java po drugi strani mnogo več kot le programski jezik. Java je v resnici podlaga (platform) za razvoj in izvajanje programske opreme in ključen člen podlage je izvajalni sistem (JVM, Java Virtual Machine), ki je sposoben javansko vmesno kodo (bytecode) izvajati na najrazličnejših strojnih sistemih, od preprostih prenosnih napravic do najzmogljivejših poslovnih strežnikov.

s

e

d

a

groovy> for (e in seznam) {println e}

groovy> go

1

2

3

4

5

b

e

groovy> for (c in "beseda") {println c}

groovy> for (i in 1..5) {println i}

Polimorfizem je ravno tako zelo dobrodošla "bližnjica" pri pisanju skriptne kode. Videli smo že, kako se obnaša sprehod skozi preslikavo s pomočjo zanke for, koda pa je precej podobna tudi pri drugačnih sprehodih:

a.leftShift(b)

Tabela 1: S pomočjo posebnih metod lahko preobremenimo operatorje za rabo s predmeti.

Videli bomo, če se bo uporabnost te zmožnosti odtehtala precej oteženo vzdrževanje kode, ki vsebuje tako prikrojeno obnašanje operatorjev.

a.putAt(i, b)

a == b

a.equals(b)

a < b / a <= b / a > b / a >= b

a.compareTo(b)

a " b

a++ / ++a

a.next()

a[i]

a.getAt(i)

a[i] = b

Raba operatorja

Ustrezna metoda

a + b

a.plus(b)

a - b

a.minus(b)

Oseba Janez je v sobi 205

Oseba Micka je v sobi 304

Oseba Polde je v sobi 110

Preobremenitev operatorjev zna biti dvorezen meč. Odsotnost te zmožnosti v javi je precej poenostavila branje, razumevanje in vzdrževanje kode, čeprav jo morda številni programerji, ki so presedlali iz C++ močno pogrešajo. No, groovy preobremenitev podpira in sicer na zelo enostaven način. Številnim operatorjem odgovarjajo posebno poimenovane metode. Če jih zapišemo za posamezen razred, lahko namesto njenega klica pri dveh predmetih tega razreda uporabimo kar operator. Povzema jih tabela 1.

Oseba Francelj je v sobi 632

groovy> go

false

Metoda zrna je torej na voljo kot lastnost (brez predpone "is"). Zelo preprosto lahko vzpostavimo tudi strukturo preslikave (Map): pare preslikave, naštete v oglatem oklepaju, ločimo z dvopičjem (:), kakor kaže zgled:

groovy> sobe = [ "Janez":205, "Micka":304, "Polde":110, "Francelj":632 ]

groovy> for ( e in sobe ) { println "Oseba ${e.key} je v sobi ${e.value}" }

groovy> go

groovy> println seznam.empty

groovy> go

class java.lang.Integer

groovy> x = "beseda"

groovy> println x.class

groovy> go

class java.lang.String

Videli smo že, kako lahko hitro vzpostavimo podatkovno strukturo, in da gre za prvovrstni javanski razred. Groovy pa nam približa tudi uporabo lastnosti in metod zrn. Ker je vsaka podatkovna zbirka vrste seznam (List collection) tudi zrno, ki pozna metodo isEmpty(), je v groovyju mogoče zapisati:

groovy> seznam = [ "Janez", "Micka", "Polde", "Francelj" ]

groovy> x = 5

groovy> println x.class

Agilnost predstavlja zmožnost jezika za hitro pisanje kode in prilagodljivost pri krajšem zapisovanju pogosto dolgoveznih javanskih konstruktov. Podatkovni tipi so, kot smo že videli, pri groovyju neobvezni, prevajalnik pa izbere ustrezno predmetno predstavitev, skladno trenutno shranjeni vrednosti. Te niso nikoli shranjene kot primitivni tip (npr. vedno Integer in nikoli int), kar predstavlja tudi samodejno pretvorbo tipa (autoboxing). To nam ponazarja naslednji preprosti zgled:

  • podpiral regularne izraze,
  • omogočal pisanje zaprtih blokov (closures).
  • podpiral statično in dinamično predpisovanje tipov,
  • ponujal skladenjske konstrukte za rabo seznamov, preslikav, polj in javinih zrn,
  • omogočal preobremenitev operatorjev (operator overloading),
  • ponujal samodejno pretvorbo tipov in polimorfizem pri rabi podatkovnih struktur, zrn in iteratorjev,
  • bil agilen,
  • Temeljne značilnosti

    Temeljne značilnosti groovya njegovi avtorji popisujejo s številnimi zvenečimi besedami (kot njega dni javo). Groovy naj bi:

    }

    }

    Seveda ta zgled nikakor ne želi ponazoriti, da je java prezapletena in preveč zgovorna, preprosto obstajajo naloge, ki jih je mogoče veliko učinkoviteje rešiti s skriptno kodo. Java ima povsem drugačno vlogo in predstavlja zelo dobro osnovo za razvoj kompleksnih, visoko zmogljivih programskih rešitev. Groovy cilja na povsem drugačne probleme. Po drugi strani pa velja poudariti, da je zaradi preproste rabe celotnega javanskega programerskega vmesnika tudi v groovyju mogoče razviti zelo zmogljive pripomočke.

    for (String s : iskano) {

    System.out.println(s);

    }

    }

    }

    for (String s : seznam) {

    if (s.contains("j")) {

    iskano.add(s);

    seznam.add("Janez");

    seznam.add("Micka");

    seznam.add("Polde");

    seznam.add("Francelj");

    List<String> iskano = new ArrayList<String>();

    import java.util.*;

    public class NiGroovy {

    public static void main(String args[]) {

    List<String> seznam = new ArrayList<String>();

    groovy> iskano.each { println it }

    groovy> go

    Francelj

    groovy>

    Zelo preprosto smo preiskali zbirko in izpisali najdeni izid, vse besede iz zbirke, ki vsebujejo črko (podniz) "j". Rezervirana beseda it omogoča preprost sklic na iterator zanke. Enakovreden program v javi 5 bi bil videti nekako takole:

    groovy>

    Javanske podatkovne strukture, kakršna je seznam (List collection), torej ustvarimo s preprostim naštevanjem znotraj oglatih oklepajev. Udobja pa s tem še ni konec:

    groovy> iskano = seznam.findAll { it.contains("j") }

    class java.util.ArrayList

    Vrnimo se nazaj v konzolo. Kakor smo zapisali, je groovy močno navezan na javo. V resnici so podatkovne strukture, ki jih lahko z groovyjem zelo hitro vzpostavimo, resnični javanski predmeti, kar nam dokaže naslednji zgled:

    groovy> seznam = [ "Janez", "Micka", "Polde", "Francelj" ]

    groovy> println seznam.class

    groovy> go

    Lep pozdrav, Uroš. Kako smo danes?

    Groovy je morda nekoliko preveč popustljiv pri skladnji programskih stavkov. Podpičja (;) na koncu niso obvezna in jih moramo uporabiti le, če bi v eni vrstici radi zapisali več stavkov. Ravno tako ne zahteva pisanja oklepajev () pri klicu metod. Čeprav se zdi takšno popuščanje primerno za hitro kodiranje, ki naj bi ga skriptna koda ponujala, žal prinaša grožnjo, ki so ji v enaki želji podlegli številni skriptni jeziki. Koda namreč lahko postane silno nepregledna, kar znatno oteži njeno kasnejše razumevanje in vzdrževanje. Glede na to, da se jezik še razvija, se bo morda v prihodnosti pri prevajanju vedel strožje.

    Če je bila vsebina datoteke "pozdrav.groovy":

    name = "Uroš"

    text = "Lep pozdrav, ${name}! Kako smo danes?"

    assert text != null

    println ( text )

    dobimo naslednji izpis:

    groovy pozdrav.groovy

    Namesto običajne konzole lahko uporabimo tudi grafično (seveda javansko, izdelano s predmetnim ogrodjem Swing), ki se skriva za ukazom groovyConsole. Ta prikliče grafični vmesnik za preizkušanje skriptne kode.

    Grafični pripomoček za preizkušanje kode v groovyju.

    Kodo trajnejše vrednosti bomo seveda shranili v ločene datoteke. Priporoča se raba podaljška .groovy. Tovrstne datoteke lahko poženemo z ukazom groovy, npr:

    Takšen, "parametriziran" pozdrav, smo zapisali precej hitreje, kot bi šlo v javi. Opazimo lahko precej prednosti skriptnega jezika: spremenljivke nismo niti najavili, niti ji predpisali podatkovnega tipa, preprosto ji dodelimo želeno vrednost. Za izpisovanje ne potrebujemo sklicevanja na posebne predmete, temveč uporabimo neposreden klic metode println. In, seveda, groovy podpira razširjanje nizov z zamenjavami (string substitution). V zgledu lahko vidimo, kako preprosto je izpisati niz s spremenljivko kot delom vsebine.

    groovy> ime = "Uroš"

    groovy> println "Tole 'gruva', kajne, ${ime}?"

    groovy> go

    Tole 'gruva', kajne, Uroš?

    groovy>

    Version: 1.0-jsr-01 JVM: 1.5.0_02-b09

    Type 'exit' to terminate the shell

    Type 'help' for command help

    Type 'go' to execute the statements

    groovy>

    Za pozivnikom (groovy>) lahko vnesemo poljubne programske stavke, za tem pa jih poženemo z ukazom go, kakor kaže spodnji zgled:

    export JAVA_HOME=/usr/local/java

    export GROOVY_HOME=/home/uporabnik/groovy

    PATH=$PATH:$GROOVY_HOME/bin

    Seveda znova ob predpostavkah, da je java v mapi /usr/local/java/, groovy pa smo si namestili v /home/uporabnik/groovy. Verjetno bomo morali po namestitvi groovyja poskrbeti tudi za izvedljivost datotek v podmapi bin/:

    chmod +x $GROOVY_HOME/bin/*

    Hitreje do cilja

    Po uspešni namestitvi lahko preizkušamo orodja skriptnega jezika. Najprej lahko poizkusimo s posebno lupino, ki omogoča hitro preizkušanje odsekov kode v groovyju, zaženemo jo z ukazom groovysh:

    $ groovysh

    Lets get Groovy!

    ================

    set PATH=%PATH%;%GROOVY_HOME%\bin

    Seveda ob predpostavki, da smo JDK namestili v mapo C:\Program Files\Java\jdk1.5.0_02, groovy pa v mapo C:\Program Files\Java\groovy. Če bomo ustrezne nastavitve izvedli iz datoteke .bat, bodo seveda na voljo le za čas seje v oknu s konzolo. Trajno lahko vse nastavitve vnesemo prek Nadzorne plošče (Control Panel). V unixu podobnih okoljih moramo nastavitve vnesti v vzpostavitveno datoteko izbrane lupine (shell startup script), npr.:

    set GROOVY_HOME=C:\Program Files\Java\groovy

    set JAVA_HOME=C:\Program Files\Java\jdk1.5.0_02

    Spletni dom jezika groovy

    Groovy seveda zahteva nameščen paket JDK 1.4 ali 1.5 (oziroma 5.0). Vsebino paketa lahko prenesemo v katerokoli mapo na disku, vendar bomo morali pred uporabo orodij groovyja poskrbeti za nekaj sistemskih nastavitev. Groovy potrebuje pot do namestitve JDK, pot do lastne namestitve, za dodatno udobje pa lahko mapo pripomočkov groovyja dodamo še v sistemsko pot. Ustrezne nastavitve za Okna nam lahko izdela pomožna datoteka .bat, katere vsebina je lahko naslednja:

    Pripravimo groovy

    Skupaj s čedalje večjim številom zanimivih odprtokodnih projektov je projekt Groovy doma na spletišču Codehaus [2]. Od tu lahko prenesemo ustrezen stisnjen paket, ki vsebuje vse potrebno, da pričnemo z delom.

    Če nas zanima hitro sestavljanje testnih primerov, povezovanje različnih sistemov ali spletnih storitev, razvoj pomožnih programčkov ali pripomočkov za enkratno rabo, pri tem pa javo že dobro poznamo, zna biti groovy izvrstna izbira. Spoznajmo ga nekoliko bliže.

    JSR 241 je bil rojen pred dobrim letom, aprila 2004, strokovna skupina pa je dobila enoglasno podporo v procesu JSR in je bila izvoljena z izidom 16 za, nihče proti. Delovna skupina je prevzela pripravljeni osnutek jezika in ga v marsičem izboljšala. Na novo so razvili členitelj (parser) in jeziku dodali številne nove zmožnosti. Po trenutnem načrtu nas do uradne različice z oznako 1.0 loči še nekaj mesecev, prva razvojna različica pa je postala dostopna svetu 6. aprila letos. Groovy ponuja, kar sta si tvorca želela, skriptni programski jezik, ki se izvaja brez posrednikov neposredno na JVM, uporablja javanska orodja, predmete in programerske vmesnike (API). Predmet v groovyju je neposredni potomec pra-razreda jave, java.lang.Object, hitro zapolnjeni seznami so v resnici predmeti razreda java.util.List, brez težav lahko uporabljamo javanska zrna, dejansko precej lažje kakor v sami javi, in celoten nabor pripravljenih knjižnic (iz podlag J2SE ali J2EE).

    Odgovor na izziv učinkovitega skriptnega jezika za programerje v javi je prišel v obliki novega jezika, poimenovanega groovy. Želja tvorcev novega skriptnega jezika, Jamesa Strachana in Boba McWhirterja, je bila, izdelati jezik, ki bi ponujal izraznost in moč, primerljivo z dvojcem python/ruby, vendar bi bil kar v največji meri vezan na javansko skladnjo, uporabljal bi standardne predmete (pre)bogate javanske izvajalne knjižnice in bi se prevedel v standardno javansko vmesno kodo. Seveda bi moral biti razvit v javi in odprtokodnega značaja, da ga lahko skupnost zainteresiranih programerjev proučuje, izpopolnjuje in s tem tudi z veseljem uporablja. Programski jezik je v tem trenutku še kako živ, nad njegovim razvojem pa bdi strokovna skupina, zbrana okoli pobude novega javanskega standarda JSR 241 [1], torej je prihodnost jezika prepuščena uveljavljenemu postopku standardizacije JCP (Java Community Process). Jezik se skozi ta proces sicer razvija nekoliko počasneje, vendar sta zagotovljeni široka podpora in strokovna utemeljenost vseh morebitnih sprememb in dopolnitev, ki še pridejo.

    Skriptni jezik za javo

    JVMju v resnici ni mar, v katerem programskem jeziku je bila napisana izvirna koda, razume le prevedeno, vmesno kodo. To idejo je do skrajnosti prignal Microsoft, ki je v svojem klonu jave, ogrodju .net, ponudbo najrazličnejših programskih jezikov, ki se vsi skupaj prevedejo v enako vmesno kodo (v primeru ogrodja .net je to vmesni jezik IL, Intermediate Language), razširil skoraj čez vse razumne meje. Tudi javanski tabor ni ostal brez odgovora, standardnim izvajalnim strojem so bili prilagojeni številni prevajalniki. Tako sta nastala npr. jython (izpeljanka pythona) in jruby. Navkljub pomembni niši, ki sta ju omenjena jezika izpolnila, pa za javanske programerje nista najprimernejši skriptni ponudbi. Na koncu koncev gre za popolnoma drugačna jezika, s drugačno filozofijo in programskimi knjižnicami, ki prekaljenega "javanca" izzoveta z novim učenjem in prilagajanjem. Osnovni namen skriptnega jezika - hiter in učinkovit razvoj - je s tem praktično izničen.

    Seveda pa ni mogoče odprtokodnih sistemov CMS zgolj opevati. Nekatere slabosti so sestavni del odprtokodnega sveta in jim moramo vzeti v zakup.

    Slabosti odprtokodnih sistemov

    Preizkušanje lahko razkrije težave, ki nam pomenijo resno oviro za uporabo sistema. Medtem ko bi se pri komercialnem sistemu lahko ob tem le ozrli stran, si pri odprti kodi še vedno lahko privoščimo prijavo težave skupnosti ali kar neposredno razvijalcem izdelka. Neredko se bodo hitro odzvali in morda sistem brezplačno prilagodili prav zaradi nas, še posebej, če smo odkrili zares bolečo pomanjkljivost.

    Nevarnost, da bi nasedli obljubam tržnega oddelka in resno pomanjkljivost v sistemu odkrili šele za tem, ko odštejemo lepe denarce, je tako precej manjša. Seveda je znova mogoče na pomoč priklicati skupnost uporabnikov, ki nam lahko svetuje skozi lastne izkušnje. Zanimiv pojav pri skoraj vseh odprtokodnih sistemih je iskrena želja večine uporabnikov, da prispevajo k dobrobiti celotnega projekta in hkrati neusmiljena kritika do očitnih pomanjkljivosti. Slabe rešitve, ki so zasnovane na napačnih predpostavkah, so zato precej pogosto izločene že na začetku.

    Preizkušanje

    Ker je odločitev o ustreznem sistemu CMS vse prej kot lahka, je pomembna prednost odprtokodnih sistemov tudi možnost neomejenega preizkušanja. Skoraj vsi ponudniki omogočajo živi preizkus zmožnosti izdelka brez kakršnegakoli nameščanja. Preprosto obiščemo njihove spletne strani, kjer najdemo geslo za dostop do preizkusnega strežnika.

    Odprtokodni sistemi so seveda znova v prednosti iz več razlogov. Prvi je jasno odprta in dostopna izvirna koda, kar nam omogoča preučevanje delovanja in poljubno razširjanje zmogljivost, če imamo ustrezno znanje, oz. smo ga pripravljeni plačati komurkoli, ki ga ima namesto nas. Vendar to ni vse. Omenili smo že prednost odprtih standardov, na katerih so ti sistemi tipično zgrajeni. Odprtokodni sistemi večinoma temeljijo tudi na odprtokodni podlagi (zgoraj omenjeni LAMP je v celoti odprta koda). To še povečuje možnost prilagajanja in širi skupino programerjev, ki nam lahko pomaga pri reševanju problemov. Možnost prostega razpolaganja s kodo hkrati omogoča vsem uporabnikom istega sistema, da združijo moči in skupaj razvijejo prilagoditve, ki jih potrebujejo. Za razliko od komercialnih ponudnikov, pri katerih se podpora tipično odvija v zaprtem krogu, ki ga definirajo drage vzdrževalne pogodbe, imajo odprtokodni sistemi vedno tudi široko zaledje skupnosti, ki jo sestavljajo tako avtorji kot uporabniki. Na javno dostopnih spletiščih lahko dejavno spremljamo reševanje težav ali vlagamo želje po dodatnih zmožnostih.

    Ker odprtokodni sistemi ne pomenijo visokega stroška vzpostavitve, se lahko več denarja nameni za njihovo prilagajanje, čemur so tudi namenjeni. Sistem CMS je namreč dober prav toliko, kolikor je učinkovito njegovo prilagajanje našim potrebam. Prilagajanje je trajen in sorazmerno drag proces, ki zajema:

    določanje videza strani, slogov besedila in druge vsebine;

    prilagajanje sistema CMS specifičnim potrebam našega spletišča;

    povezovanje sistema CMS z drugimi, že delujočimi viri vsebin;

    preizkušanje delovanja in uporabnosti;

    uvajanje uporabnikov, od vnašalcev do urednikov in upraviteljev;

    tekoče vzdrževanje delujočega sistema;

    nadgradnje in dopolnitve.

    Vse te in še nekatere manj izražene podrobnosti praktično v celoti odločajo o uspehu celotnega projekta. Izbira ustreznega sistema CMS je zgolj prvi korak, v katerem ne smemo izgubiti osredotočenosti na temeljni problem: vsebino in njeno upravljanje. Posamezne tehnične podrobnosti posameznih ponudnikov, ki se na prvi pogled lahko zdijo velikanska prednost, lahko skopnijo takoj, ko se soočimo npr. s slabo dokumentacijo istega sistema, ki nam onemogoči učinkovito prilagajanje.

    Vsekakor pa je nevarnost, da bomo pri izbiranju ustreznega sistema CMS porabili preveč časa. Spletišče OSCOM (Open Source COntent Management, http://www.oscom.org/) našteva kar 17 ogrodij za izdelavo lastnih sistemov in več kot 40 izdelanih odprtokodnih sistemov CMS. Spet drugo spletišče, CMS Matrix (http://www.cmsmatrix.org/matrix), kjer lahko nazorno primerjamo zmožnosti teh sistemov, ponuja izbiro kar 274 izdelkov!

    Izbor sistema

    Pravzaprav je nekakšna slabost odprtokodnih sistemov CMS tudi zelo široka izbira. To je v svetu odprte kode nasploh problem, saj preprosta vejitev kodne osnove v drugačno različico ne pomeni nobene večje težave, če se le najde manjša nezadovoljna skupina programerjev. Res pa ta problem pesti predvsem izdelke, s kakovostjo katerih je le redko kdo zadovoljen.

    Čeprav niso najbolj tipičen zgled, pa tudi pri odprtokodnih sistemih CMS lahko naletimo na prevelik "tehnicizem". Številna orodja so delo zagnanih programerjev, ki najpogosteje nimajo pravega razumevanja za potrebe tipičnega uporabnika. Čeprav so njihovi izdelki tehnološko izpiljeni, jim manjka uporabniške prijaznosti. Na srečo je pri sistemih CMS ta slabost redkeje izražena, saj so navsezadnje namenjeni prav lažjemu delu. Poleg tega zelo bogata izbira sili njihove tvorce, da razmišljajo tudi o preprostosti uporabe. Zapletenih sistemov CMS je tako ali tako preveč.

    Odprtokodni sistemi CMS, za katerimi ne stoji tržno usmerjeno podjetje, pogosto muči stanje nenehnega preizkušanja. Izdelek v resnici nikoli ni končan, ker ni pravega pritiska, da bi zares bil. Marsikateri sistem CMS se je skozi povsem dobre namene docela izrodil in vsi, ki so verjeli vanj, so verjetno izgubili precej časa in denarja, morda celo zaman. Vendar številne odprtokodne sisteme CMS podpira tržno usmerjeno podjetje, ki pač svoj dobiček dobi s prodajo drugih, povezanih storitev, ne pa samega izdelka.

    Le redki sistemi CMS so primerni za poslovno rabo v velikih organizacijah z zapletenimi pravili upravljanja vsebin. To še posebej velja za odprtokodne različice, ki so kot po pravilu namenjene predvsem majhnim in srednje velikim podjetjem ter organizacijam.

    Pri odprtokodnih sistemih bomo pogosto pogrešali preprost in jasen postopek namestitve na našo strojno opremo. Pogosto je treba namestiti cel kup programske infrastrukture najrazličnejših ponudnikov, jo tu in tam pokrpati z različnimi popravki in dodatki in šele na to osnovo namestiti sam sistem CMS, ki najpogosteje tudi ne pozna enega samega namestitvenega paketa.

    Potencialno težavo zaradi dovoljenja za rabo smo že omenili, zato zgolj ponovimo, da moramo pred dokončno odločitvijo podrobno preučiti pogoje rabe odprte kode. Nekateri sistemi ne vsiljujejo prav nobenih omejitev, spet drugje so lahko pravila precej zapletena in težko razumljiva. Prav tako se moramo zavedati, da brezplačnost same osnove, torej sistema CMS, nikakor ne pomeni, da bomo prišli skozi zastonj. Sam sistem je zanemarljiv strošek proti vsem prizadevanjem (in denarju), ki ga bomo morali vložiti najprej v spoznavanje sistema in zatem v njegovo prilagajanje in uporabo.

    Velikansko pomoč pri preizkušanju (pre)številnih sistemov CMS nam ponuja posebno spletišče, OpensourceCMS (http://www.opensourcecms.com/). Tu lahko najdemo preizkusne namestitve praktično vseh boljših sistemov CMS, ki izkoriščajo skriptni jezik PHP in podatkovni strežnik MySQL. Na voljo nam je dostop do javnih in nadzornih strani vsakega sistema, z njimi pa se lahko igramo po mili volji, saj se namestitve obnovijo vsaki dve uri (na polno uro).

    Izmed naštetih kriterijev nam bodo nekateri bolj, drugi manj pomembni. Številne bomo lahko preverili le s preizkusom sistema, s čimer na srečo pri odprtokodni ponudbi ni večjih težav.

    Zaščita in prenos vsebine. Kako je poskrbljeno za izdelavo rezervnih kopij podatkov in njihov morebiten prenos na drug sistem?

    Enostavnost prilagajanja. Kako hitro smo se znašli v sistemu?

    Enostavnost urejevalnikov. Ali sistem podpira urejanje "videz ne vara" (WYSIWYG)? V katerih spletnih brskalnikih je to mogoče (zgolj IE ali tudi drugih, ki že podpirajo vizualno urejanje, kot so Firefox/Mozilla, Safari, Opera)? Kako zapleteno je upravljanje večpredstavnih vsebin?

    Večjezičnost. Ali so podprti jeziki, ki jih potrebujemo, tako v javnem delu kot v modulih za upravljanje sistema?

    Dodatki. Kako široka je skupnost, ki razvija dodatke za sistem? So med dodatki kakšni, ki bi znatno poenostavili prilagoditev sistema našim potrebam?

    Varnost. Kakšne omejitve dostopa do posameznih vsebin sistem podpira? Se lahko povezuje z obstoječimi sistemi preverjanja uporabnikov (npr. LDAP)?

    Programski jezik. V katerem programskem jeziku je koda sistema? Imamo možnost to kodo dopolnjevati ali kupiti programsko podporo za nadgradnje zmogljivosti?

    Odprti standardi. Na kakšnih standardih izdelek temelji? Kako hrani vsebino in kako jo ponuja uporabnikom?

    Dovoljenje za uporabo. Ali so sistemi popolnoma prosti ali pa dovoljenje skriva kakšne podrobnosti, ki nam niso všeč? Večina sistemov je na voljo pod dovoljenjem GPL, ki zahteva, da morebitne dopolnitve vrnemo skupnosti v obliki izvirne kode. Dovoljenje LGPL te zahteve nima, kot je nima tudi dovoljenje BSD. Nekateri sistemi so na voljo popolnoma brez omejitev, drugi pa so na voljo pod različnimi pogoji, odvisno od namena rabe.

    Podpora. Je za sistem na voljo komercialna podpora, ki jo v skrajni sili lahko najamemo? Ali pa ima morda sistem tako široko skupnost uporabnikov, da bomo morebitne težave kljub pomanjkanju komercialnega ponudnika podpore vseeno odpravili?

    Podlaga. Na katerih operacijskih sistemih, kakšnem spletnem ter podatkovnem (ali programskem) strežniku se sistem izvaja? Kakšno programsko ogrodje potrebuje? Bomo sistem lahko neboleče namestili?

    Pri taki izbiri je največja napaka, ki jo lahko storimo, preveliko zaupanje priporočilu. Odločitev za ustrezen sistem CMS mora temeljiti na naših jasnih zahtevah. Kar ustreza enemu, ki navdušeno uporablja določen sistem, nam morda ne bo dovolj ali pa bo celo razlog, da nam isti sistem ne bo všeč. Na srečo lahko z jasno postavljenimi kriteriji hitro precej oklestimo razpoložljive kandidate. Pomembna merila, ki znatno vplivajo na izbor, so:

    Xaraya je popeljala kodno osnovo v PHPju proti pravemu sistemu CMS. Na novo zasnovana zgradba sistema je neodvisna od izbranega podatkovnega strežnika in ločuje videz, vsebino, delovanje in upravljanje. Razvija jo več kot štirideset programerjev po vsem svetu in dobro podpira večjezičnost.

    Envolution je gradil iz PostNuke, vendar je bila koda skoraj v celoti nadomeščena z robustnejšo in zmogljivejšo. To mu omogoča, da prenese visoke obremenitve. Prednosti sistema Envolution so: popolna prilagodljivost videza spletnih strani skozi predloge, medpomnjenje izdelanih strani za večjo odzivnost, precej lažje upravljanje, široka skupnost razvijalcev, ki ponujajo precejšnjo podporo.

    Najpomembnejša izpeljana različica PHP Nuke je PostNuke (http://www.postnuke.com/), ki je znano osnovo precej izboljšala. Žal pa tudi tvorci PostNuke niso ostali enotni, zato projekt trpi zaradi notranjih bojev, vsaka nova različica pa prinese skoraj toliko novih hroščev, kot je novih zmožnosti. PostNuke je zato rodil še več novih sistemov, kot so Envolution (http://www.envolution.com/), Xaraya (http://www.xaraya.com/) ali Xoops (http://www.xoops.org/).

    Vsekakor PHP Nuke ni za vsakogar, z njim se bodo dobro razumeli predvsem razvijalci, ki jim je PHP blizu in bi radi od blizu spoznali delovanje zapletenega sistema v njem.

    Po množičnosti uporabe je PHP Nuke še vedno najbolj razširjen odptokodni sistem za objavljanje v spletu in ga zato pozna zelo veliko spletnih razvijalcev. Ti so zanj razvili skoraj neskončno število dodatkov, žal pa to zgolj oteži njegovo prilagajanje, saj je izbira pogosto prevelika, številni dodatki pa so kljub vloženemu trudu pogosto nepopolni, predvsem pa med seboj slabo združljivi. Največ dodatkov je posvečenih izgradnji spletne skupnosti (različni forumi, pogovori, ankete...).

    Javna stran sveže nameščenega PHP Nuke, nekateri elementi so prevedeni v slovenščino.

    Osnovni PHP Nuke tako ni pravi sistem za upravljanje vsebin, temveč je v osnovi sistem za avtomatizacijo objav novic, ki pa je v letih razvoja pridobil številne dodatke in razvil izjemno skupnost. Celotna koda se razvija v skriptnem jeziku PHP in se lahko izvaja bodisi v strežniku Apache z dodatkom mod_perl, bodisi v Oknih na strežniku IIS z nameščenim tolmačem za PHP. Najbolj se znajde s podatkovnim strežnikom MySQL, lahko pa ga uporabljamo tudi z drugimi, npr. PostgreSQL.

    Tabela sistemov CMS

    PHP Nuke, PostNuke in znanci

    PHP Nuke (http://phpnuke.org/) je eden prvih odprtokodnih sistemov za lažje objavljanje in vzdrževanje vsebin v spletu. Med zagovorniki odprte kode je neznansko uspešno spletišče Slashdot (http://slashdot.org/), ki prinaša vsak dan svež seznam novic, ki se jih na dolgo in široko komentira. Skupnost obiskovalcev spletišča je tako velika, da spletna povezava, omenjena med novico, neredko doživi t. i. "slashdot efekt", saj strežnik zaradi nenadnega navala obiskovalcev, napotenih s Slashdota, preprosto klecne. Čeprav je tudi koda Slashdota na voljo pod dovoljenjem GPL in se uporablja na številnih drugih spletiščih, ga je po priljubljenosti med razvijalci odločno prekosil njegov "klon" v PHPju, Slashdot je namreč izdelan s pomočjo kode v perlu. Prvi PHP Nuke je v treh tednih razvil očitno genialni Francisco Burzi, projekt pa je pretrpel že nič koliko vejitev kodne osnove in številne izpeljane različice.

    Šele ko na izbranem sistemu uspešno preverimo celoten seznam svojih ključnih želja, si ga namestimo tudi na lastno strojno opremo. Čeprav postopki namestitve praviloma niso najpreprostejši, pa sistema ne smemo soditi po njihovi zapletenosti, saj bomo namestitev opravili redko. Enostavnost rabe nameščenega sistema je ključna.

    Plone ima veliko prednost v tem, da lahko celoten sistem preprosto namestimo, saj ponuja namestitveni program za Okna, MacOS X in Linux. Za namestitev tudi ne potrebujemo uporabniškega imena upravitelja (root), saj je celoten sistem pravzaprav uporabniški program. V Oknih imamo na voljo celo poseben nadzorni program za spremljanje delovanja sistema. Celoten nadzor sicer opravljamo, kot je pri teh sistemih v navadi, prek spletnega vmesnika. Takoj po namestitvi imamo pred sabo zgleden in zelo uporaben sistem, seveda pa ga bomo zelo verjetno želeli vsaj nekoliko preoblikovati. Ena od slabosti, ki pesti večino sistemov CMS, je namreč velika podobnost vseh spletišč na isti podlagi, ki že na daleč izdaja sistem.

    Privzeta stran sveže nameščenega sistema Plone je lična in zelo uporabna brez posebnih dodatnih nastavitev. Seveda je v temeljnem videzu Plona pripravljena tudi njegova domača stran.

    Programski strežnik Zope ponuja spletni vmesnik za upravljanje, skozi katerega lahko urejamo predloge in nadziramo predmetno zbirko podatkov. Zope je lahko samostojen spletni strežnik, čeprav se pogosto uporablja v ozadju, za bolj običajnim Apache, zaradi dodatne varnosti, zmogljivosti in medpomnjenja. Zope je nekoč uporabljal svoj skriptni jezik za opisovanje poslovne logike, danes pa vse temelji na predlogah XML in skriptni kodi v pythonu. Tako je razvito tudi ogrodje za sistem CMS, poimenovano CMF (Content Management Framework), ki ga izkorišča Plone. Plone nadzira videz, sloge, gradnike spletnih strani, vsebinske tipe itd. Za delo z vsebinami uporabljamo vnaprej pripravljene kategorije oz. arhetipe (archetypes), ki jih lahko poljubno dopolnjujemo. Ti lahko med seboj sodelujejo prek mehanizma dogodkov (events). Za upravljanje Plona se moramo potopiti v številne sloje, včasih celo nazaj do predlog strežnika Zope, kar je lahko prednost ali pa slabost, odvisno od tega, ali nas zanima prilagodljivost ali preprostost rabe.

    Zope in Plone

    Sredi lanskega leta je skupnost uporabnikov sistemov CMS razburkal izbor znane revije eWeek, ki je sistem za upravljanje vsebin Plone razglasila za najboljšega po izboru analitikov in to potrdila tudi konec leta, ko se je izdelek znašel v družbi desetih programerskih izdelkov leta. Vsekakor velikanski kompliment za brezplačen, odprtokodni izdelek v jeziku python, ki se bori za svoj delež na zelo obljudenem trgu, kjer vodilni komercialni ponudniki za svoje izdelke zaračunavajo včasih prav neverjetne vsote.

    Plone gradi na podlagi zmogljivega programskega strežnika Zope, prav tako razvitega v pythonu. Najpomembnejše prednosti kombinacije Zope/Plone so: zmogljiva podpora delovnemu toku dokumentov, skladnost s številnimi spletnimi standardi, napredna varnostna arhitektura. Temeljna značilnost Plona je njegova predmetna osnova, saj celo podatke hrani v predmetni zbirki (in ne v običajni relacijski, ki je temelj skoraj vseh drugih sistemov). To zna marsikateremu uporabniku zagreniti življenje, dokler se s sistemom ne spozna podrobneje. Poznejše prednosti predmetne zasnove so seveda pri vzdrževanju sistema neprecenljive.

    Xoops je predmetno usmerjena predelava PostNuke in je zato najprimernejši za hitro izgradnjo spletnih skupnosti, saj ponuja zelo dobra orodja za delo z uporabniki. Njegova prednost je tudi integrirana relacijska zbirka vsebin, Wiki.

    Nadzorna plošča administracijskega dela PHP Nuke.

    PHP Nuke in njegove izpeljanke so marsikomu nenadomestljivo orodje, žal pa niso najpreprostejše za rabo in se jih upravičeno drži (slab) sloves izdelka "programerjev za programerje". Na srečo lahko vse skupaj precej neboleče preizkusimo na spletišču OpensourceCMS in hitro preverimo, ali nam vsaj v grobem ustrezajo.

    Odprtokodni sistemi CMS so zato doživeli razcvet. Najuspešnejši ponudniki so lahko preživeli s prodajo prilagoditev in vzdrževanja, sama osnova pa je ostala brezplačna, odprta in pripravljena za širitev zmogljivosti. Danes so vodilni odprtokodni sistemi CMS povsem primerljivi s svojimi komercialnimi vzorniki, marsikje pa jih celo prekašajo. Številnim spletnim mojstrom je dodatna motivacija pri izbiri odprtokodnega sistema možnost preučevanja notranjega ustroja in vpliv na nadaljnji razvoj podlage. Če bi, denimo, podjetje, ki prodaja zaprt, komercialen sistem CMS propadlo, bi se njegovi uporabniki znašli v silni stiski. Odprta koda to nevarnost odpravlja, saj je podpora izdelovalca sicer še vedno pomembna, vendar v skrajnem primeru nadomestljiva, bodisi s prevzemom projekta s strani skupnosti uporabnikov bodisi s plačilom storitve nadaljnjega razvoja komurkoli, ki ima ustrezno znanje. Koda je odprta in na voljo vsakomur. Ta lastnost je še toliko bolj izražena zato, ker odprtokodni sistemi CMS skoraj brez izjeme temeljijo na odprtih ali vsaj dejanskih standardih, tako da je izbira programerjev, ki lahko gradijo na pripravljeni osnovi, vedno dovolj velika.

    Odprta koda

    Z rastjo uporabe interneta se je povečevala tudi uporaba odprte kode, ki je danes marsikje učinkovita alternativa "klasičnim" programskim rešitvam. Še več, prav prosto- in odprtokodni programi sestavljajo hrbtenico programja za internet, spomnimo se zgolj spletnega strežnika Apache. S podporo odprti kodi tudi s strani vodilnih igralcev v računalniški industriji je ta pridobila potrebno zaupanje tudi pri zainteresirani javnosti.

    Prav trg sistemov CMS je doživel izjemen razcvet ponudbe skozi odprtokodne rešitve. Najverjetneje je vzrok tolikšne izbire učinkovita podlaga - predstavlja jo predvsem kratica LAMP (operacijski sistem Linux, spletni strežnik Apache, podatkovni strežnik MySQL ter skriptni programski jezik PHP oz. perl oz. python) - na kateri so ti sistemi razviti. Drug razlog izbruha odprtokodnih sistemov CMS je precej nerazumna cenovna politika komercialnih ponudnikov različnih dveri in sistemov za upravljanje vsebin, ki jo morda lahko opravičijo v velikih organizacijah in javno financiranih sistemih, težko pa bi se zanje odločilo malo ali srednje veliko podjetje, katerega potrebe po objavi v spletu niso prav nič manjše, prej nasprotno.

    Kaj je CMS?

    Sistem CMS je programska rešitev, ki omogoča nadzor celotnega življenjskega cikla vsebine. Tak cikel zajema ustvarjanje, upravljanje, urejanje, objavo, preiskovanje in pravočasno odstranjevanje ter arhiviranje. Ključni element, ki ločuje sistem CMS od običajnega orodja za pripravo in objavo spletne strani, je urejena shramba vsebine, ki nam omogoča vse storitve sistema, kot so npr. vnaprej določen delovni tok dokumentov (document workflow), nadzor različic (versioning), zaščito izbranih vsebin (access control), učinkovito preiskovanje ali pa časovno odvisna objava.

    Ustrezen sistem CMS bi seveda lahko upravljal poljubno vsebino, vendar se najpogosteje uporabljajo prav za urejanje spletišč, ki so, kot smo omenili, danes najbolj plodna tla za nove vsebine. Učinkovit spletni sistem CMS ponuja uporabniku vrsto prednosti, kot so:

    preprostejše ustvarjanje kakovostne vsebine, ki je skladna z vnaprej določeno podobo;

    možnost upravljanja na daljavo;

    boljše sodelovanje med različnimi ustvarjalci;

    lažji nadzor nad časovno kritičnimi elementi za objavo in učinkovitejša zamenjava zastarelih vsebin;

    visoka prilagodljivost in preprosto dodajanje novih zmožnosti;

    večja varnost;

    lažje stopnjevanje obsega;

    nižji stroški vzdrževanja.

    Seveda so naštete prednosti predvsem ideali, ki se jim želijo različni sistemi CMS bolj ali manj uspešno približati. Nedvomno pa so danes ti sistemi že dosegli stopnjo, ko njihove prednosti niso več vprašljive. Težave s CMS se skrivajo drugje, kot bomo spoznali v nadaljevanju.

    Storitve

    Treba je omeniti različna dovoljenja za uporabo, ki se od sistema do sistema lahko zelo razlikujejo. Brezplačno pogosto ne pomeni tudi brezplačno pod vsakimi pogoji rabe. Nekateri odprtokodni sistemi CMS zahtevajo plačilo za uporabo v komercialne namene, drugi zahtevajo objavo izvirne kode vseh dopolnitev, ki jih bomo morda razvili. Vsekakor se moramo pred odločitvijo za posamezen sistem podrobno seznaniti s pogoji rabe, da ne bomo pozneje presenečeni.

    Kaj je CMS?

    Sistem CMS je programska rešitev, ki omogoča nadzor celotnega življenjskega cikla vsebine. Tak cikel zajema ustvarjanje, upravljanje, urejanje, objavo, preiskovanje in pravočasno odstranjevanje ter arhiviranje. Ključni element, ki ločuje sistem CMS od običajnega orodja za pripravo in objavo spletne strani, je urejena shramba vsebine, ki nam omogoča vse storitve sistema, kot so npr. vnaprej določen delovni tok dokumentov (document workflow), nadzor različic (versioning), zaščito izbranih vsebin (access control), učinkovito preiskovanje ali pa časovno odvisna objava.

    Ustrezen sistem CMS bi seveda lahko upravljal poljubno vsebino, vendar se najpogosteje uporabljajo prav za urejanje spletišč, ki so, kot smo omenili, danes najbolj plodna tla za nove vsebine. Učinkovit spletni sistem CMS ponuja uporabniku vrsto prednosti, kot so:

    preprostejše ustvarjanje kakovostne vsebine, ki je skladna z vnaprej določeno podobo;

    možnost upravljanja na daljavo;

    boljše sodelovanje med različnimi ustvarjalci;

    lažji nadzor nad časovno kritičnimi elementi za objavo in učinkovitejša zamenjava zastarelih vsebin;

    visoka prilagodljivost in preprosto dodajanje novih zmožnosti;

    večja varnost;

    lažje stopnjevanje obsega;

    nižji stroški vzdrževanja.

    Seveda so naštete prednosti predvsem ideali, ki se jim želijo različni sistemi CMS bolj ali manj uspešno približati. Nedvomno pa so danes ti sistemi že dosegli stopnjo, ko njihove prednosti niso več vprašljive. Težave s CMS se skrivajo drugje, kot bomo spoznali v nadaljevanju.

    Odprta koda

    Z rastjo uporabe interneta se je povečevala tudi uporaba odprte kode, ki je danes marsikje učinkovita alternativa "klasičnim" programskim rešitvam. Še več, prav prosto- in odprtokodni programi sestavljajo hrbtenico programja za internet, spomnimo se zgolj spletnega strežnika Apache. S podporo odprti kodi tudi s strani vodilnih igralcev v računalniški industriji je ta pridobila potrebno zaupanje tudi pri zainteresirani javnosti.

    Prav trg sistemov CMS je doživel izjemen razcvet ponudbe skozi odprtokodne rešitve. Najverjetneje je vzrok tolikšne izbire učinkovita podlaga - predstavlja jo predvsem kratica LAMP (operacijski sistem Linux, spletni strežnik Apache, podatkovni strežnik MySQL ter skriptni programski jezik PHP oz. perl oz. python) - na kateri so ti sistemi razviti. Drug razlog izbruha odprtokodnih sistemov CMS je precej nerazumna cenovna politika komercialnih ponudnikov različnih dveri in sistemov za upravljanje vsebin, ki jo morda lahko opravičijo v velikih organizacijah in javno financiranih sistemih, težko pa bi se zanje odločilo malo ali srednje veliko podjetje, katerega potrebe po objavi v spletu niso prav nič manjše, prej nasprotno.

    Odprtokodni sistemi CMS so zato doživeli razcvet. Najuspešnejši ponudniki so lahko preživeli s prodajo prilagoditev in vzdrževanja, sama osnova pa je ostala brezplačna, odprta in pripravljena za širitev zmogljivosti. Danes so vodilni odprtokodni sistemi CMS povsem primerljivi s svojimi komercialnimi vzorniki, marsikje pa jih celo prekašajo. Številnim spletnim mojstrom je dodatna motivacija pri izbiri odprtokodnega sistema možnost preučevanja notranjega ustroja in vpliv na nadaljnji razvoj podlage. Če bi, denimo, podjetje, ki prodaja zaprt, komercialen sistem CMS propadlo, bi se njegovi uporabniki znašli v silni stiski. Odprta koda to nevarnost odpravlja, saj je podpora izdelovalca sicer še vedno pomembna, vendar v skrajnem primeru nadomestljiva, bodisi s prevzemom projekta s strani skupnosti uporabnikov bodisi s plačilom storitve nadaljnjega razvoja komurkoli, ki ima ustrezno znanje. Koda je odprta in na voljo vsakomur. Ta lastnost je še toliko bolj izražena zato, ker odprtokodni sistemi CMS skoraj brez izjeme temeljijo na odprtih ali vsaj dejanskih standardih, tako da je izbira programerjev, ki lahko gradijo na pripravljeni osnovi, vedno dovolj velika.

    Treba je omeniti različna dovoljenja za uporabo, ki se od sistema do sistema lahko zelo razlikujejo. Brezplačno pogosto ne pomeni tudi brezplačno pod vsakimi pogoji rabe. Nekateri odprtokodni sistemi CMS zahtevajo plačilo za uporabo v komercialne namene, drugi zahtevajo objavo izvirne kode vseh dopolnitev, ki jih bomo morda razvili. Vsekakor se moramo pred odločitvijo za posamezen sistem podrobno seznaniti s pogoji rabe, da ne bomo pozneje presenečeni.

    Storitve

    Ker odprtokodni sistemi ne pomenijo visokega stroška vzpostavitve, se lahko več denarja nameni za njihovo prilagajanje, čemur so tudi namenjeni. Sistem CMS je namreč dober prav toliko, kolikor je učinkovito njegovo prilagajanje našim potrebam. Prilagajanje je trajen in sorazmerno drag proces, ki zajema:

    določanje videza strani, slogov besedila in druge vsebine;

    prilagajanje sistema CMS specifičnim potrebam našega spletišča;

    povezovanje sistema CMS z drugimi, že delujočimi viri vsebin;

    preizkušanje delovanja in uporabnosti;

    uvajanje uporabnikov, od vnašalcev do urednikov in upraviteljev;

    tekoče vzdrževanje delujočega sistema;

    nadgradnje in dopolnitve.

    Vse te in še nekatere manj izražene podrobnosti praktično v celoti odločajo o uspehu celotnega projekta. Izbira ustreznega sistema CMS je zgolj prvi korak, v katerem ne smemo izgubiti osredotočenosti na temeljni problem: vsebino in njeno upravljanje. Posamezne tehnične podrobnosti posameznih ponudnikov, ki se na prvi pogled lahko zdijo velikanska prednost, lahko skopnijo takoj, ko se soočimo npr. s slabo dokumentacijo istega sistema, ki nam onemogoči učinkovito prilagajanje.

    Odprtokodni sistemi so seveda znova v prednosti iz več razlogov. Prvi je jasno odprta in dostopna izvirna koda, kar nam omogoča preučevanje delovanja in poljubno razširjanje zmogljivost, če imamo ustrezno znanje, oz. smo ga pripravljeni plačati komurkoli, ki ga ima namesto nas. Vendar to ni vse. Omenili smo že prednost odprtih standardov, na katerih so ti sistemi tipično zgrajeni. Odprtokodni sistemi večinoma temeljijo tudi na odprtokodni podlagi (zgoraj omenjeni LAMP je v celoti odprta koda). To še povečuje možnost prilagajanja in širi skupino programerjev, ki nam lahko pomaga pri reševanju problemov. Možnost prostega razpolaganja s kodo hkrati omogoča vsem uporabnikom istega sistema, da združijo moči in skupaj razvijejo prilagoditve, ki jih potrebujejo. Za razliko od komercialnih ponudnikov, pri katerih se podpora tipično odvija v zaprtem krogu, ki ga definirajo drage vzdrževalne pogodbe, imajo odprtokodni sistemi vedno tudi široko zaledje skupnosti, ki jo sestavljajo tako avtorji kot uporabniki. Na javno dostopnih spletiščih lahko dejavno spremljamo reševanje težav ali vlagamo želje po dodatnih zmožnostih.

    Preizkušanje

    Ker je odločitev o ustreznem sistemu CMS vse prej kot lahka, je pomembna prednost odprtokodnih sistemov tudi možnost neomejenega preizkušanja. Skoraj vsi ponudniki omogočajo živi preizkus zmožnosti izdelka brez kakršnegakoli nameščanja. Preprosto obiščemo njihove spletne strani, kjer najdemo geslo za dostop do preizkusnega strežnika.

    Nevarnost, da bi nasedli obljubam tržnega oddelka in resno pomanjkljivost v sistemu odkrili šele za tem, ko odštejemo lepe denarce, je tako precej manjša. Seveda je znova mogoče na pomoč priklicati skupnost uporabnikov, ki nam lahko svetuje skozi lastne izkušnje. Zanimiv pojav pri skoraj vseh odprtokodnih sistemih je iskrena želja večine uporabnikov, da prispevajo k dobrobiti celotnega projekta in hkrati neusmiljena kritika do očitnih pomanjkljivosti. Slabe rešitve, ki so zasnovane na napačnih predpostavkah, so zato precej pogosto izločene že na začetku.

    Preizkušanje lahko razkrije težave, ki nam pomenijo resno oviro za uporabo sistema. Medtem ko bi se pri komercialnem sistemu lahko ob tem le ozrli stran, si pri odprti kodi še vedno lahko privoščimo prijavo težave skupnosti ali kar neposredno razvijalcem izdelka. Neredko se bodo hitro odzvali in morda sistem brezplačno prilagodili prav zaradi nas, še posebej, če smo odkrili zares bolečo pomanjkljivost.

    Slabosti odprtokodnih sistemov

    Seveda pa ni mogoče odprtokodnih sistemov CMS zgolj opevati. Nekatere slabosti so sestavni del odprtokodnega sveta in jim moramo vzeti v zakup.

    Potencialno težavo zaradi dovoljenja za rabo smo že omenili, zato zgolj ponovimo, da moramo pred dokončno odločitvijo podrobno preučiti pogoje rabe odprte kode. Nekateri sistemi ne vsiljujejo prav nobenih omejitev, spet drugje so lahko pravila precej zapletena in težko razumljiva. Prav tako se moramo zavedati, da brezplačnost same osnove, torej sistema CMS, nikakor ne pomeni, da bomo prišli skozi zastonj. Sam sistem je zanemarljiv strošek proti vsem prizadevanjem (in denarju), ki ga bomo morali vložiti najprej v spoznavanje sistema in zatem v njegovo prilagajanje in uporabo.

    Odprtokodni sistemi CMS, za katerimi ne stoji tržno usmerjeno podjetje, pogosto muči stanje nenehnega preizkušanja. Izdelek v resnici nikoli ni končan, ker ni pravega pritiska, da bi zares bil. Marsikateri sistem CMS se je skozi povsem dobre namene docela izrodil in vsi, ki so verjeli vanj, so verjetno izgubili precej časa in denarja, morda celo zaman. Vendar številne odprtokodne sisteme CMS podpira tržno usmerjeno podjetje, ki pač svoj dobiček dobi s prodajo drugih, povezanih storitev, ne pa samega izdelka.

    Le redki sistemi CMS so primerni za poslovno rabo v velikih organizacijah z zapletenimi pravili upravljanja vsebin. To še posebej velja za odprtokodne različice, ki so kot po pravilu namenjene predvsem majhnim in srednje velikim podjetjem ter organizacijam.

    Pri odprtokodnih sistemih bomo pogosto pogrešali preprost in jasen postopek namestitve na našo strojno opremo. Pogosto je treba namestiti cel kup programske infrastrukture najrazličnejših ponudnikov, jo tu in tam pokrpati z različnimi popravki in dodatki in šele na to osnovo namestiti sam sistem CMS, ki najpogosteje tudi ne pozna enega samega namestitvenega paketa.

    Čeprav niso najbolj tipičen zgled, pa tudi pri odprtokodnih sistemih CMS lahko naletimo na prevelik "tehnicizem". Številna orodja so delo zagnanih programerjev, ki najpogosteje nimajo pravega razumevanja za potrebe tipičnega uporabnika. Čeprav so njihovi izdelki tehnološko izpiljeni, jim manjka uporabniške prijaznosti. Na srečo je pri sistemih CMS ta slabost redkeje izražena, saj so navsezadnje namenjeni prav lažjemu delu. Poleg tega zelo bogata izbira sili njihove tvorce, da razmišljajo tudi o preprostosti uporabe. Zapletenih sistemov CMS je tako ali tako preveč.

    Izbor sistema

    Pravzaprav je nekakšna slabost odprtokodnih sistemov CMS tudi zelo široka izbira. To je v svetu odprte kode nasploh problem, saj preprosta vejitev kodne osnove v drugačno različico ne pomeni nobene večje težave, če se le najde manjša nezadovoljna skupina programerjev. Res pa ta problem pesti predvsem izdelke, s kakovostjo katerih je le redko kdo zadovoljen.

    Vsekakor pa je nevarnost, da bomo pri izbiranju ustreznega sistema CMS porabili preveč časa. Spletišče OSCOM (Open Source COntent Management, http://www.oscom.org/) našteva kar 17 ogrodij za izdelavo lastnih sistemov in več kot 40 izdelanih odprtokodnih sistemov CMS. Spet drugo spletišče, CMS Matrix (http://www.cmsmatrix.org/matrix), kjer lahko nazorno primerjamo zmožnosti teh sistemov, ponuja izbiro kar 274 izdelkov!

    Pri taki izbiri je največja napaka, ki jo lahko storimo, preveliko zaupanje priporočilu. Odločitev za ustrezen sistem CMS mora temeljiti na naših jasnih zahtevah. Kar ustreza enemu, ki navdušeno uporablja določen sistem, nam morda ne bo dovolj ali pa bo celo razlog, da nam isti sistem ne bo všeč. Na srečo lahko z jasno postavljenimi kriteriji hitro precej oklestimo razpoložljive kandidate. Pomembna merila, ki znatno vplivajo na izbor, so:

    Dovoljenje za uporabo. Ali so sistemi popolnoma prosti ali pa dovoljenje skriva kakšne podrobnosti, ki nam niso všeč? Večina sistemov je na voljo pod dovoljenjem GPL, ki zahteva, da morebitne dopolnitve vrnemo skupnosti v obliki izvirne kode. Dovoljenje LGPL te zahteve nima, kot je nima tudi dovoljenje BSD. Nekateri sistemi so na voljo popolnoma brez omejitev, drugi pa so na voljo pod različnimi pogoji, odvisno od namena rabe.

    Podpora. Je za sistem na voljo komercialna podpora, ki jo v skrajni sili lahko najamemo? Ali pa ima morda sistem tako široko skupnost uporabnikov, da bomo morebitne težave kljub pomanjkanju komercialnega ponudnika podpore vseeno odpravili?

    Podlaga. Na katerih operacijskih sistemih, kakšnem spletnem ter podatkovnem (ali programskem) strežniku se sistem izvaja? Kakšno programsko ogrodje potrebuje? Bomo sistem lahko neboleče namestili?

    Programski jezik. V katerem programskem jeziku je koda sistema? Imamo možnost to kodo dopolnjevati ali kupiti programsko podporo za nadgradnje zmogljivosti?

    Odprti standardi. Na kakšnih standardih izdelek temelji? Kako hrani vsebino in kako jo ponuja uporabnikom?

    Dodatki. Kako široka je skupnost, ki razvija dodatke za sistem? So med dodatki kakšni, ki bi znatno poenostavili prilagoditev sistema našim potrebam?

    Varnost. Kakšne omejitve dostopa do posameznih vsebin sistem podpira? Se lahko povezuje z obstoječimi sistemi preverjanja uporabnikov (npr. LDAP)?

    Večjezičnost. Ali so podprti jeziki, ki jih potrebujemo, tako v javnem delu kot v modulih za upravljanje sistema?

    Enostavnost urejevalnikov. Ali sistem podpira urejanje "videz ne vara" (WYSIWYG)? V katerih spletnih brskalnikih je to mogoče (zgolj IE ali tudi drugih, ki že podpirajo vizualno urejanje, kot so Firefox/Mozilla, Safari, Opera)? Kako zapleteno je upravljanje večpredstavnih vsebin?

    Enostavnost prilagajanja. Kako hitro smo se znašli v sistemu?

    Zaščita in prenos vsebine. Kako je poskrbljeno za izdelavo rezervnih kopij podatkov in njihov morebiten prenos na drug sistem?

    Izmed naštetih kriterijev nam bodo nekateri bolj, drugi manj pomembni. Številne bomo lahko preverili le s preizkusom sistema, s čimer na srečo pri odprtokodni ponudbi ni večjih težav.

    Velikansko pomoč pri preizkušanju (pre)številnih sistemov CMS nam ponuja posebno spletišče, OpensourceCMS (http://www.opensourcecms.com/). Tu lahko najdemo preizkusne namestitve praktično vseh boljših sistemov CMS, ki izkoriščajo skriptni jezik PHP in podatkovni strežnik MySQL. Na voljo nam je dostop do javnih in nadzornih strani vsakega sistema, z njimi pa se lahko igramo po mili volji, saj se namestitve obnovijo vsaki dve uri (na polno uro).

    Šele ko na izbranem sistemu uspešno preverimo celoten seznam svojih ključnih želja, si ga namestimo tudi na lastno strojno opremo. Čeprav postopki namestitve praviloma niso najpreprostejši, pa sistema ne smemo soditi po njihovi zapletenosti, saj bomo namestitev opravili redko. Enostavnost rabe nameščenega sistema je ključna.

    Tabela sistemov CMS

    PHP Nuke, PostNuke in znanci

    PHP Nuke (http://phpnuke.org/) je eden prvih odprtokodnih sistemov za lažje objavljanje in vzdrževanje vsebin v spletu. Med zagovorniki odprte kode je neznansko uspešno spletišče Slashdot (http://slashdot.org/), ki prinaša vsak dan svež seznam novic, ki se jih na dolgo in široko komentira. Skupnost obiskovalcev spletišča je tako velika, da spletna povezava, omenjena med novico, neredko doživi t. i. "slashdot efekt", saj strežnik zaradi nenadnega navala obiskovalcev, napotenih s Slashdota, preprosto klecne. Čeprav je tudi koda Slashdota na voljo pod dovoljenjem GPL in se uporablja na številnih drugih spletiščih, ga je po priljubljenosti med razvijalci odločno prekosil njegov "klon" v PHPju, Slashdot je namreč izdelan s pomočjo kode v perlu. Prvi PHP Nuke je v treh tednih razvil očitno genialni Francisco Burzi, projekt pa je pretrpel že nič koliko vejitev kodne osnove in številne izpeljane različice.

    Javna stran sveže nameščenega PHP Nuke, nekateri elementi so prevedeni v slovenščino.

    Osnovni PHP Nuke tako ni pravi sistem za upravljanje vsebin, temveč je v osnovi sistem za avtomatizacijo objav novic, ki pa je v letih razvoja pridobil številne dodatke in razvil izjemno skupnost. Celotna koda se razvija v skriptnem jeziku PHP in se lahko izvaja bodisi v strežniku Apache z dodatkom mod_perl, bodisi v Oknih na strežniku IIS z nameščenim tolmačem za PHP. Najbolj se znajde s podatkovnim strežnikom MySQL, lahko pa ga uporabljamo tudi z drugimi, npr. PostgreSQL.

    Po množičnosti uporabe je PHP Nuke še vedno najbolj razširjen odptokodni sistem za objavljanje v spletu in ga zato pozna zelo veliko spletnih razvijalcev. Ti so zanj razvili skoraj neskončno število dodatkov, žal pa to zgolj oteži njegovo prilagajanje, saj je izbira pogosto prevelika, številni dodatki pa so kljub vloženemu trudu pogosto nepopolni, predvsem pa med seboj slabo združljivi. Največ dodatkov je posvečenih izgradnji spletne skupnosti (različni forumi, pogovori, ankete...).

    Vsekakor PHP Nuke ni za vsakogar, z njim se bodo dobro razumeli predvsem razvijalci, ki jim je PHP blizu in bi radi od blizu spoznali delovanje zapletenega sistema v njem.

    Najpomembnejša izpeljana različica PHP Nuke je PostNuke (http://www.postnuke.com/), ki je znano osnovo precej izboljšala. Žal pa tudi tvorci PostNuke niso ostali enotni, zato projekt trpi zaradi notranjih bojev, vsaka nova različica pa prinese skoraj toliko novih hroščev, kot je novih zmožnosti. PostNuke je zato rodil še več novih sistemov, kot so Envolution (http://www.envolution.com/), Xaraya (http://www.xaraya.com/) ali Xoops (http://www.xoops.org/).

    Envolution je gradil iz PostNuke, vendar je bila koda skoraj v celoti nadomeščena z robustnejšo in zmogljivejšo. To mu omogoča, da prenese visoke obremenitve. Prednosti sistema Envolution so: popolna prilagodljivost videza spletnih strani skozi predloge, medpomnjenje izdelanih strani za večjo odzivnost, precej lažje upravljanje, široka skupnost razvijalcev, ki ponujajo precejšnjo podporo.

    Xaraya je popeljala kodno osnovo v PHPju proti pravemu sistemu CMS. Na novo zasnovana zgradba sistema je neodvisna od izbranega podatkovnega strežnika in ločuje videz, vsebino, delovanje in upravljanje. Razvija jo več kot štirideset programerjev po vsem svetu in dobro podpira večjezičnost.

    Xoops je predmetno usmerjena predelava PostNuke in je zato najprimernejši za hitro izgradnjo spletnih skupnosti, saj ponuja zelo dobra orodja za delo z uporabniki. Njegova prednost je tudi integrirana relacijska zbirka vsebin, Wiki.

    Nadzorna plošča administracijskega dela PHP Nuke.

    PHP Nuke in njegove izpeljanke so marsikomu nenadomestljivo orodje, žal pa niso najpreprostejše za rabo in se jih upravičeno drži (slab) sloves izdelka "programerjev za programerje". Na srečo lahko vse skupaj precej neboleče preizkusimo na spletišču OpensourceCMS in hitro preverimo, ali nam vsaj v grobem ustrezajo.

    Zope in Plone

    Sredi lanskega leta je skupnost uporabnikov sistemov CMS razburkal izbor znane revije eWeek, ki je sistem za upravljanje vsebin Plone razglasila za najboljšega po izboru analitikov in to potrdila tudi konec leta, ko se je izdelek znašel v družbi desetih programerskih izdelkov leta. Vsekakor velikanski kompliment za brezplačen, odprtokodni izdelek v jeziku python, ki se bori za svoj delež na zelo obljudenem trgu, kjer vodilni komercialni ponudniki za svoje izdelke zaračunavajo včasih prav neverjetne vsote.

    Plone gradi na podlagi zmogljivega programskega strežnika Zope, prav tako razvitega v pythonu. Najpomembnejše prednosti kombinacije Zope/Plone so: zmogljiva podpora delovnemu toku dokumentov, skladnost s številnimi spletnimi standardi, napredna varnostna arhitektura. Temeljna značilnost Plona je njegova predmetna osnova, saj celo podatke hrani v predmetni zbirki (in ne v običajni relacijski, ki je temelj skoraj vseh drugih sistemov). To zna marsikateremu uporabniku zagreniti življenje, dokler se s sistemom ne spozna podrobneje. Poznejše prednosti predmetne zasnove so seveda pri vzdrževanju sistema neprecenljive.

    Privzeta stran sveže nameščenega sistema Plone je lična in zelo uporabna brez posebnih dodatnih nastavitev. Seveda je v temeljnem videzu Plona pripravljena tudi njegova domača stran.

    Programski strežnik Zope ponuja spletni vmesnik za upravljanje, skozi katerega lahko urejamo predloge in nadziramo predmetno zbirko podatkov. Zope je lahko samostojen spletni strežnik, čeprav se pogosto uporablja v ozadju, za bolj običajnim Apache, zaradi dodatne varnosti, zmogljivosti in medpomnjenja. Zope je nekoč uporabljal svoj skriptni jezik za opisovanje poslovne logike, danes pa vse temelji na predlogah XML in skriptni kodi v pythonu. Tako je razvito tudi ogrodje za sistem CMS, poimenovano CMF (Content Management Framework), ki ga izkorišča Plone. Plone nadzira videz, sloge, gradnike spletnih strani, vsebinske tipe itd. Za delo z vsebinami uporabljamo vnaprej pripravljene kategorije oz. arhetipe (archetypes), ki jih lahko poljubno dopolnjujemo. Ti lahko med seboj sodelujejo prek mehanizma dogodkov (events). Za upravljanje Plona se moramo potopiti v številne sloje, včasih celo nazaj do predlog strežnika Zope, kar je lahko prednost ali pa slabost, odvisno od tega, ali nas zanima prilagodljivost ali preprostost rabe.

    Plone ima veliko prednost v tem, da lahko celoten sistem preprosto namestimo, saj ponuja namestitveni program za Okna, MacOS X in Linux. Za namestitev tudi ne potrebujemo uporabniškega imena upravitelja (root), saj je celoten sistem pravzaprav uporabniški program. V Oknih imamo na voljo celo poseben nadzorni program za spremljanje delovanja sistema. Celoten nadzor sicer opravljamo, kot je pri teh sistemih v navadi, prek spletnega vmesnika. Takoj po namestitvi imamo pred sabo zgleden in zelo uporaben sistem, seveda pa ga bomo zelo verjetno želeli vsaj nekoliko preoblikovati. Ena od slabosti, ki pesti večino sistemov CMS, je namreč velika podobnost vseh spletišč na isti podlagi, ki že na daleč izdaja sistem.

    Kaj je CMS?

    Sistem CMS je programska rešitev, ki omogoča nadzor celotnega življenjskega cikla vsebine. Tak cikel zajema ustvarjanje, upravljanje, urejanje, objavo, preiskovanje in pravočasno odstranjevanje ter arhiviranje. Ključni element, ki ločuje sistem CMS od običajnega orodja za pripravo in objavo spletne strani, je urejena shramba vsebine, ki nam omogoča vse storitve sistema, kot so npr. vnaprej določen delovni tok dokumentov (document workflow), nadzor različic (versioning), zaščito izbranih vsebin (access control), učinkovito preiskovanje ali pa časovno odvisna objava.

    Ustrezen sistem CMS bi seveda lahko upravljal poljubno vsebino, vendar se najpogosteje uporabljajo prav za urejanje spletišč, ki so, kot smo omenili, danes najbolj plodna tla za nove vsebine. Učinkovit spletni sistem CMS ponuja uporabniku vrsto prednosti, kot so:

    preprostejše ustvarjanje kakovostne vsebine, ki je skladna z vnaprej določeno podobo;

    možnost upravljanja na daljavo;

    boljše sodelovanje med različnimi ustvarjalci;

    lažji nadzor nad časovno kritičnimi elementi za objavo in učinkovitejša zamenjava zastarelih vsebin;

    visoka prilagodljivost in preprosto dodajanje novih zmožnosti;

    večja varnost;

    lažje stopnjevanje obsega;

    nižji stroški vzdrževanja.

    Seveda so naštete prednosti predvsem ideali, ki se jim želijo različni sistemi CMS bolj ali manj uspešno približati. Nedvomno pa so danes ti sistemi že dosegli stopnjo, ko njihove prednosti niso več vprašljive. Težave s CMS se skrivajo drugje, kot bomo spoznali v nadaljevanju.

    Odprta koda

    Z rastjo uporabe interneta se je povečevala tudi uporaba odprte kode, ki je danes marsikje učinkovita alternativa "klasičnim" programskim rešitvam. Še več, prav prosto- in odprtokodni programi sestavljajo hrbtenico programja za internet, spomnimo se zgolj spletnega strežnika Apache. S podporo odprti kodi tudi s strani vodilnih igralcev v računalniški industriji je ta pridobila potrebno zaupanje tudi pri zainteresirani javnosti.

    Prav trg sistemov CMS je doživel izjemen razcvet ponudbe skozi odprtokodne rešitve. Najverjetneje je vzrok tolikšne izbire učinkovita podlaga - predstavlja jo predvsem kratica LAMP (operacijski sistem Linux, spletni strežnik Apache, podatkovni strežnik MySQL ter skriptni programski jezik PHP oz. perl oz. python) - na kateri so ti sistemi razviti. Drug razlog izbruha odprtokodnih sistemov CMS je precej nerazumna cenovna politika komercialnih ponudnikov različnih dveri in sistemov za upravljanje vsebin, ki jo morda lahko opravičijo v velikih organizacijah in javno financiranih sistemih, težko pa bi se zanje odločilo malo ali srednje veliko podjetje, katerega potrebe po objavi v spletu niso prav nič manjše, prej nasprotno.

    Odprtokodni sistemi CMS so zato doživeli razcvet. Najuspešnejši ponudniki so lahko preživeli s prodajo prilagoditev in vzdrževanja, sama osnova pa je ostala brezplačna, odprta in pripravljena za širitev zmogljivosti. Danes so vodilni odprtokodni sistemi CMS povsem primerljivi s svojimi komercialnimi vzorniki, marsikje pa jih celo prekašajo. Številnim spletnim mojstrom je dodatna motivacija pri izbiri odprtokodnega sistema možnost preučevanja notranjega ustroja in vpliv na nadaljnji razvoj podlage. Če bi, denimo, podjetje, ki prodaja zaprt, komercialen sistem CMS propadlo, bi se njegovi uporabniki znašli v silni stiski. Odprta koda to nevarnost odpravlja, saj je podpora izdelovalca sicer še vedno pomembna, vendar v skrajnem primeru nadomestljiva, bodisi s prevzemom projekta s strani skupnosti uporabnikov bodisi s plačilom storitve nadaljnjega razvoja komurkoli, ki ima ustrezno znanje. Koda je odprta in na voljo vsakomur. Ta lastnost je še toliko bolj izražena zato, ker odprtokodni sistemi CMS skoraj brez izjeme temeljijo na odprtih ali vsaj dejanskih standardih, tako da je izbira programerjev, ki lahko gradijo na pripravljeni osnovi, vedno dovolj velika.

    Treba je omeniti različna dovoljenja za uporabo, ki se od sistema do sistema lahko zelo razlikujejo. Brezplačno pogosto ne pomeni tudi brezplačno pod vsakimi pogoji rabe. Nekateri odprtokodni sistemi CMS zahtevajo plačilo za uporabo v komercialne namene, drugi zahtevajo objavo izvirne kode vseh dopolnitev, ki jih bomo morda razvili. Vsekakor se moramo pred odločitvijo za posamezen sistem podrobno seznaniti s pogoji rabe, da ne bomo pozneje presenečeni.

    Storitve

    Ker odprtokodni sistemi ne pomenijo visokega stroška vzpostavitve, se lahko več denarja nameni za njihovo prilagajanje, čemur so tudi namenjeni. Sistem CMS je namreč dober prav toliko, kolikor je učinkovito njegovo prilagajanje našim potrebam. Prilagajanje je trajen in sorazmerno drag proces, ki zajema:

    določanje videza strani, slogov besedila in druge vsebine;

    prilagajanje sistema CMS specifičnim potrebam našega spletišča;

    povezovanje sistema CMS z drugimi, že delujočimi viri vsebin;

    preizkušanje delovanja in uporabnosti;

    uvajanje uporabnikov, od vnašalcev do urednikov in upraviteljev;

    tekoče vzdrževanje delujočega sistema;

    nadgradnje in dopolnitve.

    Vse te in še nekatere manj izražene podrobnosti praktično v celoti odločajo o uspehu celotnega projekta. Izbira ustreznega sistema CMS je zgolj prvi korak, v katerem ne smemo izgubiti osredotočenosti na temeljni problem: vsebino in njeno upravljanje. Posamezne tehnične podrobnosti posameznih ponudnikov, ki se na prvi pogled lahko zdijo velikanska prednost, lahko skopnijo takoj, ko se soočimo npr. s slabo dokumentacijo istega sistema, ki nam onemogoči učinkovito prilagajanje.

    Odprtokodni sistemi so seveda znova v prednosti iz več razlogov. Prvi je jasno odprta in dostopna izvirna koda, kar nam omogoča preučevanje delovanja in poljubno razširjanje zmogljivost, če imamo ustrezno znanje, oz. smo ga pripravljeni plačati komurkoli, ki ga ima namesto nas. Vendar to ni vse. Omenili smo že prednost odprtih standardov, na katerih so ti sistemi tipično zgrajeni. Odprtokodni sistemi večinoma temeljijo tudi na odprtokodni podlagi (zgoraj omenjeni LAMP je v celoti odprta koda). To še povečuje možnost prilagajanja in širi skupino programerjev, ki nam lahko pomaga pri reševanju problemov. Možnost prostega razpolaganja s kodo hkrati omogoča vsem uporabnikom istega sistema, da združijo moči in skupaj razvijejo prilagoditve, ki jih potrebujejo. Za razliko od komercialnih ponudnikov, pri katerih se podpora tipično odvija v zaprtem krogu, ki ga definirajo drage vzdrževalne pogodbe, imajo odprtokodni sistemi vedno tudi široko zaledje skupnosti, ki jo sestavljajo tako avtorji kot uporabniki. Na javno dostopnih spletiščih lahko dejavno spremljamo reševanje težav ali vlagamo želje po dodatnih zmožnostih.

    Preizkušanje

    Ker je odločitev o ustreznem sistemu CMS vse prej kot lahka, je pomembna prednost odprtokodnih sistemov tudi možnost neomejenega preizkušanja. Skoraj vsi ponudniki omogočajo živi preizkus zmožnosti izdelka brez kakršnegakoli nameščanja. Preprosto obiščemo njihove spletne strani, kjer najdemo geslo za dostop do preizkusnega strežnika.

    Nevarnost, da bi nasedli obljubam tržnega oddelka in resno pomanjkljivost v sistemu odkrili šele za tem, ko odštejemo lepe denarce, je tako precej manjša. Seveda je znova mogoče na pomoč priklicati skupnost uporabnikov, ki nam lahko svetuje skozi lastne izkušnje. Zanimiv pojav pri skoraj vseh odprtokodnih sistemih je iskrena želja večine uporabnikov, da prispevajo k dobrobiti celotnega projekta in hkrati neusmiljena kritika do očitnih pomanjkljivosti. Slabe rešitve, ki so zasnovane na napačnih predpostavkah, so zato precej pogosto izločene že na začetku.

    Preizkušanje lahko razkrije težave, ki nam pomenijo resno oviro za uporabo sistema. Medtem ko bi se pri komercialnem sistemu lahko ob tem le ozrli stran, si pri odprti kodi še vedno lahko privoščimo prijavo težave skupnosti ali kar neposredno razvijalcem izdelka. Neredko se bodo hitro odzvali in morda sistem brezplačno prilagodili prav zaradi nas, še posebej, če smo odkrili zares bolečo pomanjkljivost.

    Slabosti odprtokodnih sistemov

    Seveda pa ni mogoče odprtokodnih sistemov CMS zgolj opevati. Nekatere slabosti so sestavni del odprtokodnega sveta in jim moramo vzeti v zakup.

    Potencialno težavo zaradi dovoljenja za rabo smo že omenili, zato zgolj ponovimo, da moramo pred dokončno odločitvijo podrobno preučiti pogoje rabe odprte kode. Nekateri sistemi ne vsiljujejo prav nobenih omejitev, spet drugje so lahko pravila precej zapletena in težko razumljiva. Prav tako se moramo zavedati, da brezplačnost same osnove, torej sistema CMS, nikakor ne pomeni, da bomo prišli skozi zastonj. Sam sistem je zanemarljiv strošek proti vsem prizadevanjem (in denarju), ki ga bomo morali vložiti najprej v spoznavanje sistema in zatem v njegovo prilagajanje in uporabo.

    Odprtokodni sistemi CMS, za katerimi ne stoji tržno usmerjeno podjetje, pogosto muči stanje nenehnega preizkušanja. Izdelek v resnici nikoli ni končan, ker ni pravega pritiska, da bi zares bil. Marsikateri sistem CMS se je skozi povsem dobre namene docela izrodil in vsi, ki so verjeli vanj, so verjetno izgubili precej časa in denarja, morda celo zaman. Vendar številne odprtokodne sisteme CMS podpira tržno usmerjeno podjetje, ki pač svoj dobiček dobi s prodajo drugih, povezanih storitev, ne pa samega izdelka.

    Le redki sistemi CMS so primerni za poslovno rabo v velikih organizacijah z zapletenimi pravili upravljanja vsebin. To še posebej velja za odprtokodne različice, ki so kot po pravilu namenjene predvsem majhnim in srednje velikim podjetjem ter organizacijam.

    Pri odprtokodnih sistemih bomo pogosto pogrešali preprost in jasen postopek namestitve na našo strojno opremo. Pogosto je treba namestiti cel kup programske infrastrukture najrazličnejših ponudnikov, jo tu in tam pokrpati z različnimi popravki in dodatki in šele na to osnovo namestiti sam sistem CMS, ki najpogosteje tudi ne pozna enega samega namestitvenega paketa.

    Čeprav niso najbolj tipičen zgled, pa tudi pri odprtokodnih sistemih CMS lahko naletimo na prevelik "tehnicizem". Številna orodja so delo zagnanih programerjev, ki najpogosteje nimajo pravega razumevanja za potrebe tipičnega uporabnika. Čeprav so njihovi izdelki tehnološko izpiljeni, jim manjka uporabniške prijaznosti. Na srečo je pri sistemih CMS ta slabost redkeje izražena, saj so navsezadnje namenjeni prav lažjemu delu. Poleg tega zelo bogata izbira sili njihove tvorce, da razmišljajo tudi o preprostosti uporabe. Zapletenih sistemov CMS je tako ali tako preveč.

    Izbor sistema

    Pravzaprav je nekakšna slabost odprtokodnih sistemov CMS tudi zelo široka izbira. To je v svetu odprte kode nasploh problem, saj preprosta vejitev kodne osnove v drugačno različico ne pomeni nobene večje težave, če se le najde manjša nezadovoljna skupina programerjev. Res pa ta problem pesti predvsem izdelke, s kakovostjo katerih je le redko kdo zadovoljen.

    Vsekakor pa je nevarnost, da bomo pri izbiranju ustreznega sistema CMS porabili preveč časa. Spletišče OSCOM (Open Source COntent Management, http://www.oscom.org/) našteva kar 17 ogrodij za izdelavo lastnih sistemov in več kot 40 izdelanih odprtokodnih sistemov CMS. Spet drugo spletišče, CMS Matrix (http://www.cmsmatrix.org/matrix), kjer lahko nazorno primerjamo zmožnosti teh sistemov, ponuja izbiro kar 274 izdelkov!

    Pri taki izbiri je največja napaka, ki jo lahko storimo, preveliko zaupanje priporočilu. Odločitev za ustrezen sistem CMS mora temeljiti na naših jasnih zahtevah. Kar ustreza enemu, ki navdušeno uporablja določen sistem, nam morda ne bo dovolj ali pa bo celo razlog, da nam isti sistem ne bo všeč. Na srečo lahko z jasno postavljenimi kriteriji hitro precej oklestimo razpoložljive kandidate. Pomembna merila, ki znatno vplivajo na izbor, so:

    Dovoljenje za uporabo. Ali so sistemi popolnoma prosti ali pa dovoljenje skriva kakšne podrobnosti, ki nam niso všeč? Večina sistemov je na voljo pod dovoljenjem GPL, ki zahteva, da morebitne dopolnitve vrnemo skupnosti v obliki izvirne kode. Dovoljenje LGPL te zahteve nima, kot je nima tudi dovoljenje BSD. Nekateri sistemi so na voljo popolnoma brez omejitev, drugi pa so na voljo pod različnimi pogoji, odvisno od namena rabe.

    Podpora. Je za sistem na voljo komercialna podpora, ki jo v skrajni sili lahko najamemo? Ali pa ima morda sistem tako široko skupnost uporabnikov, da bomo morebitne težave kljub pomanjkanju komercialnega ponudnika podpore vseeno odpravili?

    Podlaga. Na katerih operacijskih sistemih, kakšnem spletnem ter podatkovnem (ali programskem) strežniku se sistem izvaja? Kakšno programsko ogrodje potrebuje? Bomo sistem lahko neboleče namestili?

    Programski jezik. V katerem programskem jeziku je koda sistema? Imamo možnost to kodo dopolnjevati ali kupiti programsko podporo za nadgradnje zmogljivosti?

    Odprti standardi. Na kakšnih standardih izdelek temelji? Kako hrani vsebino in kako jo ponuja uporabnikom?

    Dodatki. Kako široka je skupnost, ki razvija dodatke za sistem? So med dodatki kakšni, ki bi znatno poenostavili prilagoditev sistema našim potrebam?

    Varnost. Kakšne omejitve dostopa do posameznih vsebin sistem podpira? Se lahko povezuje z obstoječimi sistemi preverjanja uporabnikov (npr. LDAP)?

    Večjezičnost. Ali so podprti jeziki, ki jih potrebujemo, tako v javnem delu kot v modulih za upravljanje sistema?

    Enostavnost urejevalnikov. Ali sistem podpira urejanje "videz ne vara" (WYSIWYG)? V katerih spletnih brskalnikih je to mogoče (zgolj IE ali tudi drugih, ki že podpirajo vizualno urejanje, kot so Firefox/Mozilla, Safari, Opera)? Kako zapleteno je upravljanje večpredstavnih vsebin?

    Enostavnost prilagajanja. Kako hitro smo se znašli v sistemu?

    Zaščita in prenos vsebine. Kako je poskrbljeno za izdelavo rezervnih kopij podatkov in njihov morebiten prenos na drug sistem?

    Izmed naštetih kriterijev nam bodo nekateri bolj, drugi manj pomembni. Številne bomo lahko preverili le s preizkusom sistema, s čimer na srečo pri odprtokodni ponudbi ni večjih težav.

    Velikansko pomoč pri preizkušanju (pre)številnih sistemov CMS nam ponuja posebno spletišče, OpensourceCMS (http://www.opensourcecms.com/). Tu lahko najdemo preizkusne namestitve praktično vseh boljših sistemov CMS, ki izkoriščajo skriptni jezik PHP in podatkovni strežnik MySQL. Na voljo nam je dostop do javnih in nadzornih strani vsakega sistema, z njimi pa se lahko igramo po mili volji, saj se namestitve obnovijo vsaki dve uri (na polno uro).

    Šele ko na izbranem sistemu uspešno preverimo celoten seznam svojih ključnih želja, si ga namestimo tudi na lastno strojno opremo. Čeprav postopki namestitve praviloma niso najpreprostejši, pa sistema ne smemo soditi po njihovi zapletenosti, saj bomo namestitev opravili redko. Enostavnost rabe nameščenega sistema je ključna.

    Tabela sistemov CMS

    PHP Nuke, PostNuke in znanci

    PHP Nuke (http://phpnuke.org/) je eden prvih odprtokodnih sistemov za lažje objavljanje in vzdrževanje vsebin v spletu. Med zagovorniki odprte kode je neznansko uspešno spletišče Slashdot (http://slashdot.org/), ki prinaša vsak dan svež seznam novic, ki se jih na dolgo in široko komentira. Skupnost obiskovalcev spletišča je tako velika, da spletna povezava, omenjena med novico, neredko doživi t. i. "slashdot efekt", saj strežnik zaradi nenadnega navala obiskovalcev, napotenih s Slashdota, preprosto klecne. Čeprav je tudi koda Slashdota na voljo pod dovoljenjem GPL in se uporablja na številnih drugih spletiščih, ga je po priljubljenosti med razvijalci odločno prekosil njegov "klon" v PHPju, Slashdot je namreč izdelan s pomočjo kode v perlu. Prvi PHP Nuke je v treh tednih razvil očitno genialni Francisco Burzi, projekt pa je pretrpel že nič koliko vejitev kodne osnove in številne izpeljane različice.

    Javna stran sveže nameščenega PHP Nuke, nekateri elementi so prevedeni v slovenščino.

    Osnovni PHP Nuke tako ni pravi sistem za upravljanje vsebin, temveč je v osnovi sistem za avtomatizacijo objav novic, ki pa je v letih razvoja pridobil številne dodatke in razvil izjemno skupnost. Celotna koda se razvija v skriptnem jeziku PHP in se lahko izvaja bodisi v strežniku Apache z dodatkom mod_perl, bodisi v Oknih na strežniku IIS z nameščenim tolmačem za PHP. Najbolj se znajde s podatkovnim strežnikom MySQL, lahko pa ga uporabljamo tudi z drugimi, npr. PostgreSQL.

    Po množičnosti uporabe je PHP Nuke še vedno najbolj razširjen odptokodni sistem za objavljanje v spletu in ga zato pozna zelo veliko spletnih razvijalcev. Ti so zanj razvili skoraj neskončno število dodatkov, žal pa to zgolj oteži njegovo prilagajanje, saj je izbira pogosto prevelika, številni dodatki pa so kljub vloženemu trudu pogosto nepopolni, predvsem pa med seboj slabo združljivi. Največ dodatkov je posvečenih izgradnji spletne skupnosti (različni forumi, pogovori, ankete...).

    Vsekakor PHP Nuke ni za vsakogar, z njim se bodo dobro razumeli predvsem razvijalci, ki jim je PHP blizu in bi radi od blizu spoznali delovanje zapletenega sistema v njem.

    Najpomembnejša izpeljana različica PHP Nuke je PostNuke (http://www.postnuke.com/), ki je znano osnovo precej izboljšala. Žal pa tudi tvorci PostNuke niso ostali enotni, zato projekt trpi zaradi notranjih bojev, vsaka nova različica pa prinese skoraj toliko novih hroščev, kot je novih zmožnosti. PostNuke je zato rodil še več novih sistemov, kot so Envolution (http://www.envolution.com/), Xaraya (http://www.xaraya.com/) ali Xoops (http://www.xoops.org/).

    Envolution je gradil iz PostNuke, vendar je bila koda skoraj v celoti nadomeščena z robustnejšo in zmogljivejšo. To mu omogoča, da prenese visoke obremenitve. Prednosti sistema Envolution so: popolna prilagodljivost videza spletnih strani skozi predloge, medpomnjenje izdelanih strani za večjo odzivnost, precej lažje upravljanje, široka skupnost razvijalcev, ki ponujajo precejšnjo podporo.

    Xaraya je popeljala kodno osnovo v PHPju proti pravemu sistemu CMS. Na novo zasnovana zgradba sistema je neodvisna od izbranega podatkovnega strežnika in ločuje videz, vsebino, delovanje in upravljanje. Razvija jo več kot štirideset programerjev po vsem svetu in dobro podpira večjezičnost.

    Xoops je predmetno usmerjena predelava PostNuke in je zato najprimernejši za hitro izgradnjo spletnih skupnosti, saj ponuja zelo dobra orodja za delo z uporabniki. Njegova prednost je tudi integrirana relacijska zbirka vsebin, Wiki.

    Nadzorna plošča administracijskega dela PHP Nuke.

    PHP Nuke in njegove izpeljanke so marsikomu nenadomestljivo orodje, žal pa niso najpreprostejše za rabo in se jih upravičeno drži (slab) sloves izdelka "programerjev za programerje". Na srečo lahko vse skupaj precej neboleče preizkusimo na spletišču OpensourceCMS in hitro preverimo, ali nam vsaj v grobem ustrezajo.

    Zope in Plone

    Sredi lanskega leta je skupnost uporabnikov sistemov CMS razburkal izbor znane revije eWeek, ki je sistem za upravljanje vsebin Plone razglasila za najboljšega po izboru analitikov in to potrdila tudi konec leta, ko se je izdelek znašel v družbi desetih programerskih izdelkov leta. Vsekakor velikanski kompliment za brezplačen, odprtokodni izdelek v jeziku python, ki se bori za svoj delež na zelo obljudenem trgu, kjer vodilni komercialni ponudniki za svoje izdelke zaračunavajo včasih prav neverjetne vsote.

    Plone gradi na podlagi zmogljivega programskega strežnika Zope, prav tako razvitega v pythonu. Najpomembnejše prednosti kombinacije Zope/Plone so: zmogljiva podpora delovnemu toku dokumentov, skladnost s številnimi spletnimi standardi, napredna varnostna arhitektura. Temeljna značilnost Plona je njegova predmetna osnova, saj celo podatke hrani v predmetni zbirki (in ne v običajni relacijski, ki je temelj skoraj vseh drugih sistemov). To zna marsikateremu uporabniku zagreniti življenje, dokler se s sistemom ne spozna podrobneje. Poznejše prednosti predmetne zasnove so seveda pri vzdrževanju sistema neprecenljive.

    Privzeta stran sveže nameščenega sistema Plone je lična in zelo uporabna brez posebnih dodatnih nastavitev. Seveda je v temeljnem videzu Plona pripravljena tudi njegova domača stran.

    Programski strežnik Zope ponuja spletni vmesnik za upravljanje, skozi katerega lahko urejamo predloge in nadziramo predmetno zbirko podatkov. Zope je lahko samostojen spletni strežnik, čeprav se pogosto uporablja v ozadju, za bolj običajnim Apache, zaradi dodatne varnosti, zmogljivosti in medpomnjenja. Zope je nekoč uporabljal svoj skriptni jezik za opisovanje poslovne logike, danes pa vse temelji na predlogah XML in skriptni kodi v pythonu. Tako je razvito tudi ogrodje za sistem CMS, poimenovano CMF (Content Management Framework), ki ga izkorišča Plone. Plone nadzira videz, sloge, gradnike spletnih strani, vsebinske tipe itd. Za delo z vsebinami uporabljamo vnaprej pripravljene kategorije oz. arhetipe (archetypes), ki jih lahko poljubno dopolnjujemo. Ti lahko med seboj sodelujejo prek mehanizma dogodkov (events). Za upravljanje Plona se moramo potopiti v številne sloje, včasih celo nazaj do predlog strežnika Zope, kar je lahko prednost ali pa slabost, odvisno od tega, ali nas zanima prilagodljivost ali preprostost rabe.

    Plone ima veliko prednost v tem, da lahko celoten sistem preprosto namestimo, saj ponuja namestitveni program za Okna, MacOS X in Linux. Za namestitev tudi ne potrebujemo uporabniškega imena upravitelja (root), saj je celoten sistem pravzaprav uporabniški program. V Oknih imamo na voljo celo poseben nadzorni program za spremljanje delovanja sistema. Celoten nadzor sicer opravljamo, kot je pri teh sistemih v navadi, prek spletnega vmesnika. Takoj po namestitvi imamo pred sabo zgleden in zelo uporaben sistem, seveda pa ga bomo zelo verjetno želeli vsaj nekoliko preoblikovati. Ena od slabosti, ki pesti večino sistemov CMS, je namreč velika podobnost vseh spletišč na isti podlagi, ki že na daleč izdaja sistem.

    Janez

    Micka

    Polde

    Francelj

    Polimorfizem deluje tudi pri številih znotraj intervala, znakih znotraj niza ali elementih seznama.

    Uporabnost regularnih izrazov je pri skriptnih jezikih neprecenljiva, saj se zelo pogosto ukvarjajo z obdelavo daljših besedil. Groovy za delo z regularnimi nizi v skladnjo vpelje tildo (~). Takole lahko ustvarimo nov regularni izraz:

    groovy> rx = ~"^J.*"

    Operator ==~ pa omogoča iskanje ujemanj (matches). Spodnji izraz tako vrne resnico:

    groovy> println ( "Janez" ==~ rx )

    groovy> go

    true

    Zaprti bloki (closures) so postali v skriptnih jezikih izjemno priljubljeni predvsem po zaslugi pythona, v resnici pa izvirajo iz precej bolj oddaljene zgodovine računalništva, namreč iz jezikov lisp in smalltalk. Zaprti blok je v resnici izraz (najpogosteje v obliki funkcije), ki poveže proste spremenljivke s programskimi stavki (in jih na ta način "zapre"). Najbližja analogija zaprtim blokom v klasični javanski kodi so notranji razredi (inner classes). Na hitro bi lahko sestavili zaprti blok, ki poveže prosto spremenljivko in kodo, za nekoliko prijaznejši izpis njene vrednosti:

    groovy> pozdrav = { ime | println "Lepo pozdravljen, ${ime}!" }

    Zdaj lahko zaprti blok izkoristimo za izpis več pozdravov:

    groovy> pozdrav("Janez")

    groovy> pozdrav("Micka")

    groovy> pozdrav("Polde")

    groovy> go

    Lepo pozdravljen, Janez!

    Lepo pozdravljen, Micka!

    Lepo pozdravljen, Polde!

    Seveda smo se s tem zgledom le dotaknili zaprtih blokov. Z manjšo zvijačo je mogoče zapisati celo rekurzivne klice znotraj blokov in jih tako uporabiti za učinkovito pregledovanje drevesnih struktur, kot je npr. datotečni sistem z mapami. Spodaj je zgled tako zapisanega, gnezdenega in rekurzivno klicanega bloka preglej_podmape, ki izvede "opravilo" na "mapi" in vseh podmapah:

    preglej = { mapa, opravilo |

    preglej_podmape = { mapa, opravilo |

    rekurzija = this

    mapa.list().each {

    opravilo( it )

    rekurzija( it, opravilo )

    }

    }

    opravilo( mapa )

    preglej_podmape( mapa, opravilo )

    }

    "Opravilo" je seveda nov zaprti blok. Nanje torej lahko gledamo tudi kot na kazalce funkcij. Vidimo, da neposreden rekurzivni klic z imenom zaprtega bloka ni mogoč. Na srečo pa so zaprti bloki prav tako razredi, zato nam pomaga rezervirana beseda this, ki vrne sklic na dejavni predmet.

    Grafični vmesnik

    Groovy se zdi najprimernejši za obdelave v ozadju, pri povezovanju spletnih storitev, obdelavi dnevniških datotek, preizkušanju ... Vendar je z njim mogoče izdelati tudi povsem spodobne uporabniške vmesnike. Groovy ponuja pomožni razred groovy.swing.SwingBuilder, s katerim lahko zelo hitro sestavimo okno grafičnega vmesnika. Ker nam groovy omogoča tudi poimenovanje posameznih parametrov v klicu metode, je koda še toliko hitreje sestavljena in bistveno bolj berljiva:

    import java.awt.BorderLayout

    import javax.swing.JOptionPane

    swing = new groovy.swing.SwingBuilder()

    okno = swing.frame (

    title: 'Preprosto okno',

    location: [100, 100],

    size: [300, 120]) {

    menuBar {

    menu(text: 'Datoteka') {

    menuItem(

    text: 'Izhod',

    actionPerformed: {

    System.exit(0)

    }

    )

    }

    }

    panel(layout: new BorderLayout()) {

    label (

    text: ' Ime: ',

    constraints: BorderLayout.WEST,

    toolTipText: 'Vnesi ime:'

    )

    ime = textField (

    constraints: BorderLayout.CENTER

    )

    button (

    text: 'Pozdrav',

    constraints: BorderLayout.SOUTH,

    actionPerformed: {

    JOptionPane.showMessageDialog(

    null, "Lep pozdrav, ${ime.text}!"

    )

    }

    )

    }

    }

    okno.visible = true

    Najprej smo si pripravili ustrezen predmet (swing), ki smo ga v nadaljevanju prikrojili lastni rabi. S poimenovanimi parametri title, location in size smo nastavili osnovne lastnosti okna. Sledi dodajanje predmetov na uporabniški vmesnik. Najprej smo dodali menujsko vrstico z enim menujem ("Datoteka"), v katerem je en ukaz ("Izhod"). Zatem smo na vmesnik dodali vsebnik (panel), ki bo vsebino razvrstil na robove (new BorderLayout()). Na "zahodu" je napis z namigom (gre za gradnik Swing JLabel, ustrezni poimenovani parameter je toolTipText), v sredini je vnosno polje, na katerega se bomo še sklicevali, zato ga priredimo spremenljivki ime. Na "jugu" bo gumb, katerega klik bo povzročil prikaz pozdrava. Tu nam pomaga še en gradnik Swing, standardno pogovorno okno za sporočilo (JOptionPane.showMessageDialog()). Zgled delovanja je viden na sliki 3.

    Hitro sestavljen programček z grafičnim uporabniškim vmesnikom.

    Sklep

    Priljubljenost skriptnih jezikov in zmogljivost, ki jo kaže groovy, je dober obet za njegov bodoči uspeh. Ker trka na srca množice javanskih programerjev, ki se pri vsakodnevnem delu spopadajo tudi z bolj duhamornimi opravili, ki jih je v javi pogosto težko in predvsem dolgovezno programirati, zna groovy rešiti marsikatero težavo na hiter ter zmogljiv način.

    Zelo vzpodbudno je, da gre za odprtokodni projekt, ki se poleg tega razvija kot bodoči javanski standard. Tudi sami lahko zato prispevamo svoj del k nadaljnjemu razvoju tega zanimivega izdelka in ga s tem naredimo še bolj prijaznega in uporabnega.

    Viri in dodatna literatura:

    [1] Nastajajoči javanski standard, JSR 241 - http://www.jcp.org/en/jsr/detail?id=241

    [2] Trenutni dom groovya - http://groovy.codehaus.org/

    [3] Razčlenjene dobre in slabe lastnosti (starejše različice) groovya - http://www.theserverside.com/blogs/showblog.tss?id=GroovyReview

    [4] Spoznajmo groovy - http://java.sun.com/developer/technicalArticles/JavaLP/groovy/

    Naroči se na redna tedenska ali mesečna obvestila o novih prispevkih na naši spletni strani!

    Komentirajo lahko le prijavljeni uporabniki

     
    • Polja označena z * je potrebno obvezno izpolniti
    • Pošlji