Produktdokumentasjon for Sir Jerky Leap

Transkript

1 Produktdokumentasjon for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) Produktdokumentasjon for Sir Jerky Leap 1

2 Innholdsfortegnelse Forord Innledning Gruppen Om bedriften Bakgrunn for oppgaven Beskrivelse av produktet Benyttede Teknologier, språk, og rammeverk Datastrukturer Database ER-diagram Tabeller Tabellen «tasks» Tabellen «contents» Tabellen «resources» Tabellen «users» Tabellen «task_user» Tabellen «task_content» Tabellen «task_resource» Persistenslag med Memcached Memcached Persisterte objekter Oppgavetreet «Tasks» «User» «nav_tab» og «active_tab» Lagring av status på oppgaver i en fane Systemets oppbygging Hovedkomponenter Visning Navigasjon Oppdatering Tilstand Klasse- og filstrukturer SJLController TaskController SJLProcessor Modell-laget Templates Tags TaskList Virkemåte Opprettelse Utvidelser TOCList Tabs Design Grafikk og fargebruk Farger Ikoner

3 6. Adgangs- og brukerkontroll Utvidelsesmuligheter Tilrettelegging Database

4 1. Forord Dette dokumentet er produktdokumentasjonen til Sir Jerky Leap, vårt hovedprosjekt våren Hovedprosjekteter et samarbeid mellom Høgskolen i Oslo, og vår oppdragsgiver, Aptoma AS. Produktdokumentasjonen beskriver det ferdige produktets funksjonalitet, virkemåte og oppbygging. Sammen med prosessrapporten skal den gi et helhetlig inntrykk av arbeidet som er utført og det produktresultatet som er oppnådd. Dokumentets første del omtaler oppdragsgiver og hensikten med programmet, samt hva programmet utfører helt prinsipielt. Dokumentet tar videre for seg sentrale datastrukturer, systemets oppbygging, samt detaljerte beskrivelser av programmets moduler. 4

5 2. Innledning Denne delen av dokumentet inneholder bakgrunnsinformasjon for prosjektet. Vi begynner med å presentere hvem som har utført prosjektet, etterfulgt av en mer detaljert beskrivelse av bedriften og bakgrunnen for oppgaven Gruppen Gruppen bak produktet Sir Jerky Leap består av Tor Anders Gustavsen, Fredrik Hoem Grelland, Jasmine En-Ning Garry og Line Sørensen. Gruppemedlemmene har flere ganger jobbet sammen på prosjekter, og har derfor et godt og innøvd samarbeid. Vi valgte å arbeide sammen også på dette prosjektet nettopp på grunn av godt samarbeid, at vi utfyller hverandre, har samme ambisjonsnivå og ønsket samme type oppgave. Gruppens første utfordring var å finne et passende prosjekt. Vi satt oss ned i fellesskap og gikk igjennom de prosjektforslagene som forelå på hjemmesiden til dataavdelingen ved Høgskolen i Oslo. Utviklingsfirmaet Aptoma AS hadde kontaktet skolen og lagt frem to hovedprosjektoppgaver. Vi fant prosjektoppgaven Sir Jerky Leap interessant, ikke minst på grunn av utfordringene knyttet til denne oppgaven Om bedriften Aptoma AS utvikler dynamiske webapplikasjoner, rettet mot større avisselskaper og mediale bedrifter i Norge og utlandet. Produktspekteret omfatter blant annet løsninger innen web-tv, visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus. Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har VG-TV og Listefeber. I tillegg har bedriften utviket et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VGnetts «Rampelys» og den franske nyhetsnettsiden « Bedriften samarbeider også med Scanpix/NTB Bakgrunn for oppgaven Oppdragsgiver benytter i dag flere ulike verktøy til å administrere prosjekter og oppgaver, føre timer og registrere ferier. Å jobbe på tvers av mange ulike programmer, er tidkrevende og lite effektivt. Oppdragsgiver hadde ønske om å gjøre arbeidet smartere, og vi ble bedt om å utvikle et oppgavestyringsverktøy med vekt på effektivitet. 5

6 2.4. Beskrivelse av produktet Produktets hensikt er å forenkle prosjekt- og oppgavestyring. Sir Jerky Leap skal være limet mellom flere oppgavestyringsverktøy som allerede eksisterer. Vi har hentet ideer fra disse og implementert nyttige funksjoner for å kunne gjøre prosjekt- og oppgavestyringen så enkel og intuitiv som mulig. Brukerne av systemet kan enkelt opprette, endre og slette prosjekter, underprosjekter og oppgaver. Oppgaver kan tilegnes innhold i form av tekst eller bilder. Alle oppgaver med innhold har sin egen TOC eller innholdsliste. Denne gir en oversikt over alt innhold tilknyttet oppgaven. TOC i ekspandert form gir en formattert visning av oppgavens innhold, og er ment å fungere som dokumentasjon til den enkelte oppgave. 6

7 2.5. Benyttede Teknologier, språk, og rammeverk. Programvare / Teknologi Apache HTTP Server PHP MySQL Memcached AFW Prototype 1.6 Scriptaculous Zend Studio 6.0 BETA DBDesigner 4.0 Navicat 8 for MySQL Mozilla Firefox x Firebug 1.x Tortoise SVN 1.4.x HTML CSS Beskrivelse Webserver Programmeringsspråk (server-side) PHP: Hypertext Preprocessor DBMS (database management system) System for caching av databasekall på webserver Aptoma Frame Work, Aptomas eget rammeverk Rammeverk som gir objektdreven tilnærming til JavaScript JavaScript-rammeverk basert på Prototype. Integrert utviklingsmiljø for PHP, basert på Eclipse. Databasemodelleringsverktøy for MySQL Databaseadministreringsverktøy for Windows Webleser Utviklingsverktøy for Mozilla Firefox Versjonskontroll HyperText Markup Language Cascading Style Sheets 7

8 3. Datastrukturer Dette kapittelet omtaler oppbyggingingen og logikken bak Sir Jerk Leaps to datastrukturer, database, og persistenslager basert på Memcached Database Vi har benyttet nyeste tilgjengelige versjon av MySQL, versjon , for å drifte vår applikasjon ER-diagram Diagrammet under viser relasjonene mellom tabellene i databasen. 8

9 Tabeller Det er fire hovedtabeller i systemet, to entitiseringstabeller for å implementere mange til mangefunksjonalitet, samt en tabell som kobler bruker til oppgaver. Tabellene er navngitt etter spesifikasjoner gitt av rammeverket. Entitiserings-tabellene er navngitt etter følgende mønster: x_y betyr at x skal inneholde y Tabellen «tasks» «Tasks»-tabellen inneholder oppføringer for alle oppgaver i applikasjonen. For å emulere et sortert hierarkisk oppgavetre benytter vi feltene pid, Indent og Sort. Feltet «pid» inneholder peker til forelder i treet. Som toppoppgave (prosjekt) er dette feltet satt til «0». Ved sletting av en oppgave settes forelderfeltet til negativ av tidligere forelder-id. Eks. «pid = 2» blir til «pid = -2». Dette gjør vi for å beholde informasjon om tidligere forelder til en slettet oppgave. Dette gjør at om brukeren ombestemmer seg vil det være mulig å reversere prosessen. Feltet «Indent» markerer på hvilket nivå, hierarkisk, oppgaven ligger på i treet. Indent 0 er toppoppgave, barn av en oppgave med «Indent = 0» får «Indent = 1.» Dette feltet er i utgangspunktet ikke nødvendig for å lage et hierarki, men letter lasten på serveren ved produksjon av trestrukturen som opprettes i persistenslaget, omtalt i kapittel Feltet «Sort» definerer i hvilken rekkefølge oppgavene skal vises. 9

10 Tabellen «contents» Tabellen «contents» inneholder oppgaveinnhold. Denne tabellen har i likhet med «tasks»-tabellen et sorteringsfelt «Sort». Dette feltet markerer i hvilken rekkefølge innhold skal vises i en oppgave. En innholds-oppføring har også et felt «Type», en enum, som definerer om innholdet skal vises eller ikke. Feltet «resource_id» er en peker til en oppføring i «resources»-tabellen, som gir innholdsoppføringen det faktiske innholdet Tabellen «resources» Tabellen «resources» inneholder oppføringer som definerer en ressurs. En ressurs er i bunn og grunn en definisjon på et innholdobjekt, men i motsetning til et innholdsobjekt som kun eksisterer for én oppgave, kan en ressurs benyttes i x antall innholdsobjekter, oppgaver, eller andre steder hvor en trenger en referanse til innhold. Enum-feltet «Type», definerer hva slags type ressurs oppføringen definerer. Kombinert med feltene «Title», «Path», og «Text» kan vi definere et utall av ressurstyper. I applikasjonen benyttes pr i dag 10

11 kun «Text» og «Image» i enumfeltet, men det er også lagt opp til «URL», og «Note» som mulige ressurstyper Tabellen «users» «users»-tabellen inneholder minimalt med informasjon om brukeren, og benyttes kun til å vise et navn istedet for en id i brukergrensesnittet. Feltet «id» skal her være en replika av id-feltet i innloggingssystemet Sir Access. Les mer om Sir Access i kapittel 7 Adgangs- og brukerkontroll Tabellen «task_user» Tabellen «task_user» benyttes til å tildele brukere rettigheter og arbeid på en oppgave. Feltene «Admin» og «Assigned» gir oss kombinert med «user_id» i «tasks»-tabellen mulighet til å fastslå rettighetene en bruker har til å endre, opprette og jobbe med en oppgave. 11

12 Tabellen «task_content» Denne tabellen er kobling mellom tabellene «tasks» og «contents» og utgjør mange-til-mange relasjonen mellom disse Tabellen «task_resource» Denne tabellen er kobling mellom tabellene «tasks» og «resources» og utgjør mange-til-mange relasjonen mellom disse. 12

13 3.2. Persistenslag med Memcached Dette delkapittelet tar for seg hvordan Sir Jerky Leap benytter seg av et ekstra persistenslag som supplement til MySQL-databasen omtalt i kapittel Memcached Memcached er en applikasjon som fungerer som et persisterende lag mellom webgrensesnittet og applikasjonen. Memcached lagrer ren tekst i minnet på serveren, og benyttes derfor først og fremst for å lagre ren HTML på større nettmedier for å minske server-lasten på dynamisk produserte sider med mange sidevisninger. AFW har innebygd funksjonalitet for å lagre og hente ut PHP-objekter gjennom klassen Persistence Persisterte objekter I dette avsnittet vil vi vise hvilke data som legges inn i persistenslaget, og hvordan applikasjonen benytter seg av disse. Figurene som representerer persistenslageret er hentet fra debug-verktøyet som følger med AFW. 13

14 Oppgavetreet «Tasks» Første gang applikasjonen kjører på serveren vil oppgave-treet lastes inn i persistenslageret. I utgangspunktet lastes kun de mest basale data inn for å minske lasten på serveren første gang applikasjonen startes, og for å hindre unødig ventetid for førstegangsbrukeren. Etter hvert som brukere etterspør innhold, brukerlister mye mer, vil dette legges inn i oppgave-treet. Oppgave-treet legges inn i Memcached som en array med navn «Tasks» på applikasjonsnivå som er identisk for alle tilkoblede brukere, istedet for sesjonsnivå som er unikt for brukeren. Dette sikrer at alle brukere jobber på samme oppgave-tre, med samme identifikatorer, slik det ville være om vi jobbet direkte mot databasen. Figuren under viser oppgave-treet lastet inn i persistenslaget. Hvert prosjekt, eller topp-oppgave ligger som et objekt i arrayen «Tasks», mens underoppgaver ligger under sin forelder i arrayen «children». Alle objekter i dette treet har hver sin unike identifikator, AFWId, som gjør det mulig å identifisere objekter i treet gjennom Ajax-kall uten å sende med en database-identifikator. 14

15 «User» Når en bruker logger på systemet returnerer Sir Access et objekt med brukerinformasjon. Vi lagrer dette objektet i persistenslaget på sesjonsnivå, slik at brukerinformasjonen er tilgjengelig for applikasjonen så lenge brukeren er innlogget. Figuren under viser det omtalte objektet lastet inn i persistenslaget. 15

16 «nav_tab» og «active_tab» For å lagre hvilke faner en bruker til en hver tid har laget, og hvilket innhold disse fanene representerer lages det en assosiativ array, med fanetittel som nøkkel, og spørrestreng som innhold i persistenslageret. Denne informasjonen lagres på sesjons-nivå, og er unik for hver bruker. Figuren under viser «nav_tab» med to faner, «Projects» og «Hovedprosjekt». Det persisterte objektet «active_tab» inneholder en spørrestreng tilsvarende den til en hver tid åpne fanen. Figuren under viser «active_tab» Ved sammenligning av «nav_tab» og «active_tab» figurene kan vi her se at brukeren har åpnet fanen som viser oppgaven «Hovedprosjekt». 16

17 Lagring av status på oppgaver i en fane For å lagre hvilke oppgaver som er åpne, viser underoppgaver eller innhold, blir det opprettet et objekt i persistenslaget som bærer AFWId'en til fanens innhold som navn. Dette objektet inneholder en array med AFWId til de oppgaver som er åpne i fanen. Hver gang en fane leses inn på nytt, eller den aktive fanen endres blir dette objektet erstattet med daværende status. Denne informasjonen lagres på sesjons-nivå, og er unik for hver bruker. Figuren under viser at to oppgaver som har AFWId'ene 8301 og 8308 skal være åpne om det åpnes en fane med AFWId projects. Figuren under viser at to oppgaver som har AFWId'ene 8301 og 8308 skal være åpne om det åpnes en fane med AFWId

18 Om en ny fane åpnes på en oppgave som har åpne underoppgaver, vil systemet duplisere denne informasjonen og den nye fanen vil åpne de samme oppgavene. Om man så velger å lukke oppgaver i den foregående fanen vil ikke dette påvirke hvilke oppgaver som er åpne i den nyopprettede. 4. Systemets oppbygging I dette kapittelet vil leseren få en dypere innføring i hvordan Sir Jerky Leap er bygd opp. I dette kapittelet vil det hyppig refereres til rammverket AFW, og komponenter i dette. Sir Jerky Leap er bygget på AFW, og følger derfor en MVC-metodikk for å skille; visning, forretningslogikk og databehandling. For en inngående forklaring av AFW henviser vi til vedlegg nr Hovedkomponenter Før dette dokumentet går dypere inn i oppbygningen av applikasjonen vil vi belyse fire komponenter som til sammen definerer applikasjonsflyten i Sir Jerky Leap. Visning, navigasjon, oppdatering og tilstand er hovedkomponentene i brukergrensesnittet, og det er disse vi har lagt størst vekt på i utviklingen av applikasjonen Visning I Sir Jerky Leap er det lagt opp til, i all hovedsak, tre forskjellige visninger av informasjon; listevisning, oppgavevisning og spesialvisning. Spesialvisninger er for eksempel «personal», eller de foreløpig uimplementerte visningene «inbox», «search» og «recycle bin». Disse visningsmodusene er distinkt forskjellige fra «projects», som vi betegner som en listevisning, og er alle tilgjengelige fra menylinjen. En listevisning inneholder oppgavelister i et hierarkisk oppgave-tre. Oppgaver med oppgavelister kan åpnes nedover i hierarkiet, til en oppgave ikke lengre har underoppgaver. En slik «bunnoppgave» får en oppgavevisning. En oppgavevisning gir utvidet funksjonalitet til en oppgave, slik som å legge til innhold, eller tildeling av oppgaven til et eller flere individer. 18

19 Navigasjon. Det alle visningsmodusene har til felles er at det ikke skilles mellom dem når det kommer til navigasjon i applikasjonen. Informasjonen som skal presenteres åpnes i en fane som bærer navnet på oppgaven eller spesialvisningen. I en oppgavevisning kan alle oppgaver åpnes i egen fane direkte fra visningen ved å trykke på ikonet som skal indikere legg til fane. Fanene kan åpnes eller lukkes uavhengig av hverandre, og navigasjon mellom disse for å utføre oppgaver skal være normalflyten i applikasjonen Oppdatering Ved oppdatering av innhold i en listevisning, eksempelvis ved tillegging, sortering eller flytting av oppgaver, vil alltid kun de berørte elementer oppdateres på siden. Ved å velge en slik strategi i stedet for å oppdatere hele fanen minskes server-lasten, og brukeren blir også gjort oppmerksom på hvilke deler av applikasjonen som oppdateres, gjennom en oppdateringsindikator. Oppdateringsindikatoren er en enkel animert gif, og dukker opp på siden hver gang større mengder med innhold oppdateres. Så snart oppdateringen er utført blir denne trinnvis borte, og innholdet kommer til syne i løpet av 0.4sekunder Tilstand Et av hovedformålene ved å velge en navigasjonsstrategi basert på faner var at brukeren skulle ha frihet til å åpne forskjellige visninger med samme innhold, jobbe med flere oppgaver på samme tid, og få inntrykk av å jobbe med en typisk vindusapplikasjon. For å oppnå dette trenger vi å vite hvilke faner som er produsert og hvilken av disse som er aktiv. Vi må også vite hvilken tilstand, åpen eller lukket, en oppgave har i en listevisning. Dette er løst ved at applikasjonen sender elementenes tilstandsstatus tilbake til serveren hver gang en navigasjonsoperasjon blir utført, og elementene blir så manipulert til å inneha denne tilstanden når disse bees vist igjen. Vi ønsker også at brukeren skal kunne navigere mellom faner som inneholder samme oppgaveliste i forskjellige nivåer uten at tilstanden til oppgavelisten forandres i annet en den aktive fanen. Dette er løst ved å knytte oppgavetilstand til en fane. 19

20 4.2. Klasse- og filstrukturer I dette delkapittelet vil vi belyse viktige moduler i Sir Jerky Leap SJLController SJLController arver AFWController, og er den mest brukte komponenten i applikasjonen. All kommunikasjon med nettleseren skjer ved kall til denne controlleren. I korte trekk fungerer denne ved at den snapper opp alle kall fra nettleseren og ser etter en «Query string» som inneholder do=something. Her er something navnet på en metode i kontrolleren som utfører ønsket funksjonalitet. I motsetning til en vanlig web-side vil kontrolleren bestemme hvilket innhold som returneres til nettleseren istedet for web-serveren som gir tilbakemelding basert på url. Kontrolleren henter nødvendige data fra «SJLProcessor», forklart i kapittel 5.2.3, og velger ønsket tilbakemelding til nettleseren ved å benytte «templates», som forklart i kapittel

21 TaskController TaskController er i essensen lik SJLController, da begge utvider AFWController, men kalles aldri direkte fra nettleseren slik som SJLControlleren. TaskController er en statisk klasse som inneholder alle metoder for å produsere oppgaver og oppgavelister SJLProcessor SJLProcessor arver AFWProcessor og har tilgang til verktøy som letter databehandlingen mot databasen. SJLProcessor foretar all datauthenting og datamanipulasjon i applikasjonen. Alle forespørsler om uthenting eller manipulasjon av data fra SJL- og TaskController behandles i sin helhet av SJLProcessor. Processoren eksponerer ikke databasen direkte for «controllerene», men benytter klasser definert i modell-laget for å representere en dataoppføring. I applikasjonen har vi valgt å benytte Memcached, som gjør av vi kan persistere objekter mellom hvert kall til applikasjonen, og «SJLprocessor» jobber mot dette laget parallelt med databasen. Mer om Memcached og hvordan dette benyttes kan leses om i Modell-laget Modell-laget inneholder klasser som benyttes av SJLProcessor for datarepresentasjon. For at AFW skal kunne skal kunne opprette dataobjekter må det eksistere en PHP-fil med klassedefinisjon i «model-katalogen» til applikasjonen. PHP har støtte for refleksive klasser og AFW utnytter dette ved å kunne opprette objekter som speiler databasen. Vi tilrettelegger for dette ved å legge filer som bærer samme navn som databasetabellene i modell-katalogen, og AFW oppretter objekter med alle tilhørende atributter ved behov. Det eneste kravet til innhold i en slik fil, er en klassedefinisjon. Objekter opprettet av AFW vil, i tillegg til alle tabell-attributter, også inneholde en unik AFWId som gjør at man kan manipulere og finne tilbake til objektet ved hjelp av AFW's innebygde metoder. Av klassene definert i modell-katalogen benyttes foreløpig de følgene; Task, Content, Resource og User. Da systemet primært baserer seg på oppgavelister, har vi valgt å la klassen «Task» inneholde metoder som kan hente ut underoppgaver, innhold, brukerobjekter m.m. og legge disse inn i «task»- objektene. 21

22 Templates Templates, eller maler, er et samlebegrep for HTML-filer med innskutt PHP-kode som mottar data, og basert på malen produserer HTML -kode. Templates benyttes av alle moduler som produserer brukergrensesnitt i applikajsonen. I all hovedsak er dette Tags, og «SJLControlleren.» Tags En Tag er en klasse med tilhørende templates som har som formål å produsere et bestemt GUIelement på websiden. I Sir Jerky Leap benytter vi tre tagger som grunnstener for visning av innhold TaskList TaskList benyttes for å produsere oppgavelister i en listevisning ref. Kap Denne taggen er en vidreutvikling av AFW-taggen AccordionEdit, som er nevnt i kapittel i prosessdokumentasjonen.tasklist-taggen er bygd opp av et knippe komponenter; klassen «Tasklist», templatene «tasklist.tpl», «tasklist_header.tpl», «tasklist_content.tpl» og «tasklist_js.tpl», javascriptkoden «tag.js», samt en statisk metode i klassen «SJLtag» Virkemåte Ved å bruke TaskList kan vi produsere interaktive sorterbare oppgavelister i en nettleser ved hjelp av HTML, CSS, og Javascript. Listene er strukturert ved å benytte HTML-taggene <dl>, <dt> og <dd>. <dl> definerer en liste, <dt> definerer tittel-elementet i en oppgave og <dd> definerer innholds-elementet i en oppgave. Eksempelvis vil en liste med to oppgaver ha en slik HTML-struktur (konseptuelt fremstilt): <dl> <dt> tittel-element </dt> <dd> innholds-element </dd> <dt> tittel-element2 </dt> <dd> innholds-element2 </dd> </dl> 22

23 Disse listene kan nestes slik at en oppgave kan inneholde underoppgaver. Dette gjøres ved å opprette en liste inne i innholdselementet til oppgaven. Eksempelvis vil en liste med to oppgaver, hvor oppgave nr to har tre underoppgaver ha en slik HTML-struktur: <dl> <dt> tittel-element </dt> <dd> innholds-element </dd> <dt> tittel-element2 </dt> <dd> <dl> <dt> tittel-underelement </dt> <dd> innholds-underelement </dd> <dt> tittel-underelement2 </dt> <dd> innholds-underelement2 </dd> <dt> tittel-underelement3 </dt> <dd> innholds-underelement3 </dd> </dl> </dd> </dl> Interaktiviteten til listene realiseres ved bruk av Javascript som oppretter DOM-objekter av hver enkelt liste når disse lastes inn i nettleseren. Det opprettes en hendelseslytter på hvert av tittelelementene, og denne reagerer hver gang en bruker klikker på et element. Deretter manipuleres elementene i DOM for å oppnå ønsket visning i nettleseren, eller kjøre Ajax-kall til bakenden Opprettelse Å opprette en oppgaveliste gjøres i korte ordedrag ved å opprette en instans av klassen TaskList, tilegne denne et sett verdier for å sikre at denne vil være unik i nettleseren og bestemme hvilke CSSklasser som skal benyttes. Deretter legges elementer inn i listen ved å kalle på metoden addelements. Denne metoden mottar to parametre, det første er en array med informasjon nødvendig for å produsere tittelelementet, det andre er en array med innhold og eventuelle CSSklasser nødvendig for å produsere innholdselementet. Listen med tittel- og innholdselementer kan 23

24 nå benyttes i en template ved å kalle på metoden «tasklist» i den statiske klassen «SJLTag» og sende med det ferdigproduserte TaskList-objektet som parameter. HTML-kode blir så produsert på bakgrunn av de forskjellige template-filene og den mottatte informasjonen Utvidelser «TaskList» følger samme oppbygging som AFW-Taggen AccordionEdit, og store deler av logikken for å generere selve trekkspill-listene er like i disse. Utvidelsene er først og fremst fremtredende i templatene og javascriptkoden. Det er gjort store endringer i hvilken informasjon som sendes med til addelement metoden ved opprettelse av et listeelement. Det sendes blandt annet med en oppgaves AFWId, brukerrettigheter, tillstandsinformasjon, og informasjon som viser om en oppgave inneholder underoppgaver i tillegg til den informasjonen som allerede er definert gjennom AccordionEdit. Denne informasjonen blir benyttet i sterkt utvidede templatefiler. For å identifisere et listeelement som en oppgave i bakenden har et hvert tittelelement fått en «relattribut» tilsvarende AFWId'en til oppgaven den genereres på bakgrunn av. «class-attributten» i tittelelementene har fått flere oppføringer for blant annet å identifisere oppgaver som bunnoppgaver. Tittelelementene er utvidet til å inneholde ikoner og andre GUI-elementer som utfører oppgaver utover åpning og lukking av en oppgave, noe det ikke var tatt høyde for i AccordionEdit. Innholdselementene er utvidet til å inneholde en administrasjonslinje som gir brukeren mulighet til å utføre funksjoner slik som å legge til, slette, eller endre oppgaver. Denne administrasjonslinjen blir produsert på bakgrunn av brukerens rettigheter i forhold til en oppgave, og vises kun om slike rettigheter foreligger. Javascriptkoden er utvidet for å kunne fange opp brukerinteraksjon og behandle elementer som ikke var tilgjengelige i AccordionEdit. Mesteparten av de nye funksjonene har ikke direkte tilknytning til en liste eller et listeelement, og er derfor skilt ut i egne metoder i filen «SJL.js» 24

25 TOCList TOCList benyttes for å vise en innholdsliste i en «bunntask». TOCList har mye av den samme funksjonaliteten som TaskList, men benytter andre templates og mottar andre parametre ved opprettelse enn en tasklist Tabs Taggen Tabs er en utvidelse av AFWtagen med samme navn, men er kraftig modifisert for å benyttes som et dynamisk navigasjonsverktøy, i motsetning til sin navnebror hvis hovedformål er å produsere en statisk horisontal menylinje. 25

26 5. Design Store deler av oppgaven gikk ut på å lage et system som var annerledes enn tilsvarende systemer, og også mer brukervennlig. Hvordan vi kom frem til det endelige designet av applikasjonen kan det leses mer om i prosessdokumentasjonen i kapittel Grafikk og fargebruk Farger Det å velge ut farger til en applikasjon kan være en krevende affære, og da ingen på gruppen har designbakgrunn hadde vi heller ingen forkunskaper som hjalp oss med å velge ut farger, og fargekombinasjoner. Vi benyttet derfor primært to webapplikasjoner for å velge ut farger, online colorpicker 2.1, og Kuler fra Adobe. Fargevalget falt på et fargetema som strekker seg fra lyse blågrønne toner til sjøgrønt i kombinasjon med lyse gråtoner som heller mot gult i fargespekteret.vi benyttet oss også av subtile gradienter for å lette den visuelle overgangen mellom tettliggende elementer Ikoner Vi benyttet oss av ikonsettet Silk, som ligger fritt tilgjengelig under Creative Commons Attribution 2.5 License. Dette ikonsettet er lite påtrengende. 6. Adgangs- og brukerkontroll I Sir Jerky Leap har vi valgt å benytte oss av en ferdigutviklet modul fra Aptoma AS, Sir Access, som adgangskontroll. Vi valgte å benytte Sir Access da denne allerede benyttes i andre systemer levert av Aptoma AS. Brukerkontroll fungerer ved at et bruker objekt produsert av Sir Access legges inn i en session-variabel, som sjekkes hver gang brukeren gjør et kall til applikasjonen. Om ikke dette objektet er til stede, eller har vært inaktivt for lenge, blir brukeren sendt til Sir Access for innlogging og returnert til Sir Jerky Leap ved fullført innlogging. 26

27 7. Utvidelsesmuligheter 7.1. Tilrettelegging Under utvikling av Sir Jerky Leap er det tilrettelagt for vidreutvikling av applikasjonen, gjennom å legge til tabeller i databasen som foreløpig ikke er i bruk, og mulighet for å produsere objekter og strukturer av disse. Det er klargjort for implementasjon, og delvis utviklet funksjonalitet utover det systemet tilbyr i dag. For en oversikt over disse funksjonene se vedlegg nr Database Databasen vår er klarlagt for flere funksjoner som ikke er implementert i applikasjonen ennå. Utvidelsene det er lagt til rette for er: Linking mellom oppgaver, notater, tilegning av en oppdragsgiver til en oppgave, timeføring på oppgaver og deling av ressurser. Figurene viser hvordan dette er tenkt implementert på databasenivå. 27