Att stjäla kod på ett intelligent sätt

Att stjäla kod på ett intelligent sätt En handledning för Webbprogrammering gk Anders Märak Leffler 17 april 2011 Sammanfattning Detta är en kombinerad ledning till laboration 2 i Webbprogrammerings gk, och en introduktion till hur man kan använda andras resultat i sin kod. Den kommer inte att vara särskilt formell, utan använder det faktum att kommandon i JavaScript och egenskaper i DOM är enkelt och intuitivt namngivna. Detta gör att man - även om man inte kan skriva koden direkt - kan få en känsla för strukturen i ett program, och återanvända kod. En första del går igenom en allmän lösningsgång. En andra går igenom kodexemplet från föreläsningen. Denna kan du hoppa över om du känner dig bekväm med JavaScript, eller hur man läser igenom koden. I den tredje delen ges ett par råd om hur man kan bryta isär problemet, och i den avslutande delen ges sammanfattande råd inför vidare programmering. Detta är en introduktion för den som inte har programmerat tidigare, eller gjort det i den stil som brukar läras ut på gymnasiet. Om du vet vad högre ordningens funktion står för, är detta inte guiden för dig. 1 Vad vill du göra? Det första att identifiera är vad din kod ska göra. Det kan tyckas enkelt, men handlar ofta om att gå från en generell beskrivning till något hanterbart delproblem. Instruktionen från labbuppgiften är att Felaktigt ifyllda fält ska uppärksammans på ett användarvänligt sätt. Om alla fält är korrekt ifyllda ska man kunna skicka vidare formuläret till en sida som bekräftar anmälan. Ingen vidare behandling av inmatad data kommer att ske i denna laboration - det kommer vi arbeta med senare under kursen. 1 Amanuens, Institutionen för Datavetenskap, Linköpings universitet. anders.marak.leffler@liu.se 1 http://www.ida.liu.se/ 725G54/laborationer/2.sv.shtml 1

Det kan vi lösa på olika sätt. Användarvänligt skulle vissa kunna tolka som att användaren får en popupruta för varje fel den gjort. Andra skulle (helt rimligt) säga att det betyder att man har någon form av text eller bock som dyker upp direkt när man gjort rätt. Här väljer vi den senare tolkningen (som ligger i linje med det som presenterats på föreläsningen). Så hur gör man det? 1.1 Vad har problemet för delar? Nästa steg är att identifiera de olika delarna av problemet. Instruktionen från labbuppgiften kan vi till exempel bryta ned i att vi vill Kunna mata in information i flera olika fält. Kunna kontrollera om informationen stämmer (på flera olika sätt - namn ska ha viss form, årtal en annan). Kunna presentera information om att inmatad information är korrekt eller inkorrekt. Kunna hindra användaren att skicka iväg felaktigt ifyllda formulär. Om detta verkar vara en rimlig förstaindelning, gäller det att försöka skriva eller hitta kod som passar, för varje del. 2 Vad har du för kod? När vi delat in problemet, kan vi börja koda. Som vanligt på det här området finns det gott om kod som folk skrivit, och som man kan och får använda. Är man bara intresserad av att enkelt och snabbt lösa ett givet problem (och labbreglerna tillåter det - nota bene) kan det vara en bra strategi att kolla på hur andra har löst problemet. Inmatning i fält i XHTML kan man lätt göra genom att lägga in kommandon i stil med 1 <form name= inmatning a c t i o n= t a c k s i d a. html method= post > Förnamn : <input type= t e x t name= f i r s t n a m e i d= name /> 3 <div i d= namefeedback >Se t i l l a t t s k r i v a r ä t t nu!</ div> <input type= submit i d= submit value= Skicka /> 5 </form> Om detta kan man läsa exempelvis i Niederst-Robbins bok, eller på diverse ställen på nätet. Detta kan man lätt utöka till att innehålla alla fält som behövs enligt labbinstruktionen. Att hantera inmatningen blir en senare fråga. Som tur är har vi ett bra exempel från föreläsningarna. 2

2.1 Föreläsningsexempel I många fall skulle ett bra första steg - efter att man försökt lösa problemet själv - vara att leta på nätet efter problem med liknande struktur. Som tur är har denna kurs exempelkod som hör till föreläsningarna, som är en bra utgångspunkt. 1 // a l e r t ( Det funkade! ) ; Listing 1: formvalidation.js 3 submitbutton = document. getelementbyid ( submit ) ; namefield = document. getelementbyid ( name ) ; 5 namefeedback = document. getelementbyid ( namefeedback ) ; submitbutton. d i s a b l e d = t r u e ; 7 namefield. addeventlistener ( keyup, f u n c t i o n ( e ){ 9 // v = namefield. value ; // a l e r t ( v ) ; 11 l = namefield. value. l e n g t h ; // a l e r t ( l ) ; 13 i f ( l >= 5) { namefeedback. innerhtml = OK ; 15 namefeedback. s t y l e. c o l o r = #0F0 ; submitbutton. d i s a b l e d = f a l s e ; 17 } 19 i f ( l < 5) { namefeedback. innerhtml = FÃ r k o r t. ; 21 namefeedback. s t y l e. c o l o r = #000 ; submitbutton. d i s a b l e d = t r u e ; 23 } 25 }, f a l s e ) ; 2.1.1 Vad gör koden? När vi har letat fram kod, är det lämpligt att undersöka vad den faktiskt gör. En kort genomgång av koden ger att vi har Rad 3-5 Skapar variablerna submitbutton, namefield och namefeedback och binder dem till något. Detta något ser ut på formen document.getelementid(...), vilket antyder att man hämtar element med id som submit och name från sidan 2. För att just denna kodsnutt ska fungera, gäller det alltså att man i XHTMLkoden markerat sina fält med rätt id:n. Rad 6 När vi har identiferat skicka -knappen med submitbutton, försöker vi kalla på en egenskap vid namn disabled. Denna egenskap sätter vi till true. Det betyder precis vad man kan tro. Man har en Skicka -knapp, men från början är den avslagen, så att man inte kan skicka formuläret. 2 Läs Niederst-Robbins om DOM 3

Rad 8 Namnet addeventlistener antyder att vi börjar lyssna efter händelser. Googla på egenskapen, och se att man kan använda syntax i stil med 3 1 t a r g e t. addeventlistener ( type, l i s t e n e r, usecapture ) ; Målet för eventlistenern är alltså namefield, vilket svarar mot fältet namn ovan. Ser vi på exemplet ovan, märker vi att typen av händelse (event) vi lyssnar efter är keyup (vilket både låter som- och är att släppa en tangent efter att ha tryckt ned den). Det som står inom måsvingarna { och } 4 är det som händer när någon släpper en tangent efter att ha fyllt i en bokstav i fältet. (Om vi ersatte allt inom måsvingarna med kommandot alert( Test! ), skulle det alltså dyka upp en popupruta med texten Test! efter varje bokstav man skrivit in i fältet.) Rad 9-10 Först kommer ett par bortkommenterade rader. Det kan vara värt att kolla på vad som står i denna kod. Den första av raderna ser på namefield och tar fram en egenskap. Att det är en egenskap snarare än en funktion, märker man på att det inte står några parenteser efter value. Den egenskap för fältet som vi tar fram är dess value, vilket är precis vad man kan tänka sig - värdet på ett inmatningsfält i ett formulär är precis vad som matats in i det. Variabeln v tilldelas detta värde. Den andra bortkommenterade raden skulle ge en popupruta med innehållet i fältet. Rad 11 Variabeln l tilldelas längden på denna sträng (namefield.value.length). Detta använder vi sedermera. Rad 12-17 Den första if-satsen säger att om (l>=5), så gör något, där detta något står inom måsvingarna. Vad är detta något som står inom måsvingarna? 1 namefeedback. innerhtml = OK ; namefeedback. s t y l e. c o l o r = #0F0 ; 3 submitbutton. d i s a b l e d = f a l s e ; Första raden sätter (tilldelar) namefeedbacks innerhtml-egenskap något värde. Kom ihåg att namefeedback var ett vanligt stycke text på sidan. innerhtml kan man läsa om i Niederst-Robbins, eller så kan man slå på nätet efter det. Vad detta innebär är helt enkelt att man ändrar textblocket som har id namefeedback till OK. Vi kunde ha inkluderat en massa XHTML-kod inuti citattecknen om vi ville; då hade den infogats på hemsidan. 3 https://developer.mozilla.org/en/dom/element.addeventlistener 4 Ja, de kallas ofta så. Den engelska termen - på samma nivå av formalitet - är curly braces. 4

Andra raden ändrar färg på texten. Den tredje raden slår upp submitbutton - vår Skicka -knapp - och ser till att man kan klicka på den. Om den inte varit avslagen förut ändras inget, men om någon gjort så att man inte kan skicka formuläret, ändras det så att det inte är några problem. Den andra if-satsen gör något motsvarande, och beskrivs därför inte här. 5

3 Vill du göra något många gånger? Vi har nu kod som gör vad vi vill för ett fält. Men vi har en mängd olika fält. Det verkar opraktiskt (och är dålig kodstil) att kopiera koden för varje fält. Istället kan vi göra ett paket av det, en funktion, och kalla på denna funktion för varje fält. 3.1 Att paketera saker i funktioner Istället för att skriva hela koden ovan, skulle vi då kunna gömma undan stora delar i denna funktion - säg addvalidation, och bara skriva namefield=document.getelementbyid( name ); namefeedback=document.getelementbyid( namefeedback ); addvalidation(namefield, namefeedback); Det addvalidation ska göra är då att ta in ett visst fält, och ett visst feedbackfält (vi kan ju inte fortsätta arbeta med just namefield och namefeedback - funktionen ska ju kunna användas för alla möjliga fält). Funktioner börjar med function namn ( argument1, argument2,...) { och slutar med }. Således kan vi bygga om funktionen till 1 f u n c t i o n a d d v a l i d a t i o n ( Field, Feedback ) { 3 F i e l d. addeventlistener ( keyup, f u n c t i o n ( e ){ l = F i e l d. value. l e n g t h ; 5 i f ( l >= 5) { Feedback. innerhtml = OK ; 7 Feedback. s t y l e. c o l o r = #0F0 ; submitbutton. d i s a b l e d = f a l s e ; 9 } 11 i f ( l < 5) { Feedback. innerhtml = För k o r t. ; 13 Feedback. s t y l e. c o l o r = #000 ; submitbutton. d i s a b l e d = t r u e ; 15 } }, f a l s e ) ; 17 } Vi kan lika gärna, kortare, kunnat skriva 1 f u n c t i o n a d d l i s t e n e r ( Field, Feedback ) { 3 F i e l d. addeventlistener ( keyup, f u n c t i o n ( e ){ l = F i e l d. value. l e n g t h ; 5 i f ( l >= 5) { Feedback. innerhtml = OK ; 7 Feedback. s t y l e. c o l o r = #0F0 ; submitbutton. d i s a b l e d = f a l s e ; 6

9 } e l s e { Feedback. innerhtml = För k o r t. ; 11 Feedback. s t y l e. c o l o r = #000 ; submitbutton. d i s a b l e d = t r u e ; 13 } }, f a l s e ) ; 15 } Notera ändringen på rad 9. Varje gång vi kallar på addvalidation med ett fält och ett feedbackfält, kommer det läggas till en listener till det fält man matar in (inte bara namefield). 3.2 Att göra många liknande saker Så långt fungerar det väl. Men vi måste göra liknande jämförelser för vissa fält, medan andra ska göras på annat vis (t ex kontroll om en emailadress är korrekt). Detta kan man såklart lösa genom att kopiera addvalidation ovan, och göra små ändringar. Kollar vi på addvalidation, ser vi att det är en enda detalj som behöver ändras - att man kollar på längden av textsträngen. Men det vore - återigen - en ful lösning. Vad vi kan se kunde man lika gärna se det som att koden löd 1 f u n c t i o n a d d l i s t e n e r ( Field, Feedback ) { 3 F i e l d. addeventlistener ( keyup, f u n c t i o n ( e ){ i f ( F i e l d. value. l e n g t h >= 5) { 5... } e l s e { 7... } 9 }, f a l s e ) ; } eller, om vi bara hade en funktion som kollade om en sträng hade rätt längd f u n c t i o n a d d l i s t e n e r ( Field, Feedback ) 2 { F i e l d. addeventlistener ( keyup, f u n c t i o n ( e ){ 4 i f ( c o r r e c t L e n g t h ( F i e l d. value ) ) {... 6 } e l s e {... 8 } }, f a l s e ) ; 10 } På samma sätt som vi lyfte ut funktionaliteten lägg till en lyssnare, kan vi lyfta ut villkoret. En funktion correctlength måste säga att strängen är av rätt längd om den är det (ge tillbaka true ), och ange att den inte är det annars (false). Då kommer if-satsen gå in i rätt spår. 7

3.3 Att skriva ett villkor/predikat I kodexemplet från föreläsningen så ser vi hur ett villkor kan bygggas upp. När vi lyft ut det till en egen funktion, behöver den bara ge tillbaka true om villkoret uppfylls, och false annars. Vad som ska hända när villkoret uppfylls bestäms någon annanstans. Alltså: f u n c t i o n c o r r e c t L e n g t h ( o u r s t r i n g ) 2 { i f ( o u r s t r i n g. l e n g t h >= 5) { 4 r e t u r n t r u e ; } e l s e { 6 r e t u r n f a l s e ; } 8 } Eftersom det man gör ovan är att ge tillbaka true om villkoret (our string.length >= 5) uppfylls (är true), och false om villkoret är false, kan vi lika gärna skriva f u n c t i o n c o r r e c t L e n g t h ( o u r s t r i n g ) 2 { r e t u r n ( o u r s t r i n g. l e n g t h >= 5 ) ; 4 } 3.3.1 Att testa era predikat/villkor När ni har skrivit ett predikat, kan det vara bra att testa det. Om ni utanför funktionsdefinitioner skriver något i stil med alert( Ruta! ); så kommer en liten popupruta att dyka upp. Ni kan använda det för att skapa enkla tester. Pröva att skriva alert( correctlength("abc") ); Denna ruta bör innehålla ordet false. correctlength anropas med ordet abc, som har längden 3. correctlength ger då tillbaka false eftersom det är en för kort sträng. alert anropas, och får budskapet att skriva false i rutan. På detta sätt kan ni enkelt se vad era funktioner ger tillbaka för svar. Har ni en funktion som heter validemail, ska ni kunna skriva alert( validemail("anders.marak.leffler@liu.se") ); och få upp true (det borde ni, för adressen är korrekt). Om ni inte får upp de väntade resultaten, kanske ni bör ändra i funktionerna. 8

3.4 Att använda predikat/villkor Nu har vi lyft ut villkoret texten i ett fält har rätt längd. Det gör koden snyggare, men inte mer flexibel. Vi vill kunna lägga till olika slags villkor för olika slags fält. Alltså ha anrop i stil med namefield=document.getelementbyid( name ); namefeedback=document.getelementbyid( namefeedback ); addvalidation(namefield, namefeedback, correctlength); Där det sista anger att den funktion för kontroll av fältet som vi vill använda, är den som kontrollerar om innehållet har rätt längd. Kanske vill vi till och med ha ett eget felmeddelande som dyker upp när något går fel (om en mailadress är felaktig, ska det inte stå För kort - skriv minst 5 tecken ). Alltså: namefield=document.getelementbyid( name ); namefeedback=document.getelementbyid( namefeedback ); addvalidation(namefield, namefeedback, correctlength, "För kort!"); För att få detta att fungera måste vi ändra i addvalidation, så att man anropar den på sättet ovan. Något i stil med f u n c t i o n a d d v a l i d a t i o n ( Field, Feedback, V i l l k o r, Felmeddelande ) 2 { F i e l d. addeventlistener ( keyup, f u n c t i o n ( e ){ 4 i f ( V i l l k o r ( F i e l d. value ) ) {... 6 } e l s e {... 8 } }, f a l s e ) ; 10 } Notera att vi på rad 4 nu har Villkor istället för correctlength. När vi anropar funktionen med correctlength som Villkor -argument (som tredje argument i anropet), kommer det vara detta villkor som används. Hur man lägger in i koden att man ska visa rätt felmeddelande lämnas åt läsaren. 3.5 Att fortsätta härifrån Vi kommer att behöva kontrollera många fält. Vi kommer också att behöva kontrollera flera olika slags fält; skriva olika villkorsfunktioner att koppla till det. En validemail, en validbirthyear och så vidare. Här kan ni ha hjälp av sidor på internet där man gjort just detta. De flesta kommer inte att vara byggda så att de passar ihop exakt med den kod ni har hittills (t ex finns det många som bara utför kontrollen och ger en popupruta om inmatad information 9

är felaktig). Hittar ni kod som t ex kontrollerar om en mailadress är korrekt (det finns i skrivande stund länkat från kurshemsidan), kan ni fundera på vilken del av koden som innehåller själva kontrollen och lyfta ut den. Har ni väl koden som gör den kontrollen, gör en funktion som ger tillbaka true om villkoret uppfylls och false om det inte uppfylls. Svårare än så behöver det inte vara. 3.6 Saker som inte berörs här Labben innehåller också fler inslag, som det inte ges någon ledning till här. Man ska till exempel inte kunna skicka formuläret utan att alla villkor är uppfyllda. Det är ytterligare en problematik. Det kan kräva att man gör ändringar i addvalidation-koden ovan. Här ovan har vi också låtsats som om det finns en enda submitbutton. Funktionen får inte in någon speciell submitbutton som ska slås av, utan räknar med att det något som heter submitbutton definierat någonannanstans, som man kan nå. Indirekt bygger vi alltså kod som nog inte fungerar om man har flera formulär på sidan. Det är inget problem i denna labb, men det kan vara värt att fundera på hur man skulle lösa det (det är mycket små ändringar i koden som krävs!). 10

4 Sammanfattning och allmänna tips Om ni stöter på många exakt likadana problem, kan det vara värt att lyfta ut lösningen i en funktion och anropa den en gång per problem. Om ni stöter på många nästan likadana problem, fundera på om den del som skiljer sig kan lyftas ut. Isåfall kan man nog skriva en högre ordningens funktion som löser problemet. 5 I allmänhet: bryt alltid ned stora problem i många småproblem. Skriv inte ett stort kodsjok som försöker lösa allt. Det går inte i längden, och blir oläsbart och svårändrat. Dessutom kan det vara så att någon har löst något av era delproblem - isåfall gör denna modell att det blir lätt att återanvända deras resultat 6. Bygg era lösningar på småproblemen så att de kan testas lätt (som alerttesterna ovan.) Om ni gör en funktion med ett argument (säg Field ), kommer den bindningen gälla hela tiden inuti funktionen. Om ni försöker använda något som inte står med bland argumenten (t ex står inte submitbutton med bland argumenten för addvalidation-funktionen ovan), så måste det finnas definierat någon annanstans. Detta kan vara i funktionen som anropade den 7, eller att man har en s k global variabel - som kan nås överalltifrån 8. Att man inte alltid kan nå allt kan tyckas opraktiskt, men garanterar att man inte ställs inför potentiellt väldigt komplicerade frågor som vi använder Field på flera ställen i koden - vilken av dem ska vi använda egentligen? 5 En funktioner som tar in andra funktioner som argument. Här ovan skrev vi addvalidation, som tog in correctlength som argument. Om ni läser någon vettigare grundläggande kurs i programmering - snarare än en introduktionskurs som täcker många språk och områden - bör ni stöta på det begreppet. 6 Eller, för den delen, att arbeta i projekt 7 Så om Field betyder emailfältet i en funktion som anropar validemail-funktionen, kommer Field betyda emailfältet även när validemail-funktionen försöker slå upp det. Detta kallas dynamisk bindning, och är något man brukar lära sig om i fortsättningskurser i programmering, eller om man läser kurser i programmeringsteori. 8 Som submitbutton 11