Labb 4: Fullstack med Vue (Vite) och Express

INSTRUKTIONERNA KAN KOMMA ATT ÄNDRAS I.SF MEDDELAS BÅDA HÄR OCH VIA ANSLAG.

230303, kl 16.00 : Beskrivning om filstrukturern och information om vilka filer som behöver modifieras samt vilka filer som behöver läggas till har uppdaterats. Modifierade text har markerats med ikonen 🆕  

230324, kl 23:59: länk till mappen för chattprogrammet har lagts till i Del2 nedan markerat med 🆕.

230327, kl 11:00: filstrukturen filen util.js var överstruken av misstag. 🆕.

230328, kl 11.00 demo till del 2 är tillgänglig 🆕.

Översikt

I den här labben ska ni bygga ett labbokningssystem för att kunna boka in labbtider hos specifika handledare. För att komma igång med labben är det bra att kika i alla README:n i git-repot ni fått tillgång till.

Denna labb består av två obligatorisk delar samt en frivillig bonus-del. I del1 kommer du skriva kod för front-end av applikationen medan i del 2 kommer du skriva kod för back-end samt införa de modifieringar som behövs för att sätta ihop front-end och back-end till en enda applikation. Även om del 2 bygger på del 1 så måste varje del redovisas för sig själv. Om du väljer att vänta med redovisning av del1 och vill redovisa del 1 när du har skrivit del 2, se till då att du har koden för del 1 separat från de ändringar som görs i koden i samband med implementation av del 2 så att du kan redovisa koden för del 1 för sig själv.

Systemet ska bestå av 3 följande sidor:

• En bokningssida (ingen inloggning behövs för att besöka sidan) där studenter kan se handledarnas namn och vilka tider som finns för en handledare.
• En bekräftelsesida där studenter fullbordar en bokning efter att ha valt en tid genom att ange sitt namn och trycka OK.
• En inloggningssida för att logga in som administratör och få tillmgång till adminsdian (se nästa punkt).
• Adminsida där en handledare kan logga in med namn och lösenord och därefter redigera sina tider (ta bort/lägga till), på denna sida syns även vilka som bokat en viss tid.

Del 1 (Demo för del 1 Links to an external site. lösenord är "1234" men användarnamn kan välja hur som helst)

I den här delen kommer du jobba med Vuejs och tanken är att du skapar de fyra sidorna som är beskriven under översikt sidan. Men den delen körs endast på klient-sidan och har inte någon koppling till någon server. Därför en del data hårdkodas i del 1 för att senare i del 2 motsvarande information ska hämtas från databasen via servern.

🆕230303 Nu har du fått en mapp för lab4 del 1 i git.  När du är klar med den här delen av labben kommer filstrukturen se ut som nedan med:

🆕230303
lab4.1/
├── App.vue
├── main.js
└── src/ 
│.     ├── router/ 
│      │.     └── index.js 
│      ├── store/ 
│      │      └── index.js 
│      └── views/
│      │      ├── Room.vue 
│      │      ├── Rooms.vue 
│      │      ├── Admin.vue 
│      │      ├── Booking.vue 
│      │      ├── Login.vue 
│      │      └── ShowTimeslots.vue 
├── .eslintrc.json
├── .gitignore
├── .prettierrc.json
├── .stylelintrc.json
├── README.md
├── bootstrap.png
├── index.html
├── package-lock.json
├── package.json
├── vite.config.js
└── vue.js.png      

🆕(230303) Filnamn som är:

• skrivet med kursiv stil betyder att filinnehållet behöver modifieras.
• överstruken: betyder att det kan tas bort, men de måste inte tas bort.
• skrivet med fet stil: innebär att de filerna ska du skapa själv.
• skrivet utan formatering innebär att de med väldigt låg sannolikhet behöver modifieras. Ändra inget i de filerna tills du vet du behöver ändra i dem.             

Filen client/src/router/index.js innehåller kod som ordnar routing till olika sidor i src/views.

Filen client/src/store/index.js innehåller kod som stödjer olika tillstånd på på front-enden, sådana som att användaren är i inloggad eller inte, assistentens namn som behövs i Admin-sidan men den skapas i inloggnings-sidan, etc.

Modifiera Login.vue (här kan du ha mycket nytta av vue-projektet tictactoe från föreläsning 14, så titta på de filerna samtidigt):

1. Lägg till ett formulär med  inmatningsfält för användarnamn och lösenord samt en knapp för inloggning. Samt en Vue direktiv {{msg}} för felmeddelanden till användaren.

2. Glöm inte att ange Vue-direktiven v-model i input-fältenen, för att användarens inmatning  ska lagras i attributen data i Vue-objektet.

3. Lägg till koden @submit.prevent="ANROP TILL EN FUNKTION" i form-taggen. Funktionen deklarerar du sedan i Vue-objekt taggen.

4. Börja att skriva kod för Vue-objektet: Lägg till attributen data som ska ha två platser en för användarnamn och ett för lösenord samt msg för felmeddelanden se punkt 1.

5. Under attributen methods: deklarera en funktion (SAMMA FUNKTION SOM I PUNKT 3, checklogin eller liknande): funktionen kommer routa till admin-sidan om inloggningen lyckats men vid misslyckat inloggning uppdateras msg ett felmeddelande. Routing till admin-sidan ska ske genom att anropa push('ADMINSIDAN') från this.$router. ADMINSIDAN är alltså den rutt som leder till filen Admin.vue som du skapar senare. De hårdkodningar som vi har skrivit i tabellen i början av labblydelsen ska finnas här. Så ett påhittat inloggningsnman t.ex blahonga och ett påhittat lösenord till det som jämförs med användarens inmatning i denna funktion.

6. Finlen router/index.js ska du uppdatera efter de nya vue-komponenter.

7. Filen store/index.js ska du uppdatera när du behöver på ett enkelt sätt dela ett tillstånd mellan olika vue-komponenter utan att behöva skriva någon längre kod. Ett tillstånd kan vara att en assistent loggar in, och då tillståndet ändras till inloggad, och en del sidor kan kanske ändra beteende eller visa extra information beroende på tillstånden inloggad eller utloggad.

Arbetssätt:

De andra filerna Admin.vue, Booking.vue och ShowTimeslots.vue ska skrivas på samma sätt som de ovanstående punkterna, d.v.s generellt sett följande punkter behöver du göra för varje fil med extensionen vue:

1. Skriv lämplig html-tag, med direktiv till vue-objektet

2. Skriv vue-objketet, data, create och method är viktigast men kan finnas andra viktiga metoder.

3. Uppdatera filen router/index.js med information om de nya rutterna (Vue-filerna).

Följande krav ska uppfyllas för redovisningen

1. Ni skall använda de medföljande lint-skripten (package.json filen) utan modifikation. Vid redovisning ska dessa kunna köras UTAN NÅGRA VARNINGAR ELLER FEL.
2. Användarnamn samt lösenord måste vara minst 3 tecken långa samt innehålla minst en bokstav och en siffra.

3. Vid lyckad inloggning hamnar man på admin-sidan.

4. Vid misslyckad inloggning, stannar man kvar på inloggningssdian som uppdateras med ett meddelande om misslyckad inloggning.
5. Ska det finnas en utloggningsknapp/utloggningsmöjlighet som är aktiv/klickbar när en assistent är inloggad. Den kan vara på admin-sidan eller på menyn. 

⚠️ Om du undrar något om beteende av programmet så kan du få svar genom att testa demot eller få svar via mail men då kan det dröja något.

Lycka till!

Del 2 (Demo för del 2 Links to an external site. ) använd login ”Lorem” med lösenordet "Lorem" eller login ”Ipsum” med lösenordet "Ipsum". 🆕230328

Översikt

I den här delen av labben kommer du utveckla backend-delen. Du har fått nu en ny mapp för ett chattprogram. Studera gärna hela programmet både server och client delen innan du börjar ändra på något så att du får en uppfattning om hur olika delar hänger ihop.

När chattservern är igång väntar den på request från klienter:

0: Hos klienten: användaren skriver url:en http://127.0.0.1:8989/ Links to an external site. och trycker på enter.

1. Hos servern: En request på huvudsidan (/) tas emot och då kollar servern om det är en request fråpn en inloggad användare (m.h.a. sessionshantering).

   1.1. Om användaren inte är inloggad skickas en respons med inloggningssidan

   1.2. Annars skickas en respons med sidan som visar alla room till klienten

2. Hos klienten: Användaren skriver sitt namn och trycker på  enter. En post-requeset men inloggningsnamn med Ajax (funktionen fetch('/api/Login')) skickas till servern.

3. Hos servern: Servern tar emot post-requesten, skapar en användare (via anropet router.post("/login", ...) i filen auth.controller.js) sedan skickar en json-objekt som säger att authentication var lyckad.

4. Hos klienten: Klienten (i Login.vue i metoden authenticated) tar emot responsen och kollar om det är lyckad så gör ett anrop till vue-komponenten rooms (dett sker i anropet: push(authenticated === true ? "/rooms" : "/login") som finnd i Login.vue)

5. Hos klienten: Titta i filen Room.vue, komponetnen "rooms" laddas upp (alla room hämtas från servern via Ajax-anrop (se anropet fetch("api/rooms").then.... ). Och sidan med i fylld-data (alla room) visas.

6. Hos Klienten: användaren klickar på room med texten "java". Då anropas redirect metoden i Rooms.vue som laddar upp vue komponenten  room med namnet "java." (se koden this.$router.push(`/rooms/${name}` i filen Rooms.vue)

7. Hos Klienten: vue-komponenten Room.vue laddas, alla meddelanen hämtas  m.h.a Ajax (se koden fetch(`/api/rooms/${this.name}/messages`) vid montering (mounted) av vue-komponenten. I metoden mounted skapas även en webbsocket-lyssnare som lyssnar på event-namnet "msg". Se koden socket.on("msg", ...). Det är denna kod som låter att servern uppdaterar meddelandelistan med meddelanden som skickas från andra klienter UTAN ATT SIDAN BEHÖVER UPPDATERAS MED T.EX EN NY REQUEST.

8. Hos klienten: användaren skiver sitt textmeddelande och klickar på knappen SEND. Klienten skickar eN POST-REQUEST med meddelandet m.h.a ett Ajax-anrop (fetch(`/api/rooms/${this.name}/messages`, {...});  ) till servern.

9. Hos servern: Servern tar emot requesten och kör koden  router.post("/rooms/:name/messages", (req, res) => {...})  i filen chat.controller.js. I den del av programmet hämtar servern user-objektet som är kopplad till den klienten/webbläsaren, på samma sätt hämtar room-objektet. I room-objektet lägger den till meddelandet. Samt skickar meddelandet med webbsocket till alla klienter (se model.broadcast(room, `${user.name}: ${message}`) i filen chat.controller.js), denna meddelande tar emot av alla klienters socket.io kod (se punkt 7 ovan).

Resternade funktionalitet fungerar på samma sätt och du ska försöka utgå från samma princip för att implementera bokningsuppgiften i denna laboration.

Testa följande url (i samma webläsare) när du startat chattservern och loggat in och valt room och skrivit några meddelande, för att se när vad tas emot av webbläsaren när en ajax-anrop (med fetch) görs.

http://127.0.0.1:8989/api/rooms Links to an external site.

Links to an external site.http://127.0.0.1:8989/api/rooms/java/messages Links to an external site.

Du behöver radera bort innehåller av mappen client och kopiera alla filer i mappen lab4.1 från del1. Nu kommer vi att ha mest fokus på server delen även om att vi behöver modifiera och lägga till mer kod i klient-delen för att allt ska fungera som det ska.

Följande är struktur på mappen du har fått och på samma sät som del1 behöver du modifiera och läga till en del filer:

🆕230324 (Mappen kommer att läggas till på måndag men ni kan så länge använda er av filen lab4.2_canvas Download lab4.2_canvas som är identisk som ni kommer att få i git-repo)

     lab4.2/
    ├── client/
    │      └── kopiera_in_dina_filer_från_del_1
    └── server/
             ├── package-lock.json
             ├── package.json            
             └── src/
                      ├── controllers/
                      │      ├── admin.controller.js
                      │      ├── auth.controller.js
                      │      ├── chat.controller.js
                      │      └── timeslot.controller.js
                      ├── index.js
                      ├── model.js
                      ├── models/
                      │      ├── assistant.model.js
                      │      ├── room.model.js
                      │      ├── timeslot.model.js
                      │      └── user.model.js
                      └── util.js   🆕(230327) (filen utils.js var överstruken av misstag men filen ska inte tas bort då den används)

Filnamn som är:

• skrivet med kursiv stil betyder att filinnehållet behöver modifieras.
• överstruken: betyder att det kan tas bort, men de måste inte tas bort.
• skrivet med fet stil: innebär att de filerna ska du skapa själv.
• skrivet utan formatering innebär att de med väldigt låg sannolikhet behöver modifieras. Ändra inget i de filerna tills du vet du behöver ändra i dem.     

Mappen models kommer att ha följande filer assistanet.model.js och timeslot.model.js. Ett förslag på kod för filen assistant.model.js kan se ut som nedan:

class Assistant { 
   constructor(name, id){
     this.id = id;
     this.name= name;
   }
   //här kommer eventuella getters, setters elle andra "nödvändiga" metoder
}
export default Assistant;

Koden för filen timeslot.model.js ska på samma sätt ha attribut för id för assitenten som skapat/äger tiden (se koden ovan), id för själv timeslot-objektet, time som ska vara en sträng som beskriver timmen och minuten, attributen booked för att markera en tid är fri eller bokad och tillslut en attribut, booked_by, för namn för studenten som ev. har bokat tiden, om det skulle behövs kan du lägga till setter-, getters- eller eventuella andra metoder för att höja abstraktionen. 

Tabellen nedan visar vilka typ av uppgifter hör till vilka filkategori:

Observera att chatt programmet har ingen databas och alla data försvinner när man startar om chatten, men så ska det inte vara i bokningssystemet utan alla tider och assistenter ska finnas kvar vid omstart av servern. Därför så ska ni skriva om hur modeller lagras genom att integrera en databas på serversidan. Av administrativa skäl behöver denna databas vara en SQLite databas, precis som i labb 3. Kom ihåg att commit:a era SQLite filer till Github för att vi ska kunna testköra er lösning vid behov!

Modifieringar i mappen client (men inte allt på en gång)

I mappen client från del 1 har du skrivit en del kod som behöver ersättas av Ajax-anrop (med promise funktionen fetch), samt lägga till kod för websocket som möjliggör att servern uppdaterar data hos klienterna t.ex när en ny tid läggs till, bokas, är under reserverad tillstånd (10 sekunder). Förslagsvis modifiera en bit i taget samtidigt som du imeplemnterar kod för server-delen och modifiera inte all kod på en gång. Observera för att minska kommunikation mellan klienten och servern men hålla hög säkerhet hos servern behöver en del kod med samma semantic finnas både på klient-sidan och server-sidan. Ett exampel är att lösenordet får ej vara kortare än 3 tecken. Den kontrollern behöver finnas hos klienten för att minska kommunikation men samma kontroll ska även finns hos servern för att förhindra eventuella hackers för att otillåtna data ska inte in i databasen.

Bokningsflödet ska fungera som följande

1. En student går in på bokningssidan och får se alla assistenter och alla lediga tider.
2. Studenten klickar på en tid som hen vill boka varpå två saker sker:
   1. Studenten blir omdirigerad till bekräftelsesidan
   2. Med hjälp av websockets så blir övriga studenter som kollar på bokningssidan notifierade om att tiden är reserverad och just den tiden går inte att boka längre i deras UI.
3. Studenten på bekräftelsesidan har nu tre val:
   • Fylla i namn och trycka på OK varpå man skickar till servern att tiden är bokad och användaren blir omdirigerad till bokningssidan.
   • Vänta i 10 sekunder på en timeout varpå tiden blir fri igen och studenten omdirigerad till bokningssidan.
   • Trycka på cancel varpå servern skickar ut till alla anslutna att tiden är ledig igen med hjälp av websockets.

Specifika krav

Demoapp inkl. förtydligande instruktioner i lämpligt sammanhang: https://booking-spring-boot.herokuapp.com/ Links to an external site.

1. Ni skall implementera en SPA (single-page application) Links to an external site. m.h.a Vuejs(front-end) Links to an external site. (och  Links to an external site.Vite.js Links to an external site.) samt Node.js Links to an external site./Express.js (back-end) Links to an external site..
   • Routing. Dynamisk routing skall implementeras på klientsidan m.h.a. Vue Router Links to an external site..
   • Rendering. CSR (client-side rendering) skall implementeras, vilket innebär att samtliga front-end vyerna skall renderas på klientsidan. Alternativet är SSR (server-side rendering) Links to an external site. som även används ofta, men är inget krav i denna labb.
   • Säkerhet. All indata skall valideras på serversidan oavsett den använda dataöverföringstekniken som AJAX/WebSocket (socket.io Links to an external site.).
   • Kommunikation. Single page load innebär att applikationen laddar inte om sidan när den används. Efter den initiala laddningen skall all kommunikation med servern hanteras via AJAX/WebSocket (socket.io Links to an external site.) el.dyl. Ingen omladdning är tillåten.
2. När man navigerar till bokningssidan på klienten:
   • Alla bokade/reserverade/lediga tider skall hämtas från servern, m.h.a AJAX-requests.
   • Därefter så skall klienten uppdateras med nya/borttagna tider, m.h.a. websockets (socket.io Links to an external site.).
3. När man försöker boka en tid på klienten så sker det följande i ordning:
   1. En AJAX-request skickas från klienten till servern 
      • Notera att ni inte får använda "this.$socket.emit" på klienten
   2. Servern avgör om reservering/bokningen får genomföras, och svarar med en relevant status kod Links to an external site., t.ex. "200 OK", eller "403 FORBIDDEN"
   3. Servern skickar ut ett event (via socket.io Links to an external site.) till alla anslutna klienter, m.h.a. "io.emit"
4. Timeouten för en tid som är reserverad men ej bokad ska ske både på serversidan, samt på klientsidan för den klienten som har påbörjat bokningen.
   • På klienten: för att man enkelt ska kunna omdirigera studenten till bokningssidan om studenten av någon anledning inte hinner slutföra bokningen inom 10 sekunder.
   • På servern: för att se till att tiden blir ledig igen även om klienten inte hinner slutföra bokningen inom de 10 sekunderna.
5. Linting.
   1. ESLint skall användas.
   2. Dem ESLint regler som inkluderas i labb skelettet skall vid redovisning köras UTAN NÅGRA VARNINGAR ELLER FEL.
6. Databas.
   1. Databasen SQLite skall användas.
   2. Alla queries skall vara säkra mot SQL injections.
   3. Alla registrerade admins skall sparas i databasen.
   4. Inloggning skall enbart tillåtas om det angivna användarnamnet och lösenordet finns registrerat i databasen.
7. Inloggning.
   1. Vid lyckad inloggning:
      1. Inloggningssession skall skapas på serversidan och associerad kaka skall skickas till klienten.
      2. Användaren skall bli omderigerad till adminsidan.
   2. Vid misslyckad inloggning:
      1. Användaren skall visas ett felmeddelande.
8. Utloggning.
   1. Det skall finnas en utloggningsknapp på adminsidan. 
   2. Utloggning skall enbart tillåtas för inloggad användare.
   3. Vid lyckad utloggning:
      1. Inloggningssessionen skall tas bort på serversidan, samt assosierad kaka skall invalideras på klientsidan.
      2. Användaren skall bli omdirigerad från adminsidan.
9. Säkerhet.
   1. Det skall finnas ett middelware Links to an external site. på serversidan som hindrar ej inloggade användare från att anropa admin endpoints. t.ex. skapa nya timeslots, eller ta bort existerande timeslots

Tips

• Börja i tid, labb 4 är utan tvekan den tyngsta av alla labbar i kursen och den kan ta väldigt mycket tid!
• Börja med att experimentera med det givna exemplet innan ni börjar med själva uppgiften. 50% av arbetet är att förstå hur saker hänger ihop.
• Utgå eventuellt från exemplet och gör små inkrementella ändringar för att göra om exemplet till något som löser uppgiften. Det kan vara ganska svårt att debugga i början om man gjort stora ändringar.
• Kom ihåg att använda er av de tillgängliga devtools i någon modern browser, inspektorn kommer att hjälpa er mycket i denna labb. Det finns även Vue specifika devtools Links to an external site. för flera browsers som kan vara användbara.
• Vue använder en unik filtyp ".vue" som påminner om HTML. Många editors/IDE har stöd för ".vue" genom extensions. Vi tipsar om VSCode Links to an external site., samt en vue extension vid namn Vetur Links to an external site.. Det finns även en start guide för Vue i VSCode Links to an external site.. 
• Och kom ihåg att ni alltid kan be en assistent om hjälp om ni har fastnat med någonting.

Bonusuppgift

Implementera automatisk utloggning efter en viss tid (förslagsvis efter 30 sekunder) användaren inte har gjort någon aktiv handling så som klickan på en länk eller knapp i sidan samt skrivit in något i textfältet (du kan använd oninput Links to an external site.). Ett typiskt scenario är när användaren inte rör musen eller tangentbordet i 30 sekunder och då omdirigeras till inloggningssidan samt användaren loggats ut hos servern, d.v.s. om användaren försöker besöka en annan sida utan att logga in så kommer omdirigeras till inloggningssidan, precis som när användaren besöker sidan för absolut första gången. Du ska göra detta genom att implementera 2 av följande 3 Pollingsteknik:

Socket.io

Använd Socket.io för att skapa en fullduplex kommunikation mellan servern och klienten för att åstadkomma automatiska utloggningen. I denna teknik servern håller koll på klientens passivitets-tid genom att starta en timer. Klienten uppdaterar servern så fort användaren visar någon typ av aktivitet t.ex med klickning på en länk eller tangentryckning på tangentbordet vilket medför att servern nollställer och startar om sin timer.

AJAX Polling

I stort sett handlar denna teknik om att regelbundet med givet tidsintervall skicka AJAX-förfrågor till servern för att få någon slags information. Detta kan genomföras på flera olika sätt, det rekommenderade är att använda sig av funktionen fetch i kombination med setTimeout/setInterval.

Nackdelen med denna tekniken är att den resulterar i en kraftigt ökad mängd trafik. Tänk exempelvis på situationen där informationen vid vissa tillfällen uppdateras på serversidan varje minut och vid andra tillfällen varje timme. Väljer man då ett för litet tidsintervall, kommer mängden trafik öka markant - i onödan. Väljer man ett för stort tidintervall, missar man att få informationen i fråga i tid. Problemet adresseras av tekniken nedan, d.v.s. long-polling.

AJAX Long-Polling

Grundskillnaden mot polling är hur AJAX-förfrågor hanteras av servern. Om informationen är tillgänglig, borde den fortfarande omedelbart returneras till klienten varefter en ny AJAX-förfråga borde skickas iväg. I annat fall borde servern däremot vänta tills informationen är tillgänglig utan att stänga ner förbindelsen.

Karakterisera kort båda teknikerna med avseende på vilken part som inleder kommunikationen (klient-/serverinitierad), vilket protokoll som används samt hur kommunikationen sker (halv-/full-duplex inom/utom domän). Motivera.

* Informationen nedan riktas främst till dem som inte använder Firefox. Sändning av parallella AJAX förfrågor till servern, vilket kan förekomma i long-polling bl.a. när man öppnat flera flikar i en och samma webbläsare och efterfrågat samma resurs, hanteras av webbläsarna på ett varierat sätt. Klientförfrågorna som är identiska med varandra kan av vissa av dem (t.ex. Chrome, Safari) avvisas. Resultatet är att bara en förfråga skickas ut oavsett antalet öppnade flikar. Andra (t.ex. Firefox) tillåẗer det, vilket i sin tur resulterar i en utskickad förfråga per flik. I syfte att få den aktuella tiden uppdaterad korrekt i varje flik, behöver man därmed lura vissa webbläsare att alla parallella förfrågor med ursprung i olika flikar är olika. Ett sätt att göra detta är att generera en unik, slumpmässig identifierare samt inkludera den som en parameter i URL adressen (t.ex. `/time?id=${unik_id}`) innan själva AJAX anropet utförs. Observera att denna parameter borde ignoreras av servern och dess enda syfte är att skilja klientförfrågor ur webbläsarens perspektiv. Avslutningsvis, notera att problemet ovan inte finns om man använder olika webbläsare, alternativt inkognitoläget.

Tips

Alla webbläsare har utvecklarverktyg. Dessa tillåter att inspektera vad som händer bakom kulisserna. Man kan inspektera den nuvarande DOM (Länkar till en externa sida.):en, det finns en console man kan läsa utskrifter till console.log, man kan se vilka CSS regler som påverkar vilka element, och mycket mer. Ni kan läsa här (Länkar till en externa sida.), hur ni öppnar utvecklarverktygen.

⚠️ Om du undrar något om beteende av programmet så kan du få svar genom att testa demot eller få svar via mail men då kan det dröja något.

Lycka till!