III. PRODUKTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

Transkript

1 III. PRODUKTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1

2 FORORD Denne rapporten er skrevet for personer med kompetanse innenfor informasjonsteknologi og beskriver de tekniske aspektene av modulen CvReg Tilbud i sin helhet. Denne rapporten er ment for personer som skal benytte seg av CvReg Tilbud generelt, videreutvikle modulen eller av andre grunner ønsker å sette seg inn i systemet. Det kan være fordelaktig å ha kjennskap til rammeverket Grails med alle teknologiene det benytter eller et annet fullstack MVC rammeverk, men det er ikke noe absolutt krav. 2

3 INNHOLDSFORTEGNELSE FORORD BESKRIVELSE AV APPLIKASJONEN CVREG MÅL OG RAMMEBETINGELSER Mål for prosjektet CvReg Tilbud Rammebetingelser Kravspesifikasjon Endring i kravspesifikasjon Avvik fra kravspesifikasjonen MVC RAMMEVERK MODULENS STRUKTUR Oppbygning Domeneklasser ER-diagram over de genererte tabellene i databasen Språk i koden DESIGN OG FUNKSJONALITET CV view Legg til tilbud fra CV view Liste over tilbud Slette et tilbud Opprette et tilbud Tilbud-view Detaljvisning Legg til CV i tilbud Redigere tilbud Tilbud-klasse (domain class) Tilbud-kontroller Tilbud i koden Slette tilbud

4 5.13 RemoteFunction RenderDetails ØVRIG DOKUMENTASJON Brukermanual Testrapport UTVIDELSESMULIGHETER BESKRIVELSE AV APPLIKASJONEN CVREG Knowit Oslo har per i dag et eksisterende system hvor ansatte kan fylle ut sine CV-er. Det er en web-applikasjon for å registrere arbeidserfaring, kompetanseområder, styrker, svakheter og informasjon om hver enkelt ansatt. Dette på en måte som er enkel, søkbar og lett tilgjengelig både for utviklere og selgere. CV-ene kan eksporteres som PDF, ODT eller DOCX format, for så å kunne sendes ut til potensielle kunder, eller brukes internt i bedriften. Det er to grupper av brukere i dette systemet: Brukere: Utviklere (ansatte i Knowit), registrerer sine CV-er etter en universelt utformet mal, som gir en felles standard for de registrerte CV-ene i systemet. De ansattes personalia fylles inn i systemet som lager en pent formatert CV. De ansatte vil kunne se hvilke tilbud de er oppført i, og hva dette tilbudet går ut på og CV-ene kan lastes ned som PDF dokumenter direkte fra siden. Administratorer: De som oppretter, setter sammen og administrerer tilbudene. Dette kan for øvrig også være vanlige ansatte som har fått tildelt administrator rettigheter. Administratorrollen er implementert gjennom systemet i sin helhet, så disse kan redigere andres CV-er, legge til kategorier for fagfelt etc. I dette dokumentet blir ordet CV brukt for å indikere bruker eller profil. Dette fordi det er CV-ene som er essensiell for applikasjonen, og det er brukerens CV som inneholder informasjonen og knytter andre relevante moduler sammen. 4

5 2.0 MÅL OG RAMMEBETINGELSER 2.1 Mål for prosjektet CvReg Tilbud Knowit så potensialet i applikasjonen CvReg og ønsket å utvide den med ytterligere funksjoner. Et av ønskene fra salgsdivisjonen i bedriften var muligheten til å sette sammen en gruppe ansatte, via deres registrerte CV-er i systemet. Denne sammensetningen av CV-er kalles et Tilbud, som da representerer et planlagt prosjekt. Dette gjøres for å få en oversiktlig måte å samle de personer som skal inkluderes i et fremtidig oppdrag. Et tilbud består da av: Navnet på prosjektet En beskrivelse av hva prosjektet går ut på Hvem som er ansvarlig for dette prosjektet (selger) En liste over hvilke deltakere prosjektet har. En startdato En sluttdato Hvert tilbud har verdien aktiv eller ikke aktiv. Verdien blir satt utfra hvorvidt prosjektets sluttdato er nådd, og hvorvidt prosjektets startdato er nådd. Hvis dags dato er imellom disse to, er prosjektet aktivt. Disse tilbudene skal kunne opprettes, redigeres og slettes i en modul som blir kalt CvReg Tilbud. 5

6 2.2 Rammebetingelser CvReg er utviklet i rammeverket Grails, som generelt benytter seg av programmeringsspråket Groovy, som er en avart av standard Java. Videre er brukergrensesnittet i applikasjonen utviklet ved hjelp av Twitter Bootstrap. Twitter Bootstrap er en gratis samling av verktøy for utvikling av nett applikasjoner. Hovedsakelig er dette en samling av HTML og CSS maler, men som også kan utvides med valgfrie JavaScript utvidelser. Dette satte dermed rammen for hvordan brukergrensesnittet til den nye modulen ble utviklet. 2.3 Kravspesifikasjon En kravspesifikasjon har blitt utviklet i samråd mellom Knowit og gruppen fra Høgskolen tidlig i prosjektet. Knowit har klare mål for hva som er ønsket at skal være med i modulen CvReg Tilbud og hvordan brukergrensesnittet skal se ut. Denne kravspesifikasjonen er å finne som vedlegg 1 i dette dokumentet. Kravspesifikasjonen som forelå var delt inn i to deler: Milepæl 1 og Milepæl 2. Milepæl 1 var ment som et minimumskrav til hva som skulle bli levert ved prosjektets slutt, og Milepæl 2 var ment som en mulig utvidelse, hvis tid og ressurser tillot det. Kun milepæl 1 ble nådd under dette prosjektet, som også var minimumskravet. Det er noen elementer i sluttproduktet som mangler fra kravspesifikasjonen. Dette er noen mindre funksjoner eller detaljer som er definert i kravspesifikasjonen milepæl 2. Ellers ble alle punktene i den første milepælen oppnådd. Alle kravene er testet og bekreftet gjennomførte ved prosjektets leveringsdato. Den andre milepælen ble ikke oppfylt. Dette står nå på listen over utvidelsesmuligheter. 6

7 2.4 Endring i kravspesifikasjon Kravet om at en timeoutfunksjon skal endre tilbudets status fra aktiv til inaktiv etter en tid, ble revaluert underveis i utviklingen. Denne funksjonen eksisterer nå som en metode som evaluerer hvorvidt tilbudets sluttdato har passert, og hvorvidt startdatoen er nådd. Hvis en av disse to er tilfelle, vil tilbudet vises som inaktivt, og hvis dags dato ligger mellom disse to verdiene er tilbudet aktivt. 2.5 Avvik fra kravspesifikasjonen Responstiden for enkelte handlinger i applikasjonen har tidvis gjennom utviklingsprosessen vært lengre enn kravet på maksimalt tre sekunder. Dette har skyldtes tunge databasekall og dårlig optimalisert databasehåndtering på systemet som kjører lokalt på våre utviklingsmaskiner. Det gjelder spesielt visning av tilbudsdetaljer, hvor responstiden har overskredet 8 sekunder i noen tilfeller. Etter noen justeringer i koden er den nede på 3,5 sekunder, og når applikasjonen kjøres på en fullverdig webserver vil denne være ytterligere forbedret. I slutten av rapporten finnes det en liste over utvidelsesmuligheter for senere iterasjoner, som baserer seg på milepæl del to. Dette er de målene som ikke ble nådd i dette prosjektet. 7

8 3.0 MVC RAMMEVERK Figur 3.1: MVC Rammeverk MVC (Model - View - Controller), er et rammeverk som deler applikasjonen inn i data modeller og brukergrensesnitt view, slik at utformingen av brukergrensesnittet ikke har noen innvirkning på hvordan dataen i applikasjonen blir håndtert, eller motsatt. Denne typen rammeverk benyttes veldig ofte i forbindelse med objekt orientert programmering, der dataene er definert i klasser som igjen er utgangspunktet for genererte objekter. Illustrasjonen over illustrerer forholdet mellom presentasjonslaget, businesslaget og dataaksesslaget. Dataaksesslaget behandler klasser og forholdene definert mellom dem, og oppretter tabeller og restriksjoner 8

9 i databasen uten behov for direkte innvirkning fra utvikleren. Dataaksesslaget er også ansvarlig for å opprette og håndtere objekter som kan kalles på fra businesslaget. Objektene er en umiddelbart manipulerbar representasjon av datamodellen man forholder seg til under applikasjonsutviklingen. Businesslaget er ansvarlig for å håndtere forholdet mellom logikken vi skriver i kontrolleren, og klassene som eksisterer i datalaget. Mye av dette skjer under panseret og er en del av fullstack-applikasjonen som er ferdig konfigurert til CvReg som system. Presentasjonslaget består av controllers og views. Controlleren fungerer på en måte som en veiviser for datastrømmen mellom brukeren og systemet. Der opprettes objekter etter behov og data fra skjema og bruker fylles inn der det skal. Controlleren brukes både til å lagre og presentere data og til å bestemme hva som skal returneres til view. Viewet er filen som Grails bruker til å generere kode til nettleseren. I viewet brukes Groovy tags til å representere data og generere skjema, og man kan bruke variabler og returnert data fra applikasjonen til å lage dynamisk genererte websider på en fleksibel måte. I Grails er det vanlig at domeneklasser ofte benytter en kontroller og et view med samme navn som klassen selv. Dette gjør det lett å forholde seg til de forskjellige elementene i programmet. I tillegg til at kontrolleren ofte benytter samme navn som klassen, har de også alltid suffikset Controller, som gir et tydelig navn skille mellom de to entitetene. Tilsvarende er det det samme med views. Hver view som tilhører en kontroller, ligger da også ofte i en mappe med samme navn som kontrolleren og klassen. Utenom dette er det vanlig at subklasser, det vil si klasser som utvider andre klassers egenskaper, ikke alltid trenger å ha egne kontrollere eller egne views. Dette kan være klasser som enten, ikke har data som skal presenteres, men som heller blir brukt til utregninger eller lignende, eller har data som blir presentert 9

10 gjennom andre klasser og kontrollere. Noen av disse har funksjoner som skal være tilgjengelig overalt i løsningen og som dermed ikke nødvendigvis har noen spesiell tilhørighet. 10

11 4.0 MODULENS STRUKTUR 4.1 Oppbygning Løsningen som er utviklet er i korte trekk en tilleggsmodul i CvReg. Den er integrert i systemet i den forstand at det brukes eksisterende klasser og datamodeller i tillegg til de vi har supplert, for å skape en ny funksjonalitet i CvReg. Modulen CvReg Tilbud henter data fra Bruker-klassen og dens tilhørende klasser for å presentere data om brukeren, og for å binde dem sammen med Tilbudsklassen som vi har laget. CvReg Tilbud er også en tett integrert del av systemet i sin helhet, da rammeverket som dette ligger i er veldig modulært og dynamisk - det har en høy grad av granularitet med mange separate moduler som snakker sammen. Dette gjør det lett å få en god flyt i applikasjonen, og gjør at det er lettere å bruke en funksjon mange ganger i form av objekter og instanser. Lagdelingen i applikasjonen gjør det mulig å gjøre endringer ett sted uten store konsekvenser andre steder, så lenge man holder seg innenfor standardene satt av applikasjonen. Denne illustrasjonen beskriver hvordan tilleggsmodulen CvReg Tilbud føyer seg inn i applikasjonen som helhet: 11

12 Figur 4.1: Oversiktsdiagram av CvReg Man ser et omriss av dataflyten i systemet, og selv om modellen er forenklet viser den både eierskapsforhold mellom CV-er og tilbud, og rollen til administratorer i applikasjonen. Senere i dokumentasjonen blir det presentert en spesifikk use-case for å illustrere hvordan en handling forløper seg for brukeren. Videre i rapporten skal vi dykke dypere inn i systemet og se på kildekoden som ligger bak, og hvordan dette fullstack-systemet behandler forespørselen. 4.2 Domeneklasser Under vises et utsnitt av domeneklassenes avhengigheter og hvilke domeneklasser som har noe med hverandre å gjøre: 12

13 Figur 4.2: Relasjonsdiagram Som vist på diagrammet over kan en se at det er hver enkelt persons CV som er det mest essensielle i applikasjonen. Hver enkelt CV er knyttet til alle de andre forskjellige aspektene ved applikasjonen. Ytterst i applikasjonen ligger hver persons bruker i systemet. Denne brukeren er igjen knyttet til tre forskjellige elementer: Profil, Tilbud og CV. Det at CV-klassen er knyttet til resten av applikasjonens egenskaper fremfor Bruker-klassen, er fordi det er hver enkeltes CV som representeres i applikasjonen, og det er denne informasjonen som er benyttet til visningen av hver enkelt deltagers profil. 13

14 Det vil kun bli drøftet og forklart kode for de forskjellige delene av applikasjonen som er utviklet av studentene selv, og ikke kode som eksisterte fra før i applikasjonen. 4.3 ER-diagram over de genererte tabellene i databasen Merk at ER-diagrammet under er en oversikt over de genererte tabellene i MySQL databasen, basert på klassene som eksisterer i applikasjonen. I klassen proposal har vi for eksempel en verdi med navn proposalmanager. Denne er av typen User i klassen. I den genererte tabellen i databasen får denne datatypen integrer, og et navn som indikerer at den refererer til verdien id i tabellen user. I tillegg til dette blir verdien oppført som en fremmednøkkel mot tabellen user. Slike endringer blir håndtert automatisk av Grails, basert på et sett med predefinert konvensjoner. Figur 4.3: ER-Diagram 14

15 4.4 Språk i koden All koden og alle variabler er etter industristandard skrevet på engelsk. Klassen for Tilbud får navnet Proposal, klassen for bruker får navnet User, etc. Dette er for at hvem som helst skal kunne bruke koden uten å måtte slå opp i noen ordbok. Det er også mye lettere å være konsekvent på navngiving av variabler når alt forblir på engelsk. For å gjøre applikasjonen mest mulig fleksibel benytter CvReg seg av den godt utbygde internasjonaliseringsfunksjonen i Grails. Her lager man et dokument med egendefinerte tagger som korresponderer til en tekststreng. I koden kan man kalle på denne taggen, og få presentert teksten den korresponderer med. Dette kommer virkelig til sin rett når man har mange språkfiler med gode oversettelser - ved å endre på en enkel variabel kan man vise hele siden nøyaktig like godt uansett hvilket språk brukeren ønsker. 15

16 5.0 DESIGN OG FUNKSJONALITET CvReg Tilbud har en rekke egendefinerte funksjoner som legger seg til de eksiterende funksjonen fra CvReg. Disse er implementert sømløst i applikasjonen, enten via den nye siden som heter Tilbud eller innenfor selve CV siden. 5.1 CV view Figur 5.1: CV-View 16

17 Over vises et view, som viser en oversikt over brukerens eksisterende CV-profil. Denne oversikten vil brukeren selv være nødt til å fylle ut, men det er ikke nødvendig for at tilbudsmodulen som vi har utviklet skal fungere. I bildet så er både lenken til den nye Tilbud siden og nye Tilbud knappen på CV siden synlige. Disse representerer implementeringen av CvReg Tilbud i CvReg applikasjonen. 5.2 Legg til tilbud fra CV view Figur 5.2: CV-View-Legg til CV 17

18 Det er mulig å legge CV-er inn i tilbud fra CV-view. Dette kan enkelt gjøres ved å klikke på + Tilbud til venstre i CV menyen. Dette vil hente fram et poppup vindu med muligheten for å bla i en drowdown liste over alle som jobber i Knowit. Dette vinduet lister også opp hvilke eksisterende tilbud CV-en (som er valgt) er deltager i. 5.2 Liste over tilbud Figur 5.3: Vis tilbud Listen over tilbudene registrert i applikasjonen (som vist over), fungerer også som en meny - når man holder musepekeren over en av linjene i listen endrer den farge. Når den klikkes på, lastes detaljert informasjon om tilbudet inn i det høyre feltet av skjermbildet. 18

19 Listen er delt opp i tre faner øverst i visningen, for å gjøre det lettere å sortere tilbudene. Her kan man velge om alle tilbud skal vises, eller så kan kun de aktive vises, eller kun de inaktive. 5.3 Slette et tilbud På høyre ende av hver linje finner vi en knapp for å slette det relevante tilbudet. Når den trykkes på kommer det en bekreftelsesmelding på skjermen som forklarer at tilbudet vil slettes, og at ingen CV-er blir fjernet fra systemet. Den ser slik ut: Figur 5.4: Slett tilbud Når brukeren så trykker på den røde knappen, blir tilbudet fjernet fra listen, og siden lastes inn på nytt. 5.4 Opprette et tilbud Nederst på siden, under opplistingen av alle eksisterende tilbudene ligger knappen for å opprette et nytt tilbud, + Nytt tilbud. Denne knappen vil laste inn et skjema i høyre del av skjermbildet, som lar deg registrere et nytt tilbud. Dette view ser slik ut: 19

20 Figur 5.5: Legg til tilbud Dette skjemaet er veldig enkelt. De eneste kravene som stilles er at: navn, start og slutt dato er utfylt. 20

21 5.5 Tilbud-view Dette er hovedsiden for tilbudsmodulen. Det er her mesteparten av alle operasjoner angående tilbud finner sted. Denne siden viser en oversikt over alle de eksisterende tilbudene. Denne listen er delt inn i tre kategorier: Alle eksisterende tilbud, Aktive tilbud og inaktive tilbud. Under er lite utsnitt av _form.gsp. Figur 5.6: _form.gsp utsnitt Denne koden er en del av koden som utgjør brukergrensesnittet for opprettelse av et nytt tilbud. Her ser vi koden som viser et tekstfelt med en tilhørende merkelapp (label). <div class= controll-group >: Bestemmer hva slags type kode den påfølgende koden er, som da vil gi denne koden visse egenskaper definert i Twitter Bootstrap (beskrevet tidligere i dokumentet). <label for= new-proposal-name >: Standard HTML kode for opprettelse av overskrift for et element med tilhørende navn. 21

22 <input type=, id=, name=, placeholder=, value=, class= >: Definerer at det skal vises et innputt felt av typen tekst, at dette feltet skal ha id-en new-proposal-name. Placeholder= definerer hvilken forhåndsbestemt tekst som skal vises i tekstfeltet. I dette tilfellet er det benyttet en globalisert tekst behandling. Dette åpner for muligheten til enkelt å kunne velge språket applikasjonen skal presenteres i, uten at en trenger å endre på noe kode i applikasjonen. 5.6 Detaljvisning Når brukeren trykker på et tilbud - hele linjen fungerer som en knapp - så lastes detaljer om tilbudet inn dynamisk på høyre del av nettsiden. Det høyre feltet brukes til både å se detaljer om et tilbud, å opprette et nytt tilbud og til å redigere eksisterende tilbud i applikasjonen. Først tar vi for oss detaljvisningen: Figur 5.7: Detalj-visning av tilbud 22

23 Detalj-visningen av tilbudet inneholder navnet på tilbudet, fra- og til-datoene, en mer utfyllende beskrivelse av tilbudets art og omfang, samt en liste over de som er med i tilbudet. Nederst fins det en knapp for å gå til redigeringsiden der tilbudsinformasjonen kan endres hvis nødvendig. Listen over personer som er inkludert i tilbudet har to interaktive funksjoner. Første funksjonen er selve navnene er lenker til den aktuelle personens CV i dette systemet. Dette gjør det enkelt å få mer informasjon om den ansatte. Den andre funksjonen er en slette-knapp på høyre siden av listen. Denne knappen fjerner den aktuelle personen fra tilbudet. Det kommer ikke opp noen bekreftelses boks når denne trykkes på. Dette er utelatt da det er enkelt nok å legge til personen på nytt, samt vanskelig nok å slette mer enn en person i vanvare. Når man trykker på denne sletteknappen for å fjerne en person fra tilbudet, blir personen fjernet uten at hele siden lastes inn på nytt - kun boksen med presentasjonen lastes inn igjen. 23

24 Under vises et utdrag av koden som gir en del av skjermbildet (henvisning til skjermbilde nr.) Figur 5.8: Detalj-visning kode Dette er veldig mye vanlig HTML kode, men er tatt med her for å beskrive hvordan en kan bruke Groovy kode direkte i et view (.gsp filer). Øverst i koden markert i gult, er det blitt benyttet en if test midt i koden: <g: if test= ${user?.isadmin} >. Det er mulig å benytte Groovy-kode ved å skrive: <g: etterfulgt av Groovy kode. Alle slike tags avsluttes med en respektiv </g:> tag, slik som det er gjort i bunnen av denne kodesnutten. Det denne kodesnutten faktisk gjør, er at den kjører en spørring på klassen user sin isadmin funksjon. Denne funksjonen returener en tru eller false verdi basert på om brukeren er administrator eller ikke. Det samme er gjort for den delen av koden som er markert i blått. Forskjellen på disse to kodesnuttene er at den siste i blått i tillegg til å benytte seg av en allerede eksisterende variabel fra klassen Proposal (proposals automatisk genererte id felt), og så lagrer denne verdien i en hiddenfield. Grails sender med alle verdier som eksisterer innenfor formremote-taggene tilbake til kontrolleren. 24

25 5.7 Legg til CV i tilbud Figur 5.9: Legg til CV i tilbud For å legge til en CV i tilbudet, kan man velge et navn fra nedtrekks menyen i detaljvisningssiden. Når man trykker på knappen merket legg til, vil denne delen av siden lastes inn på nytt for å reflektere endringen. Knappen merket rediger tar brukeren med til en ny side, for å redigere tilbudet. Dette skjemaet er det samme som brukes til å legge til et nytt tilbud, men med den eksisterende tilbudsdataen lagt inn. 25

26 5.8 Redigere tilbud Figur 5.10: Rediger tilbud Å redigere et tilbud er veldig enkelt. All tidligere registrerte data hentes inn i formen, og alle endringer av feltene i formen vil bli lagret i databasen. 26

27 5.9 Tilbud-klasse (domain class) Domain class filen er selveste Modellen i MVC-rammeverket, og er det som definerer datastrukturen i programmet. Klassedefinisjonen spesifiserer hvilke verdier som skal kunne lagres i databasen. I tillegg til de vi har opprettet her, genererer også DBHS felt for id og version som begge auto-inkrementeres når felter i databasen legges til eller endres. Figur 5.11: Domain class Over ser du et utsnitt av domeneklassen for Proposal. En domene klasse inneholder en rekke datafelter, som representerer verdier eller egenskaper en ønsker at et objekt skal ha. I Grails er en domene klasse også en definisjon på en tabell i databasen som tilhører prosjektet. Dette fordi Grails automatisk oppretter disse 27

28 tabellene basert på den informasjonen som blir gitt i domene klassen. Dette betyr at hele applikasjonen bygger på hvilke domene klasser som eksisterer, og hvilke relasjoner disse har til hverandre. Videre følger en forklaring på koden i bildet over. Kode: class Proposal: Definerer navnet på klassen, og utgjør navnet på tabellen i databasen. Date date_ended: Definerer tilbudets slutt dato. Denne datoen benyttes i applikasjonen for å bestemme hvilke tilbud som er aktive og inaktive. Date date_started: Definerer tilbudets start dato. Start dato har i prinsippet kun en informativ hensikt, da dens eneste hensikt er å informere brukerne om når et fremtidig tilbud er tiltenkt. String description: Er datafeltet som inneholder beskrivelsen til tilbudet. Denne informasjonen er tekst lagret i en String. String name: Inneholder navnet på tilbudet. User proposalmanager: Er datafeltet som bestemmer hvilken ansatt som har ansvaret for et bestemt tilbud. Alle tilbud kan ha en ansvarlig, men dette er ikke et krav. Videre i koden har vi det som kalles for relasjonsbestemmelsene for klassen: static belongsto = CV: Er en deklarasjon som bestemmer at denne klassen Proposal, skal være et barn child av CV-klassen. static hasmany = [cvs: CV]: Bestemmer at disse klassene er i et mange til mange forhold med hverandre. Disse to deklarasjonene bestemmer da også relasjonene mellom tabellene i databasen. Til slutt har vi datafeltenes begrensninger: 28

29 static constrinats = {: Er en definisjon som sier at de påfølgende linjene inneholder begrensinger for de respektive datafeltene nevn. date_ended size: , nullable: false: Bestemmer at verdiene i datafeltet kun kan ha en verdi på størrelse mellom 0 og 500 tegn Tilbud-kontroller Kontrolleren er da det mellomliggende elementet mellom brukergrensesnittet og domene klassen, som bestemmer hvordan dataene i klassen skal bli representert i brukergrensesnittet. Dette gjøres ved å definere funksjoner med kode som behandler de dataene som eksisterer i klassen, og om de skal bli sendt med til view-et. Under følger et utsnitt av kontrolleren til Proposal klassen, og en dypere forklaring på koden. Figur 5.12: Proposal Controller Kode: def index() : Er en standard metode (funksjon), som fungerer helt likt som en konstruktør i klassisk Java. Index metoden automatisk blir kalt på om den inneholder noen kode. Det er mest vanlig i denne metoden å definere hvilket view en ønsker at skal bli lastet inn først i applikasjonen, men en kan også på denne måten 29

30 bestemme hvilken kode i kontrolleren som skal utføres i det et view blir vist på skjermen. I dette tilfellet er denne metoden ikke benyttet. def create(): Er metoden som blir kalt når en i applikasjonen oppretter et nytt tilbud (som beskrevet i brukermanualen). Fra _form.gsp (et tilhørende view), blir all informasjonen om det nye tilbudet sendt og kan benyttes i denne metoden. Proposal proposal: Definerer at det skal eksistere en instans av klassen Proposal, med navnet proposal. proposal = new Proposal(): Er kode som oppretter en ny instans av klassen Proposal med de verdiene som er definert innenfor denne metoden. name: params.proposalname: Sier at feltet name (som er et datafelt i klassen, og da også en rad i den tilhørende tabellen Proposal i databasen), skal ha verdiene som finnes i params.proposalname. Params er en Groovy funksjonalitet som inneholder alle verdiene tilsendt av et view. Her betyr dette at params inneholder alle verdiene for både: name, description, date_started og date_ended. Viewet til hovedsiden for tilbudsmodulen ser slik ut: 30

31 Figur 5.13: Tilbudsmodul Her opprettes de tre fanene som deler opp tilbudene i aktive og ikke aktive tilbud - og en tredje fane med begge blandet og sortert etter navn. Nederst i koden ser vi en Grails tag som rendrer et template view som heter container. Dette viewet har ikke behov for å kalle på noen controller action, men er kun et statisk skjelett for innholdet i siden Tilbud i koden Listen over tilbud ligger i koden som en vanlig tabell med felter for navn, start dato, slutt dato og til slutt en knapp for å slette tilbudet - men den synes kun om man er logget inn som administrator. 31

32 For hver av tilbudene som applikasjonen finner i databasen, lages det et ny linje i tabellen. Den ser slik ut i proposal viewet, og er en del av _list.gsp, som igjen ble rendret i _container.gsp, som ble kalt på i index filen som nevnt i forrige avsnitt. Figur 5.14: Proposal form 5.12 Slette tilbud Knappen for å slette hele tilbudet lages av en Grails render tag, som henter opp en feles klasse for å generere en slett-dialog. Knappen vises kun for innloggede brukere som passerer testen isadmin, som returneres til viewet gjennom Main-controlleren. Denne slette klassen tar et par innparametere for å avgjøre hva som skal slettes, som igjen da sendes tilbake til controller. Vi har en controller action som heter delete(), som ser slik ut som dette: 32

33 Figur 5.15: Slette kode For å slette et proposal må man først fjerne alle tilhørigheter mellom proposal og cv. Disse opprettes av GORM (Grails object relationship manager), som er bindevevet mellom applikasjonen og DB. GORM håndterer data som objekter i minnet, og det er mange praktiske snarveier man må være oppmerksom på når man skal bruke GORM til å håndtere databaserelasjoner. Fordelene er mange, men det er noen begrensinger som vanskeligjør databehandlingen. I dette tilfellet må det opprettes et array bestående av alle medlemmene av et proposal, for å så be GORM fjerne hver av deltagerne i arrayet. Løsningen unngår problemer med at det blir konflikt mellom dataobjekter i minnet og datastruktur i databasen. Til slutt, når det ikke er flere restriksjoner i databasen som hindrer admin-brukeren i å slette proposal, så blir proposal.delete utført, med (flush:true) på slutten for å være sikre på at endringen blir videreført til databasen RemoteFunction Hver linje i tabellen med listen over de eksisterende tilbudene har en onclick-funksjon som gir tabellen funksjonalitet som en navigeringsknapp. Når linjen klikkes på eksekveres denne koden: 33

34 Figur 5.16: remotefunction remotefunction er en Grails-tag som generer et AJAX-kall for oss. Den tar innparametre om hvilken action i controlleren som skal kjøres, hvilke parametere som skal sendes med fra view og hvor i nettsiden endringen skal utføres. Den er fleksibel nok til å utføre mange forskjellige oppgaver, men dette var bruksområdene vi hadde i denne sammenhengen RenderDetails Figur 5.17: renderdetails Controller actionen som kalles på her heter renderdetails. Den bruker vi til å hente ut et objekt av typen Proposal. Dette inneholder alle datafeltene i klassen, i tillegg til en del metainformasjon og generert data som vi kan benytte oss av. Gjennom modellen gjør vi den tilgjengelig med nøkkelnavnet proposal. Vi sender også med elementet user, for å forsikre oss om at administratorstatusen kan valideres i neste view. 34

35 Use Case Administrator legger til CV i et Tilbud For å gå mer i dybden hva angår applikasjonens virkemåte og logikken som ligger bak den, presenteres det her et use case med tilhørende diagrammer for å illustrere en isolert funksjon i applikasjonen. Dette er både et eksempel på hvordan metodekall brukes og på hvordan et mange-til-mange forhold løses i applikasjonen. Funksjonen det fokuseres på ligger tilgjengelig i presentasjonen av Tilbudet og har som oppgave å legge til en forbindelse mellom et gitt tilbud og en CV, slik at CV-en blir inkludert i tilbudet. I presentasjonen av Tilbudet velges en CV i en rullegardinmeny. I listen i menyen finner vi navnet på alle personene som har en CV registrert i systemet. Når ønsket person er valgt, trykker brukeren på knappen merket 'legg til i tilbud.' Siden lastes inn på nytt, med den valgte brukeren lagt til i oversikten over inkluderte CV-er. Figur 5.18: Use Case Diagram Use case scenario er beskrevet i vedlegg 4. 35

36 Dette er en grunnleggende funksjon i applikasjonen, men bak den ligger fortsatt mye kode. I kontrolleren opprettes det to objekter av typene CV og Proposal. Minner igjen om at koden er på engelsk, Proposal omtales ellers som Tilbud. Illustrasjon av hvordan CV legges til i Tilbud, i controlleren: Figur 5.19: Proposal Parameteren med navn PersonInclude hentes fra nedtrekks listen i skjemaet på nettsiden. Den brukes for å hente inn et nytt objekt av typen CV med verdien som korresponderer med parameteren. ProposalId brukes for å identifisere det aktuelle tilbudet, og hentes inn fra et annet, skjult skjemaelement på siden. Igjen opprettes et nytt objekt, denne gang av typen Proposal (tilbud). Neste linje bruker en funksjon i Grails som genererer dynamiske metoder. Dynamiske metoder er en måte å gjøre kall på objekter uten å eksplisitt skrive selve kallet. Man skriver en verbal instruks til hva programmet skal hente eller behandlet, og Grails genererer alle de nødvendige metodene. Dynamiske metoder har begrenset med funksjonalitet, men kan være veldig kraftige. I dette tilfellet brukes det for å instruere GORM til å legge til CV til Proposal - enkelt og greit ved å skrive "CV.addToProposal(proposal)". 36

37 Til sist lastes detalj-visningen i nettsiden inn på nytt med kommandoen redirect. Vi gir innparameteret action: renderdetails for å fortelle kontrolleren hvilken Action vi skal bruke for å laste inn siden på nytt, og sender med ID-verdien til tilbudet for at denne Action skal vite hvilket tilbud den skal laste inn på nytt. En mer detaljert oversikt over hvordan dette spesifikke kallet gjennomføres på serveren er forklart i vedlegget nummer 5 Dette vedlegget illustrerer steg for steg veien kallet som har blitt forklart her tar igjennom applikasjonsstacken. 37

38 6.0 ØVRIG DOKUMENTASJON 6.1 Brukermanual En brukermanual er blitt utredet som beskriver de grunnleggende funksjonene i CvReg Tilbud modulen. Brukermanualen finnes som Vedlegg 2 i sluttrapporten 6.2 Testrapport En testrapport ble også utredet under og ved slutten av utviklingen for å kvalitetssikre CvReg Tilbud. Testrapporten finnes som Vedlegg 3 i sluttrapporten. 38

39 7.0 UTVIDELSESMULIGHETER Flere funksjoner i modulen CvReg Tilbud kan utvikles videre eller utbedres. Noen av dem er konkrete funksjoner som er listet her. Kalenderfunksjon: kode for bruk av Bootstrap kalenderfunksjon i CvReg Tilbud modulen har blitt lagt til i filen som heter _date.gsp, men den er ikke aktiv på grunn av problemer med implementering. En versjon av Grails sitt kalenderfunksjon er i bruk per dags dato i modulen. Funksjonelt så virker kalenderfunksjon som den skal i modulen, men følger ikke design mønsteret til resten av CvReg applikasjonen. Da ingen av målene for milepæl to ble utviklet under prosjektet, inngår disse i listen over elementer som kan utvikles i senere iterasjoner. - Advarsel om at en CV allerede er blitt inkludert i ett annet aktivt tilbud. - Funksjon for å laste opp vedlegg til et tilbud (pdf, bilder, video, etc ) - Funksjon for å laste ned alle CV-er i et tilbud som zipfil - Utvidet sortering av tilbudene i tilbuds viewet, som f.eks. sortering på navn, start og slutt dato. - Konvertere fra Grails egen date picker til Bootstrap DatePicker. - Multi seleksjon for å legge til CV-er i et tilbud. - sende e-post til CV bruker når CV er lagt inn i tilbud 39