Språkhantering för webbplatser med internationellt innehåll

Examensarbete 20 poäng D-nivå vid Örebro universitet Språkhantering för webbplatser med internationellt innehåll Reg.kod: Oru-Te-EXA089-D102/06 Peter Bergqvist Dataingenjörsprogrammet 160 p Örebro höstterminen 2007 Examinator: Lars Karlsson LANGUAGE MANAGEMENT ON A WEBSITE WITH MULTINATIONAL CONTENT Örebro universitet Örebro University Institutionen för teknik Department of Technology 701 82 Örebro SE-701 82 Örebro, Sweden

SAMMANFATTNING E-man AB har i dagsläget en webbplats som kan presentera innehållet på flera språk. Dock har det nuvarande systemet inget enkelt sätt att uppdatera webbplatsens innehåll. Önskan från E-man var att skapa ett administrationsgränssnitt så att administratörer och översättare kan uppdatera innehållet, samt att integrera den publika webbplatsen mot administrationsverktyget. Jag byggde ett system från grunden som baserats på Microsofts.Net-teknologi och databasen SQL Server 2005. Översättningsfunktionen bygger på att sidorna på den publika webbplatsen innehåller koder för de texter som skall bytas ut mot översatt innehåll. Applikationen försöker hämta den översatta texten från en cache på webbservern för att applikationen då kan undvika att kontakta databasen. I de fall där texten inte finns i cachen så kontaktar systemet databasen för att hämta det översatta innehållet. Processen med cache förbättrar systemets prestanda och tillåter därmed flera besökare. Var 30:e minut identifierar systemet de texter som har blivit ändrade via administrationsgränssnittet och plockar bort dessa från cachen. Det uppdaterade innehållet hämtas sedan vid första visningen och lagras också i cachen. För att undvika åtkomst för obehöriga har ett inloggningsförfarande införts till administrationsgränssnittet. ABSTRACT The contents of this report will describe the application I implemented for e-man ltd during the fall semester of 2006. The report is a part of the masters program in computer science at the University of Örebro. The current version of e-man s homepage supports contents in multiple languages, though there s no easy way for the administrators or translators to keep the content up to date. e-mans desire was to create an administration interface that would enable easy updates, and also to integrate the administration interface with the public webpage where the content should be presented. I built the system using Microsoft s.net-technology and the application relies on a SQL Server 2005 database for the content. The translation service is based on that the pages on the public homepage contain special codes that are used to identify which texts that should be replaced by translated content. The application will first attempt to find a translated value in the web-server cache, in order to avoid the much slower database. The text is retrieved from the database only in the event where the cache does not hold the text. The cache improves the over-all performance of the site and enables the site to allow more visitors. A log-in procedure was implemented to avoid unauthorized access to the administration area. Nyckelord: ASP.Net, Språköversättning, Enterprise Library, Cache-hantering, Enhetstester, Databaser, Lagrade procedurer, Reguljära uttryck, Generics ii

FÖRORD Arbetet pågick under hösten 2006 och rapporten är skriven som en delkurs på Magisterprogrammet för datateknik vid Örebro universitet. Arbetet utfördes på företaget E-man AB i Örebro. Jag vill passa på att tacka alla anställda på E-man AB för det vänliga bemötandet och de tips jag fått vid utvecklingen. Örebro universitet genom Lars Karlsson skall ha ett tack för att de tillät mig skriva examensarbetet helt fristående och jag vill rikta ett speciellt tack till min handledare Christer Lindkvist som tog över handledarrollen och tog sig tid att hjälpa mig med rapporten trots andra åtaganden. Örebro den 2007-12-12 Peter Bergqvist iii

INNEHÅLLSFÖRTECKNING FÖRORD... III LISTA AV ILLUSTRATIONER... 7 FIGURFÖRTECKNING... 7 TABELLFÖRTECKNING... 8 1 INLEDNING... 9 1.1 FÖRETAGET E-MAN AB... 9 1.2 OM DOKUMENTET... 9 1.3 BAKGRUND... 9 1.3.1 Innehållshantering... 9 1.3.2 Existerande system...10 1.3.3 Administrering...10 1.4 PROBLEMBESKRIVNING...10 1.5 GRUNDKRAV...11 1.5.1 Mål för språkmotorn och demonstrationswebbplatsen...11 1.5.2 Mål för administrationsgränssnittet...11 1.6 ARBETSGÅNG...11 1.6.1 Kravinsamling och systemdesign...11 1.6.2 Implementering av systemet...12 1.6.3 Test och dokumentation...12 2 METODER OCH VERKTYG...13 2.1 VERKTYG...13 2.2 PROJEKTSTRUKTUR...13 2.2.1 Presentationslager...13 2.2.2 Kontrollager...13 2.2.3 Modellagret...13 2.3 CSS-BASERAD DESIGN...14 3 GENOMFÖRANDE...15 3.1 KRAVINSAMLING...15 3.1.1 Användarfall...15 3.1.2 Skrivna användarfall...15 3.2 PROJEKTDESIGN...17 3.2.1 Uppdatering och underhåll...17 3.2.2 Projektet CacheHelper...18 3.2.3 Projektet DatabaseHelper...18 3.2.4 Projektet TranslationManagementAdminArea...18 3.2.5 Projektet TranslationManagementWeb...18 3.2.6 Projektet TranslationManagement.Admin...18 3.2.7 Projektet TranslationManagement.Authentication...18 3.2.8 Projektet TranslationManagement.Globalization...18 3.2.9 Projektet TranslationManagement.LanguageHandling...18 3.2.10 Projektet TranslationManagement.WebUtilities...19 3.2.11 UnitTest -katalogen...19 3.3 HUR ÖVERSÄTTNINGSKRAVEN ÄR UPPFYLLDA...19 3.3.1 Hämta text från databas...19 3.3.2 Identifiera koder...20 3.3.3 Ersätta koden...20 3.3.4 Flödesschema...21 3.4 HUR SPRÅKHANTERINGENS GRUNDKRAV ÄR UPPFYLLDA...22 3.4.1 Språk...22 3.4.2 Hämta användarens önskade språk...22 iv

3.4.3 Visa aktiva språk...23 3.5 HUR ADMINISTRATIONSVERKTYGETS GRUNDKRAV ÄR UPPFYLLDA...24 3.5.1 Inloggning...24 3.5.2 Användarmenyn...25 3.5.3 Uppdatera texter...26 3.5.4 Demonstration av administrationsverktyget...27 3.5.5 Språkadministrering...29 3.6 DATABASEN...29 3.6.1 TranslationManagement...29 3.6.2 Lagrade procedurer...30 3.7 LEVERANSFÖRFARANDE...30 3.7.1 Kodbasen...30 3.7.2 Databasen...31 3.8 UTBYGGNAD...31 3.8.1 Ärva TranslationManagement.Globilization.Translate...31 3.8.2 Underlätta underhåll...31 4 LÖSNINGSMETODER...33 4.1 KOMMENTARER KRING KODEN...33 4.1.1 Gemensam basklass...33 4.1.2 Generics...33 4.1.3 Gränssnitt...34 4.2 MICROSOFT ENTERPRISE LIBRARY...34 4.2.1 Caching Application Block...34 4.2.2 Database Application Block...35 4.3 MICROSOFT AJAX.NET...35 4.3.1 AJAX...35 4.3.2 Partiell rendering...35 4.4 ENHETSTESTER OCH TDD...36 4.4.1 NUnit...36 4.4.2 Mock object...37 4.4.3 Test Driven Development...37 4.4.4 NCover...38 4.5 KODANALYS...38 4.5.1 FxCop...38 4.5.2 Ants Profiler...38 5 SLUTSATSER...40 5.1 RESULTAT...40 5.1.1 Grundkrav språkhantering...40 5.1.2 Grundkrav administrationsgränssnitt...40 5.2 JÄMFÖRELSE MED TREDJEPART...41 5.2.1 Inbyggd resurshantering i Microsoft.Net...41 5.2.2 EPiServer CMS...41 5.2.3 Sammanfattning...42 5.3 DISKUSSION...42 5.4 FÖRSLAG TILL FÖRBÄTTRINGAR...42 6 REFERENSER...43 6.1 BÖCKER...43 6.2 INTERNET...43 6.3 ÖVRIGT...43 7 TERMINOLOGI...44 8 APPENDIX...46 v

8.1 APPENDIX A: DATABASEN...46 8.1.1 Schema: Översättning...46 8.1.2 Schema: Administrationsverktyg...46 8.1.3 Lagrade procedurer...46 8.1.4 Databasens tabeller...48 8.2 APPENDIX B: KLASSDIAGRAM...51 8.2.1 Administrationsgränssnitt...51 8.2.2 Språkmotorn...52 8.3 APPENDIX C: ANVÄNDARFALL - ADMINISTRATIONSGRÄNSSNITT...53 8.3.1 Inloggning...53 8.3.2 Förstasida...54 8.3.3 Hämta text...54 8.3.4 Uppdatera text...54 8.3.5 Spara ny text...55 8.3.6 Editera ett existerande språk...55 8.3.7 Lägga till språk...55 8.3.8 Lägga till textkategori...56 8.3.9 Ta bort textkategori...56 8.4 APPENDIX D: ANVÄNDARFALL - SPRÅKMOTORN...56 8.4.1 Översättning av en fras...56 8.4.2 Hämta text via kod...56 8.5 APPENDIX E: ANVÄNDARFALL - ÖVRIGA...57 8.5.1 Hämta aktiva språk...57 8.5.2 Hämta lokal-information från besökaren...57 8.6 APPENDIX F: FÅNGADE FEL AV FXCOP...57 8.7 APPENDIX G: LADDNINGSTIDER...58 vi

LISTA AV ILLUSTRATIONER Figurförteckning Figur 1: Alla projekten i lösningen... 17 Figur 2: Ett flödesschema som visar vilka steg en sida på webbplatsen går igenom... 21 Figur 3: Visar en skärmbild där en text ska översättas.... 27 Figur 4: Presentationsvy i administrationsverktyget.... 27 Figur 5: Vyn "Översätt text".... 28 Figur 6: Välj text att översätta.... 28 Figur 7: Nya översättningen presenteras på webbsidan... 29 Figur 8: Visar basstrukturen och innehållet i en MasterPage.... 32 Figur 9: Innehållet på denna sida baseras på masterpage-filen i figur två.... 32 Figur 10: En skärmdump när NUnit körs från Visual Studio... 36 Figur 11: En skärmbild över hur fuktionen GetTranslationManagementDB exekverats.... 39 Figur 12: Relationerna mellan de olika tabellerna som utgör översättningshanteringen... 46 Figur 13: Relationerna mellan de olika tabeller som utgör administrationsverktyget... 46 Figur 14: Funktioner för att logga in och för att rita upp menyer.... 51 Figur 15: Kategorihanterigen listar, lägger till och tar bort kategorier... 51 Figur 16: Interfacet ITextCategory beskriver en textkategori... 52 Figur 17: Interfacet IUserInfo beskriver en användare i administrationsverktyget... 52 Figur 18: Interfacet IAdminMenuItem beskriver ett val i administrationsverktyget... 52 Figur 19: Interfacet IRole beskriver en användarroll i administrationsverktyget... 52 Figur 20: Funktioner för hantering av språk... 52 Figur 21: Funktioner för hantering av texter... 53 Figur 22: Interfacet ILanguageInfo beskriver ett språk... 53 Figur 23: Interfacet ITextValueInfo beskriver en text... 53 Figur 24: Klassen Translation sköter översättning av texterna... 53 7

Tabellförteckning Tabell 1: Sammanfattning och kort beskrivning över alla utformade användarfall... 16 Tabell 2: Översikt över användargruppernas behörigheter i administrationsverktyget... 25 Tabell 3: En sammanställning over de funktionerna som tog längst tid att exekvera... 39 Tabell 4: Innehåller en sammanställning över de termer som använts i rapporten... 45 Tabell 5: Beskriver de lagrade procedurer som är relaterade till inloggning och användare... 47 Tabell 6: Lagrade procedurer som hanterar texter och textkategorier... 48 Tabell 7: Lagrade procedurer som ansvarar för språkhanteringen... 48 Tabell 8: Webbplatsens alla texter finns sparade i tabellen Text... 49 Tabell 9: Tabellen TextCategory innehåller alla kategorier en text kan tillhöra... 49 Tabell 10: Tabellen Language innehåller alla språk som webbplatsen kan visa... 49 Tabell 11: Tabellen AdminUser innehåller användare som har tillgång till verktyget... 50 Tabell 12: Tabellen UserRole definierar administrationsgränssnittets olika roller... 50 Tabell 13: Tabellen AdminFunction innehåller de olika funktioner man kan utföra i administrationsgränssnittet.... 50 Tabell 14: Tabellen RoleFunctionAccess är en kopplingstabell mellan UserRole och AdminFunction.... 51 Tabell 15: De mest frekvent förekommande felen enligt FxCop.... 58 Tabell 16: Tider (i ticks) för att ladda ett urval av de olika texterna på framsidan... 59 Tabell 17: Tiderna visar hur tiden varierar vid de tre första laddningarna av svenska texter... 59 8

9 Inledning 1 INLEDNING Detta kapitel tar upp varför denna rapport skrivits och beskriver de grundläggande kraven som specificerades inför projektets start. 1.1 Företaget E-man AB E-man AB grundades på våren år 2000 av en liten grupp konsulter med det gemensamt att de alla har lång erfarenhet inom konsultverksamhet. Idag har företaget ca 35 anställda utspridda över fyra orter i Sverige. Huvudkontoret är beläget i Örebro, men E-man har även kontor i Västerås, Göteborg och nu senast i Stockholm. Grundidén är att erbjuda företag eller organisationer konsulttjänster från konsulter med lång branscherfarenhet och bred kunskap. E-man kan erbjuda specialistkompetens inom applikationsförvaltning, utveckling och systemintegration. 1.2 Om dokumentet Denna rapport riktar sig främst till personer med grundläggande kunskap inom webbutveckling och intresse för onlinebaserade projekt. Stort fokus riktas mot den tekniska lösningen av projektet. Därför bör läsaren ha kännedom om, framförallt Microsofts, olika teknologier för webbutveckling och programvara relaterat till onlinebaserade system. Inledande förklaringar finns skrivna till vissa nyare tekniker. För mer detaljerade beskrivningar hänvisar jag till referenslistan som innehåller de webbplatser och böcker där jag inhämtat information. 1.3 Bakgrund Efter ungefär ett år med en hemsida med ett visst språkstöd, men med ett undermåligt verktyg för att redigera och lägga in nya texter, så har E-man AB insett att de behöver förbättra situationen. Framförallt ville företaget komma ifrån att en anställd var tvungen att ta tid från sitt jobb för att sköta uppdateringen av översatt material. Istället vill man låta en översättare få direkt tillgång till att ändra i webbplatsens innehåll. För att minska extrajobbet vid förändringar på webbplatsen så önskar E-man gå över till MasterPage-konceptet som introducerades i Asp.Net 2.0. 1.3.1 Innehållshantering Att hålla webbplatsens innehåll uppdaterat och felfritt är oerhört viktigt för företag, dels för att göra ett seriöst intryck mot kunder men även ur ett sökmotorperspektiv. Att optimera sin webbplats för att få en bra placering i sökresultat kan generera betydande affärer. En uppdaterad webbplats är en förutsättning för en bra ranking 1. Att underlätta arbetet för att uppdatera och lägga till innehåll var därför den stora utmaningen. Samtidigt som företaget vill låta extern personal sköta översättning och redigering av texterna, vill man kunna begränsa vad de olika användarna får se och vilket innehåll de har rättighet att ändra. Krav på autentisering av användaren och rättighetshantering krävs därför. Till skillnad från ett komplett system för innehållshantering för en webbplats ligger fokus för denna rapport på redigering av texter. Det finns inga funktioner för 1 Denna fras, och efterföljande fraser i fetstil, definieras i terminologisektionen på sidan 44. 9

10 Inledning att skapa nya/ta bort befintliga sidor eller publiceringsfunktioner, t.ex. att sätta tider då en sida ska vara synlig. 1.3.2 Existerande system I det existerande systemet består översättningshanteringen av en funktion som listar vilka språk som finns tillgängliga och för varje sida på webbplatsen listas en länk som pekar mot en sida med översatt innehåll. När användaren är på förstasidan och den visas på det svenska språket är adressen till sidan /default.aspx. Skulle användaren vilja byta till det finska språket skulle han gå till /fin/default.aspx och engelska /eng/default.asp. För varje sida låg sedan innehållet statiskt direkt i aspx-sidan och det fanns då en uppsättning av den sidan för varje språk som webbplatsen stödde. Dessutom byggdes webbplatsen på den äldre versionen Asp.Net 1.1 som saknar MasterPages. Vill man då göra en designändring som är generell för webbplatsen så måste alla sidor på alla språk gås igenom; det kan handla om så mycket som 40 sidor. Detta var onödigt extraarbete som E-man ville undvika. Den existerande lösningen är en fullt fungerande implementation, men den leder till mångdubbelt arbete vid ändringar av innehållet. Dessutom behövs en resurs från E-man som lägger in texter som översättare tillhandahåller, då översättare inte har direkt tillgång till filerna på grund av företagets säkerhetspolicy. 1.3.3 Administrering För att förbättra och göra webbplatsen tillgänglig för ytterligare besökare, som inte behärskar de språk som finns tillgängliga, behövs ett fungerande administrationsverktyg. Verktyget tillhandahåller sedan funktioner för utbyggnad och uppdatering av webbplatsen. Som exempel på vad verktyget skall klara av kan nämnas att korrigera texter, lägga in nya texter, men även lansera helt nya språk. Ett verktyg skulle därför införas för att tillgodose dessa krav. Till ett administrationsverktyg tillkommer även grundläggande behov som autentisering och rättighetshantering. Verktygets alla användare som har tillgång till verktyget kan inte få tillgång till alla dess funktioner då oerfarna användare av misstag kan ta bort viktiga funktioner eller att hemligt innehåll läcker ut. 1.4 Problembeskrivning E-mans hemsida har under åren genomgått ett antal uppgraderingar och designförbättringar. I den senaste stora uppgraderingen fick webbplatsen stöd att visa innehållet på flera språk (svenska, engelska och finska). Av någon anledning infördes det aldrig något administrationsgränssnitt, vilket innebar en krånglig och komplicerad process för uppdateringar. Uppdateringar krävde ofta direkt tillgång till aspx-filen. Den samlade problematiken resulterade i att endast den svenska versionen blivit uppdaterad med nytt innehåll. För att minska extrajobbet vid förändringar på webbplatsen så önskar E-man gå över till ett administrationsverktyg för att ändra texter och översättningar på webbplatsen. 10

11 Inledning 1.5 Grundkrav Innan projektet startade sammanställdes en lista över punkter som skulle tilldelas extra fokus. Den listan låg sedan till grund för kravdokumenten som skrevs i den inledande perioden för specifikation. En ordentlig kravinsamling utfördes för att identifiera behoven, samt skriva användarfall och skapa klassdiagram som bas för kod och databasdiagram. 1.5.1 Mål för språkmotorn och demonstrationswebbplatsen Här följer de mål som sattes upp innan projektets start: - Alla typer av texter ska vara översättningsbara: sidtitlar, metadata och längre innehåll. - Presentera ett stort antal språk (låta användaren välja språk) - Presentera texter i alla större teckenuppsättningar. - Systemet skall använda så mycket information som möjligt av de data som användaren lämnar ut för att identifiera vilket språk som sidan skall presenteras på. 1.5.2 Mål för administrationsgränssnittet - Alla texter som presenteras på webbplatsen ska vara administrerbara. - Inloggning till systemet sker via formulär. Inloggningsuppgifter sparas i databasen för systemet. - Systemet ska kunna hantera att falla tillbaka till ett förvalt språk. Vid de tillfällen då en användares språk inte stöds skall systemet falla tillbaka till bäst applicerbara språk. Detta sköts via administrationsgränssnittet. - Administrationsgränssnittet skall använda minimalt antal omladdningar. Tekniken som gör detta möjligt sker via AJAX och Microsofts ramverk Atlas. En diskussion om framtida förbättringar finns i kapitlet slutsatser på sidan 40. 1.6 Arbetsgång För att på bättre struktur på projektgenomförandet valde jag att dela upp arbetet enligt följande delmoment: kravinsamling, implementation och dokumentering som presenteras i följande kapitel. 1.6.1 Kravinsamling och systemdesign I inledningen av projektet så sammanställde jag alla önskemål och krav som kunden (i detta fall E-man AB) vill ha för webbplatsen. Mer om kravinsamlingen se kapitel 3.1 Kravinsamling. Leverabler från detta delmoment inkluderar ett förstudiedokument, en databasmodell och ett klassdiagram. Efter kravinsamligen var klar så gjordes design av projektstrukturen samt databas och källkod. Klass- och databasdiagramen som producerades är bifogade i Appendix A: Databasen och Appendix B: Klassdiagram. Under denna period bestämde jag även vilka tekniker och vilken miljö jag skulle använda mig av vid utvecklingen; mer om detta i kapitlet Metoder och verktyg på sidan 13. 11

12 Inledning 1.6.2 Implementering av systemet Efter den inledande specifikationen var godkänd och designen av webbplatsens grund var klar så följde implementeringen, dvs. skriva kod. Till stöd för utvecklingen hade jag den sammansatta listan av användarfall och klassdiagram, men innan jag startade med kodningen tog jag mig tid att ordentligt läsa på om de tekniker jag hade bestämt mig för att använda. Efter förberedelserna gick det sedan enkelt att komma igång med kodningen. Jag sorterade upp användarfallen efter hur pass viktiga de var för systemets grundläggande funktioner och efter det så betade jag av dem en efter en. 1.6.3 Test och dokumentation Utvecklingsmetodiken jag följde när jag skrev webbplatsens kod var Test Driven Development. Denna utvecklingsmetod innebär att innan man skriver kod för t.ex. en funktion så fastställs vad som behöver testas i funktionen, och skriver kod för testet. När testet är klart implementeras funktionen (mer om detta i kapitel Enhetstester och TDD). Att skriva tester innan implementationskoden gjorde att antalet kodfel hölls på en låg nivå och jag kunde inrikta arbetet på nya funktioner istället för att leta och rätta fel. Relativt tidigt under projektet, redan innan implementationen startat, påbörjade jag arbetet med att designa dokumentet som skulle ligga till grund för denna rapport. Under arbetets gång kunde jag sedan fylla på allteftersom projektet pågick. 12

13 Metoder och verktyg 2 METODER OCH VERKTYG 2.1 Verktyg Dessa tekniker fanns som krav att systemet skulle utvecklas i: - Utvecklat i ASP.NET 2.0 - Programmeringsspråk: C# - Atlas för AJAX stöd - Systemet skall bygga på databasen SQL Server 2000 - Webbplatsen körs på IIS - Enhetstester via NUnit Utvecklingen av språkmotorn och administrationsgränssnittet skedde i utvecklingsmiljön Visual Studio 2005. Utvecklingsmetoden Test Driven Development användes med framgång under stora delat av projektet. Under projektets gång lanserade Microsoft SQL Server 2005 Express, vilket är en gratisvariant av deras serverprogramvara för frågespråket SQL (Begg & Connolly, 2002). Jag valde då att gå över till denna nyare programvara. Dessutom så gick AJAX ramverket från alfa-stadie till beta-stadie och bytte under det skiftet namn från Atlas till Ajax.Net. Även denna uppdatering valde jag att installera. 2.2 Projektstruktur För de ingående projekten är koden för både webbplatsen och administrationsverktyget uppdelade enligt principen för designmönstret MVC (Model, View, Controller). Designmönstret beskriver hur ett projekt ska delas upp i tre lager: ett presentationslager, ett kontrollager och ett modellager. Kontrollagret svarar på interaktioner/anrop från användaren som utförs i presentationslagret. Modellagret används för att agera förvaringskälla för tänkbar data. 2.2.1 Presentationslager I detta projekt representeras presentationslagret av det gränssnitt som besökaren ser, både i administrationsverktyget och i den publika webbplatsen. 2.2.2 Kontrollager Till skillnad från traditionell 3-skitks arkitektur har detta projekt inget affärslager som sköter affärslogiken. Kontrollagret agerar endast som ett mellanlager som sköter kontakten mellan presentationslagret och modellagret. Jag har valt att i fortsättningen kalla detta lager för fasadlagret då det bättre passar in i detta sammanhang. Fasadlager är inte alls beroende av vilken sorts datakälla som används i modellagret. Kan modellagret returnera de datatyper som fasadlagret förväntar sig så kan valfri datakälla användas. 2.2.3 Modellagret Modellagret representeras i detta projekt av databasen och de klasser som används för att kommunicera med databasen. I största möjliga mån har jag försökt att enbart använda de primitiva datatyperna (int, string osv.) i detta lager. Detta lager kommer fortsättningen benämnas som databaslager. 13

14 Metoder och verktyg 2.3 CSS-baserad design En CSS-baserad design bygger på att alla direktiv om hur en sida skall renderas, dvs. vilka element som ska ligga vart och vilket utseende de skall få, ska ligga i en CSSfil. Html-filen skall endast skriva ut innehållet; det är sedan upp till CSS-filen att sätta design. Fördelarna är många: - Man kan återanvända design över flera sidor. - All design finns på ett ställe, man undviker upprepade instruktioner. - HTML-filerna blir mindre, ett företag kan spara pengar på minskade kostnader på grund av onödig data som skickas. Då CSS filen lagras hos användaren så behöver filen bara skickas en gång. - Designändringar förenklas då man enbart behöver ändra på ett ställe. 14

15 Genomförande 3 GENOMFÖRANDE Målet för projektet var att förenkla och förbättra processen kring översättning och innehållshantering av E-mans hemsida. Jag valde att från grunden skapa ett administrationsgränssnitt som både är specialskrivet för E-mans hemsida men även så pass generellt att det går att anpassa till andra typer av applikationer. Samtidigt behövde bakgrundskoden för E-mans publika hemsida skrivas om så att den integrerar mot applikationsverktyget. I samband med omstruktureringen av den publika webbplatsen valde vi att designa om strukturen för att komma ifrån mycket av kringarbetet. Dock ser sidan precis likadan ut som tidigare. 3.1 Kravinsamling Följande kapitel kommer att beskriva hur kraven specificerades och hur specifikationen användes av mig som utvecklare. Kravinsamling görs för att specificera vilken funktionalitet som ett system skall ha för projektet ska anses vara färdigt. 3.1.1 Användarfall Ett användarfall beskriver ett flöde som en användare kan utföra i ett system eller i en applikation. Fallen är vanligtvis skrivna i beskrivande textform, men man kan även skriva/rita dem i diagramform. I större applikationer begränsar man ofta användarfallen genom att kräva att ett system ska befinna sig i ett visst tillstånd då fallet startar. Ett användarfall kan anses klart då det har åstadkommit vad som specificerats, eller då applikationen befinner sig ett specificerat sluttillstånd. 3.1.2 Skrivna användarfall Denna sektion kommer att kort nämna vilka användarfall som skrevs och ge en kort beskrivning av dess betydelse. De fullständiga användarfallen finns bifogade i Appendix C: Användarfall med start på sidan 53. De fallen är mer detaljerade vad det gäller vad som skall utföras för att anse fallet som avklarat. Namn Beskrivning Administrationsgränssnitt Inloggning Förstasida Hämta text Uppdatera text Spara ny text För att få använda administrationsgränssnittet krävs att användaren loggar in på systemet. Den första sidan som användaren kommer till skall presentera möjliga delar/funktioner som den inloggade användaren har tillgång till. Användarfallet beskriver hur en användare navigerar i listor och väljer den text som skall översättas. Texten presenteras i en textruta. Detta fall beskriver hur en vald text uppdateras. Detta fall beskriver hur en ny text lagras i systemet. 15

16 Genomförande Editera ett existerande språk Lägga till ett språk Lägga till en textkategori Ta bort textkategori Detta användarfall behandlar hur man uppdaterar metadata för ett språk. Detta fall beskriver hur ett nytt språk läggs in i systemet. Detta användarfall beskriver hur en användare lägger till nya textkategorier. Detta fall beskriver hur en textkategori tas bort. Språkmotorn Översättning av en fras Hämta text via kod Detta användarfall beskriver hur fraser ur en längre text översätts. Detta fall besktiver hur en text hämtas baserat på en text-kod. Övriga Hämta aktiva språk Detta användarfall används på den publika webbplatsen för att hämta en lista över de aktiva språk som en besökare kan se webbplatsen på. Hämta lokalinformation från besökaren Systemet ska utgå från den informationen om geografi och språkval som webbläsaren delger och genom den välja det språk som sidan ska presenteras på. Tabell 1: Sammanfattning och kort beskrivning över alla utformade användarfall 16

17 Genomförande 3.2 Projektdesign För att få en överblick hur lösningen är uppbyggd så kommer detta kapitel presentera de ingående projekten som utgör webbplatsen. För att skapa en lösning som är lätt att underhålla och lätt att uppgradera med ny funktionalitet har jag valt att dela upp den stora lösningen i ett flertal mindre delprojekt. När man har delprojekt påverkas inte hela webbplatsen vid uppdateringar utan endast de beröra delprojekten. Figur 1: Alla projekten i lösningen Strukturen i figur ett gäller enbart så som miljön ser ut under utveckling. När webbplatserna (publika webbplatsen och administrationsverktyget) ska publiceras så kompileras varje delprojekt till en DLL-fil och kopieras till underkatalogen BIN som skapas upp för respektive webbplats. DDL-filerna får namn efter vad delprojektet heter, t.ex. TranslationManagement.Globalization.dll 3.2.1 Uppdatering och underhåll Vid en initial lansering, dvs. första gången en lösning lanseras i en produktionsmiljö, så kopieras alla aspx-filer och alla kompilerade DLL-filer till en produktionsserver. Detta är en stor operation som innehåller många felkällor där mycket kan gå fel. Är produktionsmiljön dessutom lastbalanserad är risken för fel ännu större, då samma procedur måste upprepas på flera servrar. Lanseringsprocessen sker dessutom under tidspress, då önskan att starta webbplatsen så snart som möjligt är stor. Att undvika denna process leder till en större säkerhet för både personen som utför lanseringen, och att webbplatsens besökare snabbare får tillgång till webbplatsen. För att underlätta uppdateringar och underhåll av systemet så delades lösningen upp i flera delprojekt och varje delprojekt kompileras till en fristående DLL. Vid uppdateringar/felrättningar av en del av webbplatsen, eller kanske endast ett delprojekt, så behöver man endast byta ut de berörda filerna. 17

18 Genomförande 3.2.2 Projektet CacheHelper Klassen CacheHelper används för att initiera objekt som kommunicerar med cachen. Detta är en statisk klass som returnerar en instans av CacheFactory, en klass som ingår i Enterprise Library (mer om detta på sidan 34). Initieringen sker endast då objektet är null, dvs. första gången cachen laddas. 3.2.3 Projektet DatabaseHelper Klassen DatabaseHelper används för att initiera ett objekt som kommunicerar med databasen. Detta är en statisk klass som returnerar en instans av DatabaseFactory, en klass som ingår i Enterprise Library (mer om detta på sidan 34). Initieringen sker endast då objektet är null, dvs. första gången databasen laddas. 3.2.4 Projektet TranslationManagementAdminArea I detta projekt ligger de filer som utgör presentationsdelen för administrationsverktyget. Administrationsverktyget består av en masterpage som styr design, en sida för inloggning och en välkomstsida. Övriga sidor är enbart skal för att ladda en User Control. All logik för kontrollerna ligger i projektet TranslationManagement.Admin. Administrationsverktygets basklass kontrollerar att användaren fortfarande är inloggad. 3.2.5 Projektet TranslationManagementWeb Projektet TranslationManagementWeb är en webbplats som utgör demowebbplatsen. Webbplatsen innehåller kopior av sidor från www.e-man.se så som sidorna såg ut vid tillfället då detta dokument skrevs. Sidorna har ändrats så att det statiska innehållet är utbytt mot koder som sedan kommer att användas för att presentera översatt innehåll. Alla sidor på webbplatsen ärver en gemensam basklass. Basklassen innehåller logik för att identifiera det språk som passar en ny besökare bäst och anropar de funktioner som översätter texter. 3.2.6 Projektet TranslationManagement.Admin All logik för administrationsverktyget är samlat i detta projekt. Denna klass innehåller dessutom koden som ritar upp html-elementen för User Controller. Kontrollerna använder AJAX i den utsträckningen att de data som postas till webbservern enbart är data från formulären. 3.2.7 Projektet TranslationManagement.Authentication I detta projekt hittas logiken som styr användarrättigheter för webbplatsen. Projektet innehåller funktioner för att hantera användarinloggning och verifiering av användarrättigheter. Klassen består av ett fasadlager och ett databaslager. 3.2.8 Projektet TranslationManagement.Globalization Funktioner för att hantera texter och textkategorier finns samlade i detta projekt. Även en statisk klass för översättning av texter är placerad här. 3.2.9 Projektet TranslationManagement.LanguageHandling Funktioner som rör språk hanteras i detta projekt. Som de övriga projekten är det uppdelat i fasad- och databaslager. 18

19 Genomförande 3.2.10 Projektet TranslationManagement.WebUtilities Gemensamma funktioner för webbplatsens olika webbsidor ligger i detta projekt. Även basklassen som alla sidor ärver ligger i detta projekt. 3.2.11 UnitTest -katalogen Innehåller de enhetstester som jag skrivit för lösningen. Dessa projekt ingår och kompileras endast då projektet byggs för utveckling. I en skarp version som går publikt kommer projekten i denna katalog att uteslutas. 3.3 Hur översättningskraven är uppfyllda Följande kapitel kommer att ge en mer tekniskt detaljerad genomgång av hur de olika projekten införts och hur delproblemen lösts. Flera kapitel innehåller kodexempel som är tagna ur källkoden för webbplatsen och administrationsverktyget. Grundkravet för applikationen var att innehållet på webbplatsen går att översätta så att webbplatsen kan presenteras på flera språk. Den tekniska lösningen baseras på att varje text som skall kunna översättas identifieras genom att märkas med tecknen ## före och efter ett id för en text. Identifikationen av en text, härmed kallat koden för en text, består av textens namn och namnet på kategorin som texten tillhör. Ett exempel på en text blir: ##Textkategori.Textnamn##. Den tredje parametern som behövs för att översätta en text är på vilket språk som besökaren just nu ser på webbplatsen. Med hjälp av dessa tre variabler kan systemet presentera rätt innehåll. Efter att sidans innehåll har genererats av ASP.Net ramverket så skickas den genererade HTML-koden för presentation. Precis innan HTML-koden skickas till webbläsaren så fångar applikationen upp HTML-koden. Alla textkoder letas sedan upp och byts ut mot det översatta innehållet. När alla textkoder är ersatta skickas HTML-koden vidare till webbläsaren. Ur kodperspektiv betyder det att applikationen skriver över händelsen Render (rendera) och här letar upp alla koder. Funktionssignaturen för denna funktion ser ut såhär: protected override void Render(HtmlTextWriter writer) { //Function body goes here... } Override -instruktionen i funktionssignaturen styr så att denna funktion används i stället för den inbyggda funktionen. Render-funktionen ligger i en basklass för webbplatsen. 3.3.1 Hämta text från databas För varje kod som hittas i HTML-koden så sätts en nyckel ihop; nyckeln består av kategori, textnamn och språkkod. Nyckeln används sedan för att hämta upp korrekt text-värde. För att beskriva hur översättningen sker kommer jag att använda följande testdata: Kategori: FrontPage Text-namn: SamplePhrase Nyckeln för de olika texterna blir "FrontPage.SamplePhrase_en" och "FrontPage.SamplePhrase_sv". 19

20 Genomförande Nästa steg är att slå upp text-koden mot databasen. Om applikationen lyckas matcha en text mot de tre variablerna returneras en data-rad. Innehållet i data-raden används för att initiera ett objekt som implementerar gränssnittet ITextValue. En cache används av applikationen för att spara de skapade objekten. Det extra steget utförs för att komma ifrån behovet att hämta varje värde från databasen och sedan skapa ett objekt. Nyckel som identifierar objektet i cachen är den ovan skapade nyckeln. Vid nästa laddning av sidan hämtas objektet från den snabbare cachen. En tabell över hur tiden det tar att ladda framsidan varierar finns att se i kapitlet Appendix G: Laddningstider på sidan 58. 3.3.2 Identifiera koder I den genererade HTML-strängen kommer det att finnas en mängd text-koder att söka reda på. Att leta upp alla koder samt att utföra detta utan märkbar tidsfördröjning är en utmaning. Till hjälp använder applikationen ett reguljärt uttryck som letar upp alla förekomster av en text som kan matchas mot uttrycket ##[text]##, dvs. de koder applikationen använder för att identifiera en text. Det uttrycket som applikationen använder ser ut såhär: "#{2}(.*?)#{2}" Den första och sista delen #{2} säger att texten den ska leta efter ska börja med ett #, och att det ska vara två i rad. Det sista betyder att koden ska avslutas på samma sätt. Den mittersta delen (.*?) betyder kort sagt allting där i mellan som har minst en punkt. De tre reglerna gäller för att en text ska matcha. 3.3.3 Ersätta koden När applikationen väl har identifierat koden och hämtat dess värde från databasen så ska applikationen ersätta textkoden med den översatta texten. Funktionen "Replace" på String-klassen används för detta ändamål. Funktionen tar textkoden och den översatta texten och ersätter alla förekomster av koden. Såhär ser funktionsanropet ut: translatedstring = translatedstring.replace(foundcode.value, translatedvalue); translatedstring är i detta fallet strängen med HTML, foundcode.value är textkoden och translatedvalue är det översatta värdet. Detta sker för varje översättbar-text, varenda gång en sida laddas. Skulle en textkod förekomma flera gånger i html-koden så kommer alla förekomster att ersättas med ett anrop. 20

21 Genomförande 3.3.4 Flödesschema För att ge en tydligare bild hur flödet ser ut då en sida får sina texter utbytta mot översatt innehåll har detta schema skapats. 1) Start 3) Sök kod 2) Sidladdning 4a) Kod finns i cache 4b) Ingen kod i cachen 5a) Hämta text från cache 5b) Hämta text från DB 5c) Spara text i cache 7) Upprepa för varje kod 6) Ersätt text 8) Slut Figur 2: Ett flödesschema som visar vilka steg en sida på webbplatsen går igenom 1) Startpunkten. Här initieras en laddning av en av webbsidorna på den publika webbplatsen. 2) De olika delsteg som en sida går igenom utför olika funktioner som initierar webbsidan, t.ex. händelserna Page_Load ( sidladdning ) och Page_PreRender ( innan rendering ) genererar dynamiskt innehåll som ska skrivas ut på webbsidan. Alla kontroller på sidan binder data till sidan och den 21

22 Genomförande färdiga HTML-strukturen skickas för presentation. I detta läge innehåller HTMLstrukturen fortfarande de koder som översättningsmotorn använder. 3) Identifiera koder i HTML-strukturen. Systemet använder sig av reguljära uttryck för att hitta de koder som skall översättas. När en kod hittats går flödet vidare och när inga fler koder går att hitta tar flödet slut. 4) En kod har identifierats. Systemet gör nu en koll ifall denna kod har påträffats av tidigare sidladdningar. I så fall kan cachen användas annars måste databasen leverera texten. a. Systemet lyckades hitta koden i cachen och kan därmed genast returnera texten med hjälp av koden. b. Systemet har inte påträffat denna kod tidigare. Därför krävs att koden skickas till databasen som i sin tur returnerar texten som matchar koden. 3.4 Hur språkhanteringens grundkrav är uppfyllda Följande kapitel kommer beskriva hur grundkraven för språkhanteringen är uppfyllda. Listan över krav finns sammanställd i kapitel 1.5 Grundkrav. 3.4.1 Språk E-man har hittills valt att översätta hemsidan till tre språk: svenska, engelska och finska (finska då företaget har vissa affärer i Finland). För att korrekt visa upp en webbsida på ett specifikt språk, så att en webbläsare kan identifiera vilket språk som presenteras, behöver sidan ange denna information. Metoden för att identifiera språket sker främst via de meta-taggar som finns i html standarden. För att presentera vilket språk en sida visas på använder man en språkkod. Språkkoden sammanställs av en internationell standardorganisation och består av två bokstäver. I vissa fall kan fyra bokstäver användas, de extra två beskriver då vilken dialekt som används. För att presentera språkets olika bokstäver rätt behöver även språkets teckenuppsättning anges på sidan. Språkinformation är även viktig för sökmotoroptimering. På webbplatsen kan ett språk vara aktivt eller inaktivt. Ett språk ska även vara ett förvalt språk, dvs. det språk som applikationen faller tillbaka på i de fall ett önskat språk inte existerar i databasen. De aktiva språken visas på webbplatsen, medan de inaktiva endast går att nå via administrationsverktyget. Tanken är att när ett nytt språk läggs till så kan en översättare i lugn och ro översätta alla texter innan språket visas upp publikt på webbplatsen. I de fall då det språk som användaren helst vill se webbplatsen på inte är aktivt, alternativt då det inte finns i databasen, ska systemet använda funktionen GetDefaultLanguage i Language -klassen som returnerar det förvalda språket. Det språket ska webbplatsens innehåll sedan visas i. Systemet faller då tillbaka till det språk som är satt som förvalt i administrationsverktyget. För varje besökare av den publika webbplatsen associeras ett interface av typen ILanguageInfo. Det beskriver alla egenskaper som systemet använder för ett språk. Efter att objektet initierats så sparas det i besökarens session. 3.4.2 Hämta användarens önskade språk I dagens moderna webbläsare har det blivit allt viktigare att presentera för en webbplats vilken region en användare kommer ifrån. Behovet uppkommer för allt 22

23 Genomförande ifrån att visa rätt språk till att leverera riktade regionsspecifika annonser till användaren. Ofta väljer man vilket land man kommer ifrån när man laddar hem eller installerar webbläsaren, men man kan även styra denna information via inställningar i webbläsaren. Variablerna som beskriver användaren skickas till webbplatsen när användaren gör en anslutning. Alla variabler som webbläsaren ger ifrån sig kan man komma åt via klassen HttpRequest och egenskapen ServerVariables. Klassen ligger i namnrymden System.Web. ServerVariables är en datakälla där man skickar in en nyckel för att få tillbaka ett värde. Nyckeln för att få tag i användarens önskade språk heter HTTP_ACCEPT_LANGUAGE. Värdet för den variabeln får man tag igenom att använda nyckeln på detta sätt: string languageinfo = Request.ServerVariables["HTTP_ACCEPT_LANGUAGE"]; Värdet som returneras kan se ut som denna sträng: sv,en;q=0.7,en-us;q=0.3 Även om den kan anses något kryptisk så är den väldigt enkel. De språk som användaren har förvalt är sv = svenska, en = engelska och en-us = engelska med amerikansk dialekt. De olika språken separeras via kommatecknet, parametern q står för quality och anger vilken sannolikhet det är att det språket matchar besökarens preferens. Språkkoden för svenska sv har q=1 och har i detta fall högst sannolikhet, det vill säga att det är väldigt sannolikt att användaren vill att sidan visas på svenska. På grund av risken att användarens önskade språk inte stöds av webbplatsen, eller att det önskade språket inte är aktivt, görs en matchning där användarens önskade språk jämförs med webbplatsens aktiva språk. Hittas en matchning presenteras webbplatsen på det språket, annars faller applikationen tillbaka till det språk som har satts som det förvalda språket. 3.4.3 Visa aktiva språk De aktiva språken skrivs ut med hjälp av en kontroll som ligger på en av grundsidorna, denna kontroll blir därmed inkluderad på alla sidor. För att byta språk på webbplatsen implementerades användarfallet "Hämta aktiva språk". För att hämta aktiva språk används den lagrade proceduren "GetAllActiveLanguages". Språkbytet sker genom att en parameter "l" (kort för language ) läggs på sidans frågesträng (querystring). Adresserna till startsidan default.aspx blir: Default.aspx?l=en, Default.aspx?l=sv. När systemet ser att språkkoden bytts initieras ett ILanguageInfo-interface med hjälp av den nya språkkoden och den aktuella besökarens sessionsvärde uppdateras med det nya objektet. Information om användarens valda språk, det som sidan presenteras på, hämtas upp i basklassen från sessionsvariablerna via denna instruktion: ILanguageInfo currentlanguage = ((BaseWebPage)this.Page).WebUser.PreferredLanguage; 23

24 Genomförande Efter att gränssnittet hämtats från basklassen skrivs språkkoden och teckenuppsättningen ut på två ställen i sidans huvudsektion (header): literalcharacterset.text = currentlanguage.languagecharset; literallanguagecode.text = currentlanguage.languagecode; Webbläsaren kan då rendera sidans innehåll korrekt. Vanliga problem man kan råka ut för annars är att specialtecken inte presenteras korrekt, till exempel kan man få problem med att å, ä och ö skrivs ut felaktigt. 3.5 Hur Administrationsverktygets grundkrav är uppfyllda Följande kapitel kommer beskriva hur grundkraven för administrationsverktyget är uppfyllda. Listan över krav finns sammanställd i kapitel 1.5 Grundkrav. 3.5.1 Inloggning För att undvika att obehöriga besökare får tillgång till administrationsverktyget, där de kan göra stor skada, så krävs att användare autentiserar sig själva. Detta sker med hjälp av ett lösenord och ett användarnamn som personen blir tilldelad. När användaren anländer till förstasidan för administrationsverktyget så kontrollerar systemet huruvida användarens information finns sparad i användarens session. Användarinformation representeras med hjälp av interfacet IUserInfo och initieras när användaren loggar på administrationsverktyget. Finns objektet sparat så välkomnas användaren med namn, annars blir han/hon automatiskt omdirigerad till inloggnings-sidan. Har användaren en gång vart inloggad på systemet, men lämnat datorn så pass länge att session gått ut, kommer den besökaren bli ombedd att återigen logga in. Vid godkänd inloggning kommer sedan systemet automatiskt dirigera administrationsanvändaren till den sida som personen senast arbetade på. Logiken för att logga in användare och skicka dem rätt är inget som man behöver skriva själv, utan det är en funktionalitet som finns i.net-ramverket. Det man behöver göra är att instruera systemet hur anonyma användare ska hanteras; detta sker i konfigurationsfilen web.config. Denna regel instruerar ramverket att inte tillåta anonym åtkomst på webbplatsen: <authorization> <deny users="?"/> </authorization> Nedanstående regel säger till ramverket att användare ska logga in via ett formulär som heter adminform, att användaren ska sedan skickas vidare till sidan default.aspx när inloggningen är klar och att användare ska skickas till login.aspx för att logga in. <authentication mode="forms"> <forms loginurl="login.aspx" defaulturl="default.aspx" name="adminform"/> </authentication> 24

25 Genomförande I tabellen AdminUser ligger alla användare som har tillgång till systemet. Denna tabell är speciellt känslig då den innehåller inloggningsinformation. För att säkra systemet så lagras lösenordet krypterat i en hash, man kan alltså inte läsa ut lösenordet direkt från innehållet i databasen. Vid inloggningen så skapas en hash av det värde som användaren matar in och hashvärdet för den inmatningen jämförs sedan med hashvärdet av lösenordet som redan ligger i tabellen. Krypteringsfunktionen som krypterar hashvärdet är sha-1. Krypteringen gör det avsevärt mycket svårare att få fram lösenordet och därmed ta sig in i systemet, men det är dock inte omöjligt. Sha-1 ska i sig vara oknäckbart, men det finns en möjlighet att någon lyckas mata in rätt kombination, och därmed kan ta sig in i systemet. 3.5.2 Användarmenyn För att navigera runt bland administrationsverktygets olika sidor så innehåller administrationsverktyget en navigeringsmeny. Samtidigt som man vill göra det enkelt för en användare att hitta i systemet vill man inte att en användare ska kunna komma åt information den inte ska få se. Vissa användargrupper ska till exempel enbart få översätta texter. Beroende på vilken användarroll som den inloggade användaren är tilldelad, ska innehållet i menyn varieras. Menystrukturen i sig är enkel, den består av tre större sektioner: texter, textkategorier och språk. Varje sektion har i sin tur undersidor. Användargrupp Administratörer Översättare Sektion och funktion/undersida Texter o Lägga till text o Översätta text Textkategorier o Lägga till kategori o Ta bort kategori o Ändra kategorinamn Språk o Lägga till språk o Ändra språkegenskaper o Sätta förvalt språk Texter o o Lägga till text Översätta text Tabell 2: Översikt över användargruppernas behörigheter i administrationsverktyget I databasen har varje funktion ett id och en förälder. Texter som är en toppfunktion har förälder-id=0 och funktions-id=1, Lägga till text är ett barn till Texter, den har funktions-id=11 och förälder-id=1. Baserat på den strukturen kan man sedan hämta ut menyn, först hämtas alla toppfunktioner, när de skrivs ut på sidan skrivs dess barn ut. Hela strukturen laddas via ett anrop till databasen. På detta vis presenteras menyn enligt liknande: Texter (Funktions-id 1, Förälder-id = 0) 25

26 Genomförande o Lägg till text (Funktions-id 11, Förälder-id = 1) o Översätt text (Funktions-id 12, Förälder-id = 1) o Det presenteras som en oordnad lista (UL-taggen i HTML). En uppenbar brist i säkerhetstänkandet i denna applikation är att säkerhetskollen görs enbart i rendreringen av menyn. Kan användaren adressen till webbsidan finns inget som hindrar sidan att laddas. Den enklaste och bästa lösningen för detta vore att lägga en kontroll för att se till så att användaren har tillgång till funktionen. Behörighetskontrollen placeras lämpligtvis i administrationsverktygets basklass, vilket förenklar administration och förebygger duplicering av kod (mer om detta i kapitlet Gemensam basklass på sidan 33). Det går även att precisera så att enbart enstaka funktioner ur varje grupp visas, dvs. en användargrupp kan tilldelas olika underfunktioner. 3.5.3 Uppdatera texter När väl applikationen har lagrat en text i cachen så kommer den alltid att hämta texten från cachen. Att hämta data från cachen är något man eftersträvar då cachen är mycket snabbare att jobba mot än att gå via databasen. Ett problem uppstår dock på grund av denna funktion; när en administratör eller översättare ändrar i en text, så sparas innehållet enbart i databasen. Det värde som lagrats i cachen kommer inte att uppdateras. Detta är på grund av att administrationsverktyget och den publika webbplatsen är två skilda applikationer, som enbart har det gemensamt att de kommunicerar mot samma databas. Den publika webbplatsen har därför ingen vetskap om att en text har ändrats. För att lösa detta problem så infördes ett datum på texten. Datumet beskriver när texten senast blev uppdaterad eller skapad. Dessutom infördes en timer som sattes att klocka var 30:e minut. Till händelsen att timern klockade kopplades en funktion vars uppgift är att leta reda på alla texter vars datumstämpel var uppdaterad inom de senaste 30 minuterna. En nyckel som beskrev texten skapas, och denna nyckel används sedan för att plocka bort texten ur cachen. Nästa gång texten ska visas på webbplatsen så kommer applikationen i vanlig ordning först leta i cachen, sedan falla tillbaka och hämta upp den då uppdaterade texten ur databasen för att sedan spara den i cachen. I.Net-ramverket finns inbyggda säkerhetsprinciper för att minska riskerna för webbplatsen. En av de principerna är att man i grundutförandet ej får mata in htmlkoder i textformulär som postas till webbservern. Detta är dock ett behov för texterna på webbplatsen. För att komma runt regeln måste man sätta följande instruktion i sidans definition: ValidateRequest="false" Med denna säger man till ramverket att inte validera innehåll som postas till servern. 26

27 Genomförande I och med att man lämnar sidan öppen för valfri inmatning mot databasen är det viktigt att man HTML-kodar den text som skall sparas. På det sättet försvarar man systemet som illasinnade användare som annars kan orsaka skada. Instruktionen för att säkra den inmatade texten ser ut såhär: string textvaluehtmlencoded = System.Web.HttpUtility.HtmlEncode(tbTextContent.Text); Där tbtextcontent.text är innehållet i textfältet där användaren matar in text. 3.5.4 Demonstration av administrationsverktyget I detta kapitel följer en demonstration av administrationsverktyget. Demonstrationen kommer att visa hur det går till när en text ska översättas. Det är titel-texten på demosidan som ska läggas till på det svenska språket. Som man kan se på bilden så skrivs text-koden för en text ut på webbsidan ifall systemet inte lyckades matcha en text till koden. I detta fall är det koden ##Title.FrontPage##. Det är en finess som gör det enkelt att hitta koder som behöver uppdateras med riktigt innehåll. Figur 3: Visar en skärmbild där en text ska översättas. Den engelska översättningen syns kort i den högra fliken under addressfältet. För att redigera/lägga till texten så loggar jag in i administrationsgränssnittet. Min användare har statusen Administratör vilket gör att jag får se alla menyalternativ i vänstermenyn. Förstasidan i administrationsverktyget visar en presentationbild där användaren välkomnas: Figur 4: Presentationsvy i administrationsverktyget. Eftersom texten redan finns inlagd på svenska ska vi enbart översätta texten till engelska. Översättningar sker på vyn Translate text ( Översätt text ). För att 27