KAMPHAVET

I ASP.NET finns en mängd färdiga kontroller för att hantera inloggning, men det tog sin rundliga tid att med massor av hjälp från Loopia support komma på hur de fungerade. I princip behöver man bara skapa en login-sida med dessa kontroller och ASP.NET ser till att man hamnar där om man klickar på en länk till en skyddad katalog. Men ASP.NET utgår från att man använder en MS SQL-databas för att lagra användaruppgifterna, och MS SQL har jag alltid skyggat från för att hela konceptet är svårbegripligt - inte alls så visuellt och lätthanterat som MS Access. MS SQL Server huserar på servern och kan inte installeras på ens egen dator utan att det kostar skjortan. För en något rimligare kostnad (ca 500 kr/år) kan man få en egen databas upplagd på servern hos Loopia. I teorin skall man med hjälp av en (gratis) applikation som heter MS SQL Management Studio kunna komma i kontakt med sin databas på servern och hantera den, men det enda besked man får från Management Studio är att databasen inte finns. Efter tjogvis med mail till supporten gav de upp - av något skäl kan min dator inte kontakta databasen. (Se förklaringen i inlägget ovan!)

Efter mycket trasslande fick jag ändå inloggningen att fungera lokalt - med en (ganska tafflig) applikation som ingår i Visual Web Designer Express (ASP.NET Configuration) kan man lägga upp användare och åtkomstregler för dem. Då skapas en MS SQL Express-databas i /App_Data på den egna datorn med användare och lösenord, och sedan går det att köra lokalt. Men... SQL Server lagrar inte data i det filformatet, och det går inte att bara ladda upp databasfilen som man gör med MS Access.

Man måste alltså att lagra sina användardata både lokalt i SQL Server Express (för att kunna provköra innan man laddar upp) och på servern i SQL Server. På den egna datorn hittar Login-funktionerna den lokala databasen utan problem, men det går som sagt inte att tala om för dem att hämta dem från servern - för den "finns ju inte". Åtkomstreglerna skrivs in i en särskild liten web.config-fil i var och en av de kataloger som skall skyddas, och de är bara att ladda upp. Däremot vägrade mina login-funktioner envist att erkänna att det fanns någon MS SQL-databas på servern. Till sist levererade supporten en "connection string" som skulle skrivas in i sajtens huvud-web.config - men absolut inte i den lokala huvud-web.config, då slutade det att fungera, för connection string säger ju att SQL Server-databasen ligger hos Loopia, och den finns ju inte enligt min dator!

Det blir alltså två huvud-web.config för varje sajt att hålla ordning på och inte blanda ihop. Eftersom MS SQL Management Studio inte kan kontakta server-databasen kunde jag inte lägga upp några användare, utan supporten fick skapa en administratörsanvändare åt mig. Så fick jag skriva en särskild administratörssida för att skapa användare och lösenord (kontroller för det finns i ASP.NET - egentligen a piece of cake att implementera, även om somliga funktioner inte går att anpassa till hur jag vill att de skall se ut - vad jag kommit på hittills, vill säga.) Så fick jag komplettera alla de särskilda web.config-filerna så att folk som legalt loggat in på ett konto i den ena sajten inte skulle få se skyddade kataloger på den andra sajten - alla användare ligger i samma MS SQL Server-databas. Det gäller att ha tungan rätt i mun, men notationen är ganska rättfram: <deny users="användarnamn" /> respektive <allow users="annat användarnamn" /> .

ASP.NET innehåller som sagt en mängd kontroller för inloggningssystem. Den viktigaste är förstås <asp:login> som presenterar textrutor där man kan skriva in användarnamn och lösenord och klicka på en logga in-knapp. Sedan kollar kontrolen att namn och lösenord stämmer med databasen, och om de gör det så blir användaren inloggad tills han loggar ut eller lämnar sajten. Om användaren har <allow users="användarnamnet" /> i web.config-filen i den katalog han vill besöka så får han göra det, annars åker han tillbaka till login-sidan.

Andra användbara kontroller är t ex <asp:LoginView>, som visar om man är inloggad eller ej, <asp:LoginName>, som visar vilket användarnamn man är inloggad med och <asp:LoginStatus>, som visar en länk för att logga in eller ut, beroende på vilket tillstånd som är aktuellt. För administratörssidan finns <asp:CreateUserWizard>, som låter en skapa nya användare och lösenord, och <asp:ChangePassword>, som låter en ändra sitt eget lösenord. Det där sista är ett ännu olöst problem - för på mina sajter är det bara adminstratören som skall kunna ändra lösenord, t ex när ett nytt verksamhetsår börjar. Det problemet får jag ta tag i när det börjar lacka mot jul.

Har Du samma eller liknande problem med Din sajt så hör gärna av Dig med ett mail, jag hjälper gärna till med litet mer detaljerade råd.

• webbplatsen skrivas om från HTML och Perl till ASP.NET och C#
• ett konto öppnas hos Loopia
• webbplatsen laddas upp till det nya webbhotellet och provköras
• domännamnet överföras till Loopia
• namnservrarna ändras så att de pekade på Loopia-webbplatsen i stället för Crystone-webbplatsen

Det visade sig vara mer jobb än jag hade trott, men nu är den äntligen uppe och fungerar. För det första behövde jag skapa en databas med alla uppgifterna från Excel-filen; den var indelad i 26 flikar (en för varje socken) och jag behövde ju en enda tabell. Jag fick alltså kopiera in alla raderna (över 12000 st) i ett Excelark och lägga till en kolumn med sockennamnet. Jag behövde också en ny nyckelkolumn med unika radnummer, för från början fanns en nummerserie för varje socken. Detta var ju dock en smal sak med Excels autofyll.

Så behövde jag lägga själva länkarna ensamma i en kolumn, och det var svårare, för i Excel ligger de gömda i varje cell som har en länk och kan bara kopieras en och en. Jag hittade ingen funktion i Excel som kunde extrahera själva länken och spara den i en annan kolumn, men efter mycket grubbel kom jag på att jag kunde exportera Excelarket till html-format, läsa in den i Excel igen som text och sedan var det "bara" att rensa bort alla rader som inte behövdes. Det blev omkring 80000 rader html-kod, varav jag bara behövde bara 24000. Det tog en stund, om man säger så, men genom att sortera dem kunde jag radera jättelika sjok med rader som innehöll allt möjligt html-skräp som jag inte var intresserad av. Radnumren hamnade t ex på en egen rad och måste kopieras snett nedåt för att hamna på samma rad som länken. Men just sådant är Excel suveränt till.

Sedan kunde jag klippa in kolumnerna med de frilagda länkarna och deras nummer i det ursprungliga bladet, och kontrollera att rätt rad fått rätt länk. Jag kunde enkelt kolla detta genom att skriva en funktion "om ursprungligt radnummer är skilt från länkens radnummer skriv "FEL" annars ingenting" till varje rad. Trivialt i Excel.

Sedan hade jag tänkt att det skulle bli "a walk in the park" att importera den nya Excelfilen till MS Access, skriva en urvalsfråga och svänga ihop ett par aspx-sidor för att söka och presentera resultatet. Det första jag upptäckte var att Loopia-servern inte kan hantera Access 2010-databaser och fick konvertera den till Access 2003. Så behövde jag en dropplist med de socknar som finns och en annan som visar de platser som finns i respektive socken. Där visade det sig att Lantmäteriets hemsida, där Sven-Olov hämtat datat, inte är särkilt väl normaliserad - på en del ställen stod det inte platsnamn utan långa haranger om "uppmätning av tomtgränsen mellan herrarna X och Y...". Jag fick syssla en hel del med att ändra platsnamnen till mer konsekventa och kortfattade texter.

Till sist såg det ändå skapligt ut, och jag kunde göra en ny html-sida på släktforskarföreningens webbplats där jag lade in en iframe som länkade till aspx-sidorna på Kamphavet. Och det fungerar!

En liten sak fattas bara, jag skulle vilja ha med alternativet "Alla platser" när man valt en socken. Det bör gå hyggligt lätt, men jag åker nog på att skriva litet C#-kod som byter ut söksträngen till databasen när man väljer "platsen" Alla.

Vill Du titta på hur det blev så klicka här, välj "Forskarhjälp", leta upp "Register över skannade lantmäterihandlingar för Norrtälje kommun" och klicka på knappen bredvid. Eftersom jag inte kan använda Master pages på Unix-servern utan måste ligga kvar i uråldriga "frames" kan jag inte ge en länk direkt till registret, för då tappar man headern, menyn och footern. Ett gott exempel på varför master pages är en bättre lösning än frames!

Som jag tidigare berättat är den skriven i någon tidig version av html och full av JavaScript och perl-kod. Not my cup of tea, alltså.

Men något måste göras, strukturen är obeskrivligt snårig (den har helt enkelt kommit till efter hand - en lång rad av webmasters har lagt in nytt innehåll utan att fundera över struktur) och det är så många formella fel i koden att man inte ser de allvarliga felen bland de hundratals oviktiga. Färgsättningen är förfärlig, illgrönt och knallila och jag vet inte vad. Hundratals font- och center-taggar som säger samma sak som de som redan gäller. Fritt svävande cell-taggar (td) i tabellerna - ett under att sidorna ser så pass skapliga ut som de gör.

Det finns också flera register som flitiga mäniskor skrivit av från kyrkböckerna. De är lagrade som semikolonavgränsade textfiler, sökningen och presentationen görs med perl-kod. Hela sajten ligger naturligtvis på en unix-server, så jag kan inte använda ASP.NET med dess bekväma databaskopplingar.

Först tänkte jag skriva om hela sajten till ASP.NET på en subdomän till kamphavet.se, byta servermiljö på släktforskarsajten och sedan skyffla över en fix och färdig sajt till Crystone, där den nuvarande ligger. Det kräver dock väldigt mycket arbete just att göra om alla registren till riktiga databaser och under tiden måste ju släktforskarsajten hållas uppdaterad. Jag släppte den idén.

Nu satsar jag i stället på att skapa en parallellsajt på Crystone-servern med en vettig struktur, där jag undan för undan kopierar över sidorna när jag har städat upp dem. När den fungerar kan jag visa den för styrelsen och diskutera menystruktur, layout, färgsättning mm. Naturligtvis lägger jag så mycket jag kan i en stilmall, så att det blir enkelt att ändra i efterhand.

Ett av problemen är att sökvägarna till registren ligger som hårdkodade serveradresser i perl-koden; ändrar jag dem så måste jag ändra dem igen när jag sjösätter den nya sajten - strul är oundvikligt! Därför får de många mapparna med registrens textfiler ligga kvar där de ligger, direkt under roten, tills jag gjort om registren helt och hållet. Kanske kan jag lägga dem på kamphavet tillfälligt och länka dit tills Crystone-servern bytt miljö? Iframes?

Utan ASP.NET får jag hålla mig till frames och vanlig html - det leder till en del dumheter, som att folk kan googla upp enstaka sidor direkt och missa det övriga innehållet, så jag måste lägga en länk till startsidan på varenda sida (och ta bort dem igen när det hela är klart).

Ett annat problem är bildarkiven, som är gjorda automatiskt med en äldre version av Photoshop. I den version jag har finns bara brokiga och tramsigt animerade mallar med amerikansk dålig smak, som jag inte kan förmå mig att använda. Å andra sidan presenteras bilderna nu helt utan kommentarer - filnamnen är den enda ledning man får för att gissa vad bilderna föreställer - så det får nog skrivas ett antal "reportage" med bilder från respektive begivenhet i stället. Rätt mycket research att göra!

Du som läser detta och intressserar Dig är välkommen att titta på den nya sajten och komma med råd och synpunkter. Fast det tar nog ett par dagar innan jag laddar upp de första sidorna.

Principen är ju enkel - man lägger en delvis genomskinlig grafik i en div ovanpå div:en med kartan. Det är ju rätt lätt, grafik-div:en behöver bara ges position:relative och top:minus kartans höjd i pixels. Problemet är i stället att skapa de genomskinliga delarna av grafiken.

Jag känner bara till två grafikformat som kan hantera genomskinlighet: GIF och PNG. Med GIF kan man hantera figurer med total genomskinlighet, men inga finesser. I PNG (32-bitarsversionen) sägs att man kan ge varenda pixel ett genomskinlighetsvärde ... hmmm! Vad jag ville göra den här gången var att måla de delar av kartan som låg under havsytan vid en viss tidpunkt (men gärna halvgenomskinligt, så att man känner igen sig i kartan och delar av platsnamn mm inte blir helt dolda). De delar av kartan som låg över vattenytan även på den tiden skulle förstås visas utan någon övermålning. Om man kunde måla vissa delar av grafiken i "helt genomskinlig färg" och det övriga i "delvis genomskinlig färg" skulle det rimligtvis bli så snyggt!

Jag använder PAINT.NET som grafisk editor, den kan mängder av konster som jag bara förstår hälften av. Menyerna antyder att det bara är att välja en färg och tala om vilken grad av genomskinlighet den skall ha, men av någon anledning händer ingenting när jag "målar" med genomskinlig färg. Det är något jag inte begriper här.

Efter många dagars trixande med PowerPoint (som har den bästa funktionen för att rita kurvor och polygoner - jag behövde det för att lägga in strandlinjerna i kartan) kunde jag exportera PowerPoint-bilderna till PNG-filer, men när jag sedan skulle måla dem genomskinliga i PAINT.NET funkade det inte, hur jag än försökte.

Till sist fick jag kasta in handduken, men hittade i stället en funktion för att sätta genomskinlighetsgraden för hela bilden. Resultatet blev "så där" - det syns att vissa områden blir mörkare (där grafiken är knallblå!), men även de delar av kartan som skulle synas oförändrade är förstås litet mörkare. Det här hade gått att hantera i GIF!

Jag tillämpade då "80-20-regeln" (80 % av resultatet kräver 20 % av arbetet, de resterande 20 % av resultatet kräver 80 % av arbetet) och publicerade den nya sidan i dag - någon dag kanske någon kan tipsa mig om hur man målar genomskinligt i PNG!

Kan Du det så hör av Dig! Vill Du titta på resultatet så gå till Rösajten/Förhistoria/Strandlinjeförskjutning

På Lantmäteriets webplats kan man bland annat köpa digitala kartor över ett område man väljer själv. Där finns bland annat rasterversioner av de moderna kartserierna, dvs. Sverigekartan, Översiktskartan, Fjällkartan, Vägkartan, Terrängkartan, Fastighetskartan och Tätortskartan. Jag valde terrängkartan i skala 1:50000 och 5 m upplösning och jpg-format; ett kartutsnitt på 13 x 13,4 km (2600 x 2680 pixels) kostade 433,50; inte oöverkomligt. Tar man upp kartan direkt på skärmen ser man förstås bara en del av den, så innan jag kunde använda den på websidorna fick jag beskära den och minska upplösningen till 1000 x 1300 pixels. Tyvärr kräver även det att man skrollar, men hade jag minskat upplösningen ännu mer hade det inte blivit mycket kvar av kartbilden. (Med ursprungliga 5 m per pixel är kartan fantastiskt klar och tydlig!)

Det finns emellertid ett aber med att använda dessa fina kartor på websidor: Lantmäteriet vill ha en licensavgift för varje websida som innehåller kartinformation. Försäljningen sköts av Metria, som har en förvirrande sida med användningsvillkor som är mycket förmånligare än de som verkligen gäller. Jag tyckte det var "too good to be true" och frågade, vilket kanske var dumt, och mycket riktigt gäller Metrias villkor inte för de här kartorna. Lantmäteriet vill ha 450 kronor för varje websida, och dessutom 500 kr i startavgift, så det kan inte bli särskilt många sidor med kartbakgrund. Lantmäteriets historiska kartor (t ex Häradsekonomiska kartan, Ekonomiska kartan och alla kartorna i Lantmäteriarkiven), är däremot gratis att använda enligt ett mail jag fick för något år sedan när jag frågade vad det kostade.

Jag använder kartorna t ex för att visa var bortglömda platser låg - jag lägger kartan som bakgrund i en PowerPoint-fil och ritar in symboler och texter ovanpå kartan. Sedan sparar jag PowerPoint-bilden som en jpg-fil och lägger in den i min websida. Jag föredrar det sättet framför att rita direkt i den ursprungliga jpg-filen, på det här sättet kan jag flytta symboler och texter utan att göra om allt från början.

Jag lägger också in en länkkarta i websidan, så att jag kan visa en text när man håller cursorn över en symbol och länka till en annan websida med mer fyllig information när man klickar på symbolen. I gamla Dreamweaver var detta väldigt bekvämt, man lade in sina hotspots direkt i en WYSIWYG-bild av sidan, men i Visual Web Developer är det inte lika lätt. I ASP NET finns en tagg som heter asp:ImageMap; man anger vilken bild den skall överlagras på och sedan fyller man på med en undertagg för varje hotspot, t ex asp:CircleHotSpot, där man får ange koordinater, radie, länkadress och Alt-text.

När man skall ta ut koordinaterna för varje hotspot tar man upp jpg-bilden i en editor som visar var cursorn är i pixels; jag använder PAINT.NET, som man kan ladda ned gratis. Har man två skärmar blir det hyggligt bekvämt.

Som det nu blev är jag skapligt nöjd med resultatet; titta gärna på t ex sidan med glömda platser på Rösajten.

Ett par ändringar har jag fått göra: dels kom jag på att jag inte kunde byta namn på startsidan; många kanske sitter med den gamla länken "www.kamphavet.se/index.html" - som inte skulle fungera om jag bytte namn på startsidan till "Default.aspx."

Den ändringen medförde ett antal konsekvensändringar i menyerna och länkarna, men inget stort.

Dessutom visar det sig att vissa andra webläsare inte tycker om QuickTime, plugin:en som spelar upp näktergalskvittret på startsidan. Internet Exporer och Opera kör den (fast under protest från Web Developer), Firefox vanställer den, och Google Chrome vägrar tvärt. Kan inte hjälpas; det är ju inte det viktigaste innehållet på Kamphavet.

Nu skall jag låta det rulla ett tag och se om jag snubblar över några fler konstigheter. Vad värre är, så ser jag nu att Rösajten, som jag mödosamt skrev om förra hösten, har "förbättringspotential". Idiotiskt att låta menyerna försvinna ovanför överkanten när man skrollar ned i ett långt dokument - vi får se när jag får tid och lust att göra någonting åt detta.

Den viktigaste vinsten med det är att när sidorna laddas tar de med sig all gemensam information från en "Master Page", där man kan lägga vinjetten, menyerna och allt som skall se likadant ut på alla sidor. I en html-applikation med frames MÅSTE man alltid gå in via frame-sidan för att se det gemensamma innehållet - hittar någon en intressant sida via en sökmotor måste de gissa frame-sidans namn om de vill se något mer av webplatsen, för menyerna och länkarna i frame-sidan kommer inte med!

Dessutom tillhandahåller ASP.NET en massa bra funktioner för databaskoppling och annat som antagligen är oändligt bökigt att lösa i ren html.

Störst bekymmer har hanteringen av släktdatabaserna varit. De består ju av tusentals sinsemellan hoplänkade html-sidor som genereras automatiskt av vårt släktforskningsprogram "Min Släkt" och det är naturligtvis helt omöjligt att skriva om dem en och en till ASP.NET; dels för att det skulle vara orimligt mycket arbete, dels för att det sedan inte skulle gå att uppdatera filerna automatiskt.

Länge funderade jag på att skapa en GEDCOM-parser som konverterade GEDCOM-exportfilen från MinSläkt till en Access-databas och sedan skriva ASP.NET-sidor för att visa informationen, men GEDCOM är så pass snårigt att jag lade den idén på hyllan och i stället valde att visa html-filerna som de är i en iframe i en ASP.NET-sida. Därmed får jag fördelarna med ASP.NET för navigering och hantering av gemensam information samtidigt som jag slipper jättejobbet med GEDCOM-parsern. Det verkar nu att fungera och ser skapligt snyggt ut.

Familjens fotoalbum (som ligger i en lösenordsskyddad katalog) var en annan utmaning. Jag ville ha en rullningsbar lista med miniatyrer till vänster och kunna klicka på dem för att visa bildsidan till höger, och dessutom kunna bläddra mellan sidorna med länkar som ligger i bildsidan. Det fungerar inte helt som jag ville, bland annat laddas miniatyrlistan om varje gång man byter sida, så att man får rulla ned från start varje gång. Ett annat problem är att funktionen som öppnar bildvisningssidan gör det på huvudskärmen, inte sidoskärmen där jag har webläsaren - men det spelar ju inte så stor roll om man bara har en skärm. Om någon är intresserad av min lösning så hör av er så kan jag maila över koden.

Det vore ett mirakel om jag fått alla länkar och annat rätt på en gång och dessutom finns ett par skönhetsfläckar som jag skall jobba vidare med, men nu får det duga för sjösättning.

Den gamla bloggen var en enda lång html-sida, med länkar till andra html-sidor som innehöll bilderna. Varje gång vi lade till ett inlägg måste vi göra en en miniatyrbild med länk till bildsidan, skapa en ny bildsida, ändra innehållsförteckningen på bloggen, köra website-generatorn för att sökmotorerna skulle hitta den nya sidan, ändra datum för senaste uppdatering och kanske skriva ett inlägg på Nyhetssidan. Ganska jobbigt med andra ord. Allt det där går ju automatiskt i en riktig blogg och dessutom kan besökarna kommentera det de läser.

Inte minst det sista tyckte vi var en stor brist på den gamla bloggen och började i början av januari fundera på att byta till en riktig blogg. Det finns gott om gratis programvara att hämta på nätet, problemet var snarare att välja vilken vi skulle satsa på. Först försökte jag med WordPress, som kanske är det mest spridda och populära bloggsystemet. Det är skrivet i php, ett annat skriptspråk än det jag använder till våra hemsidor (ASP.NET). Om php kan jag fortfarande ingenting och har inte heller lust att lägga ned månader på att lära mig ett språk till. WordPress berömmer sig av att vara lätt att modifiera (vilket system gör inte det?), men det är ett påstående man bör ta med en matsked salt.

WordPress-sidornas utseende styrs av ett tema, som består av ett tjugotal php-filer och en handfull bildfiler. Vad de olika filerna gör kan man nödtorftigt räkna ut av filnamnet, men där slutar min förståelse. Det finns massor av teman att ladda ned från nätet, men man vill ju ha en egen stil på bloggen, så jag försökte länge att få det enklaste standardtemat att bara visa en av våra bilder i stället för den tråkiga enfärgade vinjett det har från början. Det finns en redigeringsfunktion för teman i WordPress, men hur jag bar mig åt gick det inte att byta namn på bakgrundsfilen; jag fick döpa om min bild till samma namn som standardbakgrunden och ladda upp bilden separat.

Nästa problem var språket. Alla texter och meddelanden i WordPress är på engelska. Det finns en bekväm funktion där man kan skriva in översättningar för varje text som förekommer i WordPress; färdiga översättningsfiler finns att hämta på nätet - men: standardtemats texter finns inte med i den svenska översättningsfilen, så resultaten blev en sällsam röra av svenska och engelska texter.

I det läget tröttnade jag på WordPress och försökte med att annat system, Joomla! Där var det lättare att få till det och jag trodde jag var i mål. Utan att traggla mig igenom den ganska oordnade dokumentationen flyttade jag entusiastiskt in alla de gamla blogginläggen i Joomla - det tog en vecka. Så skulle jag skriva en förklaring om hur man kommenterade inläggen och upptäckte först då att Joomla inte har någon kommentarfunktion! Ridå!

Nu var jag riktigt trött på allt vad "färdiga" bloggsystem heter och kände mig för med en alldeles egen lösning i "gamla trygga" ASP.NET. Det gick ganska fort att skapa en Access-databas och ASP.NET-sidor som visade inlägg och bilder på ett sätt som var ganska likt den gamla Kamphavsbloggen, fast mycket lättare att underhålla. Nu återstod bara att skapa en kommentarfunktion. Jag ville ju inte att någon skulle kunna ändra våra inlägg, utan bara skriva in sina kommentarer och det fordrade någon sorts identifiering av användarna, så att mitt system visste om det var vi själva eller någon annan som satt vid datorn. Där körde jag fast. ASP.NET har funktioner för inloggning och användarhantering, men de använder sig av Microsofts egen databashanterare och den understöds inte av vårt webhotell! Där kroknade jag ... att ge mig på användarhantering, kryptering av lösenord och tusen andra saker som behövs var bara allt för mycket! Tillbaka till WordPress med svansen mellan benen.

Jag måste först få ordning på den förfärliga svengelskan i WordPress. Det visade sig inte gå att lägga till nya rader i översättningsfilen - programmet heter Poedit, förresten. För övrigt upptäckte jag att temat i alla fall inte bryr sig om översättningsfilen, så då var det bara att ändra texterna i alla temafilerna för hand - puh.

Kommen så långt började jag skriva in de sista fyra inläggen från Kamphavsbloggen i WordPress. Bilderna var på tok för stora, jag hittade ingen funktion i WordPress för att få dem automatiskt reducerade, och gjorde om dem till 640x480 pixlar. Sedan såg det hyggligt ut på min dator, så jag ändrade alla de 198 bilderna till 640 pixlars bredd. Det tog en stund.

När jag stolt bad Ann Britt att titta på den nya bloggen var alla bilderna hoptryckta i sidled! Vad??? Hon använder ju samma webläsare som jag!!! Så kollade jag alla andra webläsare jag har och de visade samma fel allihop. Varför såg det rätt ut i min? Jo, till sist kom jag på det: jag hade kört min Internet Explorer 8 i "kompatibilitetsläge" - dvs den gör på konstgjord väg samma fel som föregångaren Internet Explorer 7! När jag slog av kompatibilitetsläget såg det lika illa ut hos mig.

Nu måste jag söka hjälp på WordPress svenska forum. Jag hade varit där förut och upplevt att det var som att ropa i öknen - oftast var jag ensam inloggad. Som i alla forum finns det tusentals frågor och svar, men hur man letar hittar man inget som passar på mitt problem. Till sist svarade i alla fall någon, och efter en stunds diskuterande kom han med det avgörande tipset: bilderna måste skalas ned manuellt! Dvs. antagligen behöver man inte det, men jag har inte kommit på hur man skall göra i stället. Nu löste det mitt problem, så det andra kan vänta.

Därmed var det klart för sjösättning, som skedde när jag ändrade länkarna från Kamphavet och Rösajten till den nya bloggen. Nu är det bara resten kvar.

Den bygger på att de s k alt-texterna visas automatiskt när man för pekaren över en komponent som har en alt-text. Egentligen är den till för att presentera namnet på en bild om den av någon anledning inte kan visas normalt. Man kan också lägga in osynliga ytor med länkar ovanpå en bild, s k hotspots, och det är det jag utnyttjar för namnvisningen. Jag definierar hotspots för varje ansikte i en bild och sätter dess alt-text till det namn jag vill visa.

Det var ingen konst när jag jobbade i html, då skriver man bara in koordinater och storlek för sina hotspots i en image map på varje sida. I den lösning jag valde för den nya Rösajten är det bara en enda ASP.NET-sida, och innehållet hämtas från en databas. Koordinater och namn ligger nu också i databasen, hämtas till sidan när den skall visas och skrivs in i en image map innan servern skickar ned den till klienten som html-kod.

Det finns tyvärr inget riktigt praktiskt sätt att ta ut koordinaterna till hotspots i Visual Web Developer. I DreamWeaver kunde man rita in dem i bilden och koordinaterna sparades automatiskt, men i VWD måste man skriva in dem som siffror. Jag gör så att jag öppnar bilden i Paint, där pekarens koordinater hela tiden visas i nederkanten. Om jag har databasen öppen samtidigt kan jag skriva in koordinaterna direkt - men det är tur att jag kostat på mig två skärmar till datorn så jag inte behöver växla mellan databasen och Paint på samma skärm.

I stället fick jag acceptera att jag inte kan använda den inbyggda menyn i ASP.NET utan måste skriva en egen, vilket ju bär emot en del när det finns en snygg many inbyggd. De flesta andra menyer bygger på Javascript, men nu är det ju så att användaren kan stänga av javascript i sin webläsare och därmed stänga av en javascriptmeny. (Javascript kan ju användas för att skriva skadliga program).

Jag valde i stället att göra en meny som bara utnyttjar html-listor och stilmallar. I en stilmall kan man styra vilka delar av menyn som skall visas och ändra utseende på menyns olika delar när man för pekaren över dem.

Jag startade förstås en tråd på ASP-sidans forum när jag började grubbla över stilmallsbaserade menyer - utan alla nyttiga tips jag fick där hade jag nog grubblat mig tokig över den ganska svårbegripliga koden i stilmallen. Om någon är intresserad av min lösning så skicka ett mail!

Jag bestämde mig också för att gå över till Internet Explorer 8 som huvudwebläsare för Rösajten, för om det fungerar i IE8 så fungerar det för det mesta i alla andra moderna webläsare. Sedan var det bara ett IE7-problem, för den gör inte som de andra. Nu kan man lägga till en extra stilmall som bara läses in om sidan hämtas till IE7, så slutresultatet blev att sajten nu fungerar OK i IE8, IE7, Safari, Chrome, Firefox och Opera - över 90 % av alla användare kör någon av dessa.

Den enda hyggligt vanliga läsare som återstår är IE6, den 8 år gamla läsaren som släpptes tillsammans med Windows XP. IE6 har inte stöd för "hover" annat än för vanliga länkar, och därför går det inte att använda stilmallsbaserade menyer i IE6. Det kan vara möjligt att lägga till javascript till min meny för att den skall fungera i IE6, men det jobbet (bl a att lära mig javascript) får vänta - det finns faktiskt inget skäl att inte uppgradera IE6, så jag lade in en länk till Microsoft Download i "About"- sidan.

Det visade sig att Microsofts serverprogram skapar felaktig kod när det skickar ned html-koden för en asp-meny. IE7 märker inte detta, men i IE8 har man rättat felaktigheten utan att rätta serverprogrammet!

Lösningen var ett obetydligt tillägg i .css-filen och menyn som säger till IE8 att lägga menyerna ovanpå allting annat.
Problemet med Safari visade sig mer invecklat, men jag jobbar med det.

Förutom att detta tar en del plats på servern så kan man naturligtvis inte skriva om nästan 9000 filer för hand till asp.net så att man kan använda en Master Page, utan tvingas leva kvar i frames med de nackdelar det har.

Dessutom har vi inte hittat något sätt att ta reda på vilka filer som behöver uppdateras när man ändrat något i MinSläkt. (De genererade html- filerna får namn som är långa siffersträngar där det inte går att se vilken person de berör utan att öppna dem). När man gjort den minsta ändring i sin släktforskning måste man därför ladda upp alla filerna igen för att vara säker på att allt blir rätt.

Nu är det ju inte särskilt smart att skapa flera sidor för varje post i något som egentligen bara är en databas. Anledningen till att jag började arbeta i asp.net var just att man då smidigt kan hämta innehållet i en sida från en databas (så hanteras platser, personer, blommor och alla möjliga saker på Rösajten). Man behöver bara en enda asp.net-sida för att visa alla poster man har i sin databas; 8997 filer kan slopas - förutom asp.net-sidan behövs en sida med kod och förstås själva databasen.

När man gjort en ändring behöver man bara ladda upp databasfilen - vilken förenkling! Jag har börjat peta i detta för att på sikt försöka ersätta de tusentals html-filerna med en smidig asp.net-applikation.

Nu är det tyvärr så, att databasen i MinSläkt inte går att komma åt utifrån; inte heller begriper asp.net att MinSläkt-filen är en databas. Innehållet i MinSläkt-filen måste alltså konverteras till en databas asp.net kan använda, men sedan kan man börja skriva asp.net-sidor för att visa sina personer och familjer.

MinSläkt kan inte bara exportera innehållet som html-sidor, programmet kan också spara hela innehållet i en textfil på ett format som kallas GEDCOM. GEDCOM är ett format som tagits fram av mormonkyrkan i USA - som bekant gör deras religion det ytterst angeläget att forska fram sina förfäder. Tack vare mormonerna är det mesta av de svenska kyrkoarkiven mikrofilmade, till stor glädje också för alla svenska släktforskare. GEDCOM-filer går att begripa, om man bara har nyckeln till de taggar som talar om vad varje rad handlar om, men det är trivialt - GEDCOM-standarden är bara att ladda ned från internet.

Vad som inte är helt trivialt är att GEDCOM bygger på en datamodell som inte direkt kan översättas till en relationsdatabasmodell av det slag alla moderna databaser bygger på. För att överföra MinSläkt-datat till en relationsdatabas måste jag alltså läsa GEDCOM-filen rad för rad, lista ut vilken tabell informationen skall läggas i och (vilket är knivigast) sätta upp relationerna mellan de olika posterna, så att barnen får rätt föräldrar och rätt personer är gifta med varandra t ex.

Vad jag har börjat med är därför att försöka bygga ett program inuti en Access-databas som kan läsa GEDCOM-filen och fylla på datat i de olika tabellerna. Tyvärr måste jag skriva programmet i Access Basic som är det enda Access förstår - snårigt och ovant för mig. Jag hade hellre arbetat med C# som i asp.net, och lärt mig det ordentligt i stället för två programspråk halvdant. Ett alternativ vore att byta databashanterare till SQL Server, som är gratis, modernare och kraftfullare än Access - men det är förstås ett jättejobb att lära sig en helt ny databashanterare. Rår jag inte på problemet med Access Basic kanske jag får tänka om.

Wish me luck!

Förr skötte man (och vi gör fortfarande det på Kamphavet och Setons the) det med framesets; den stora skillnaden är att ett frameset hämtar innehållet i de olika ramarna från andra filer, medan alla sidor i den modernare lösningen hämtar sin MasterPage och fyller den med innehåll. En nyttig konsekvens av detta är att om någon hämtar en sida direkt, utan att gå via hemsidan, får man med menyer och allt och kan surfa vidare inom sajten. Förr fick man aldrig se menyer och annat som låg i andra frames om man hittade en av våra sidor t ex via Google.

Så långt ser det ju bra ut!