Hem

KAMPHAVET

Ann Britt och Björn Bergströms hemsida

Aktuellt
Ann Britts släktforskning uppdaterad
Webplatsen har hittills besökts gånger
Senaste uppdatering 2017-01-26

Diverse - Programmerarbloggen

Inloggning
Du är utloggad
Logga in

Björns programmerarblogg

Här berättas om mina vedermödor under webutvecklingsarbetet. För närvarande är det Kamphavet, Rö socken och Norrtälje Släktforskarförening jag arbetar med. De är skrivna i ASP.NET och C#. Många av sidorna använder sig av Accessdatabaser för att lagra sina data, därigenom behöver jag bara skriva en enda sida i stället för tusentals när det enda som skiljer dem är de data som presenteras.

Jag är totalt självlärd som webutvecklare, har köpt en enda bok om ämnet (som är helt inaktuell nu i alla fall), men har lärt mig massor på bara några år genom att leta information på Internet. Det finns två webplatser som är överlägset bäst enligt mitt förmenande: w3schools.com och aspsidan.se.

  • w3schools finns både komplett referensinformation om html, JavaScript, css och all möjligt annat; men också online-kurser i webutveckling.

  • Asp-sidan innehåller inte bara information om programmering i ASP och ASP.NET, utan också mycket annat. Den mest förträffliga delen av Asp-sidan är deras forum, där jag fått hjälp med otaliga små och stora problem.

    Tyvärr verkar något ha hänt med denna förträffliga sajt - surfar man till adressen så hamnar man på något som kallas old.aspsidan.se. Det antyder ju att det finns en ny ASP-sida någonstans, men den har jag inte kunnat hitta. Däremot görs det fortfarande inlägg i forumet, så det verkar fortfarande fungera.

Med tiden kanske det blir mer allmän information här, men här kommer själva bloggen.

2015-06-19 En tid fungerade inte inloggningen för medlemmar på Rösajten. Medan Etanet var vår ISP var port 1433 blockerad, så det gick inte att accessa databasen med SQL Server Management Studio. När Telia tog över som ISP 27 maj började det dock fungera och jag kunde se att loginsystemet spärrat användare som loggade in som medlemmar för att någon försökt med fel lösenord för många gånger. Det där är ett ofrånkomligt problem när alla medlemmar har samma inloggningsuppgifter - om någon klantar sig för många gånger spärras alla medlemmar. Men nu vet jag i alla fall hur jag skall göra om det händer igen: ta bort användaren i databasen (på 2 ställen!) och lägg dit den igen!
2015-05-08 I dag ringde Etanets "second line support" (de som vet litet mer än dem man kan ringa till) och talade om att Etanet blockerat port 1433, den som man kommunicerar med MS SQL Server genom. Varför visste de inte och de kunde inte heller göra någonting åt saken, men i slutet av maj skall Telia ta över Etanets nätverk, så man kan ju alltid hoppas att problemet försvinner då. Tänk så mycket jobb vi hade sparat, både jag och Loopia, om jag fått det beskedet första gången jag ringde Etanet!
2015-05-06 Efter ett par frustrerande månader har jag fått stil på inloggningssystemet till Rösajten och Kamphavet. På båda sajterna finns kataloger som inte alla skall kunna komma åt, t ex medlemssidorna på Rösajten, och hittills har webbhotellet Loopia tilhandahållit en bekväm lösning där man kunde sätta lösenordsskydd på dem. Men nu skall de byta server, och då tar de bort det gamla systemet. Det gällde alltså att implementera ett nytt inloggningssystem som inte är beroende av Loopias gamla system.

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.

2014-09-02 Några dagar har jag besvärats av ett märkligt fel på Rösajten: om man bara skrev in grund-URL:en (dvs. http://www.rosocken.se/) så fick man upp en gammal startsida. Om man däremot skrev ut hela URL:en till startsidan (http://www.rosocken.se/Default.aspx) så blev det rätt. Tyvärr tittade jag inte efter vad den sidan jag fick upp hette, då hade jag nog begripit fortare. Det visade sig nämligen att förutom Default.aspx fanns en sida som hette index.html i rotkatalogen - hur i allsin dar jag lyckats skapa och ladda upp den har jag ingen aning om, den fanns inte på min lokala sajtkopia där jag lagrar alla nya filer innan jag laddar upp dem - ett mysterium. Att jag fick upp index.html i stället för Default.aspx beror på att servern har en strikt ordning för att söka igenom en grund-URL efter en startsida, och index.vadsomhelst kommer före default.vadsomhelst. Nu är problemet emellertid löst, jag behövde bara radera index.html på servern.
2013-09-15 Den 21/8 fick jag OK från NSFF:s styrelse att flytta deras webbplats till en server hos Loopia. Det var väl ingen som betvivlade mina argument, men det skulle ju ändå fattas ett formellt beslut. För att göra flytten krävdes ett antal åtgärder:
  • 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
Mycket var ju gjort genom att registren skrivits om till ASP.NET och redan låg på vår egen webbplats, men de måste kompletteras med en Master Page med allt gemensamt innehåll som menyer o dyl. Det gjorde jag genom att skapa nya, tomma sidor länkade till mastern och sedan klippa in koden från respektive sida - mycket säkrare än att peta i varje sidas kod och försöka få allt rätt.
Så behövde jag skriva om alla html-sidor på Crystone-servern till ASP.NET - det var inte så många, och var mest att klippa och klistra. Det jobbet var i stort sett klart redan när beslutet togs.
Att öppna ett konto hos Loopia och ladda upp filerna var förstås inget problem, men när jag skulle börja provköra skar det sig direkt! När man försökte söka i någon av databaserna fick man en av de värsta felsidorna med oceaner av obegriplig information. Efter mycket frustration fick jag reda på att Loopia lagt sajten på en server som saknade stöd för MS Access! När de väl begripit att jag MÅSTE ha Access tog det bara en halvtimme innan saken var ordnad. Efter ett par dagars provkörning kände jag mig mogen att dra igång den nya sajten och begärde en transferkod från Crystone. Den kom snabbt via mail, och på Loopias kontrollpanel väljer man "lägga till domännamn" och anger transferkoden. Sen tog det ett par dagar innan den svenska domännamnsadministrationen "punktSE" noterat att Loopia tagit över som "registrar" som det heter.
Nu återstod bara att peka om namnservrarna så att de visste att norrtelje-sff.se låg hos Loopia. Det gör man också på Loopias kontrollpanel under rubriken "Byt namnservrar": man bara skriver i ns1.loopia.se respektive ns2.loopia.se i stället för motsvarande på crystone.net. Men... efter en stund står det crystone.net där igen - uppgiften hämtas från en rotserver, och man har ingen aning om ens begäran fungerat eller om någonting pågår. I och för sig varnas för att det tar några timmar, men jag prövade gång på gång de närmaste dagarna och hamnade alltid på Crystone-sajten när jag skrev in www.norrtelje-sff.se i Internet Explorer. Efter en vecka frågade jag om något hänt, och då erbjöd man sig att göra bytet åt mig. Visst sade jag, och efter ett tag fungerade det. Undras allt om det där med att byta själv verkligen går!
Nu borde allt ha varit frid och fröjd, men när jag testade igen så kom den förfärliga felsidan tillbaka när jag testade de databasdrivna sidorna! Nära panik, nu hade jag ju annonserat till styrelsen att allt var klart, och de viktigaste sidorna på hela sajten fungerar inte! Efter en stund kom jag ihåg att det sett likadant ut när de lagt sajten på en server utan stöd för MS Access och ringde deras support - jo, visst den ligger på en server utan stöd för Access. Jamen VAFF...!!! som Berglins figurer utbrister. Tebax, tebax, sade jag, och det skulle de naturligtvis göra - fast hade jag inte själv begärt flytt till den här servern den 6 september? Otänkbart, sade jag, jag MÅSTE ju ha Access! Men i deras detaljerade loggar hittade de en notering att jag bytt "plattform" från ASP till ASP.NET; jo, jag hade ju upptäckt att webbsajten av någon anledning hade alternativet ASP inställt, och det kan ju inte vara rätt när hela sajten är skriven i ASP.NET? Men - att ett alternativ hette ASP.NET och ett ASP hade inget med saken att göra - alternativet ASP.NET betydde modernare server utan stöd för Access, och alternativet ASP betydde ASP och ASP.NET och Access, fast en äldre server. De borde nog fila litet på förklaringarna på den sidan, Loopia. Men på det hela taget var deras support beundransvärd: snabb, pedagogisk och effektiv.
Så nu snurrar det. Och en rättelse i personregistren tar mig 10 minuter i stället för att vara i princip omöjlig!
2013-07-19 Till sist blev jag ändå klar med alla släktforskarföreningens fem register. Konverteringen innehöll alla de problem jag mötte med Döda i Roslagen, och en hel del nya. Värst var det stora Vätöregistret (19500 poster). Ett exempel: ålder och födelsedatum stod i samma kolumn - åldern dessutom i ett antal olika format - t ex 26, 26å, 26 år. Epitet, namn och platser var inskrivna utan försök till normalisering, så det tog en del tid att ensa upp. Vätö är dessutom extra krångligt, för församlingen delades 1914 i Vätö och Björkö-Arholma - vad skulle man skriva i kolumnen "hemförsamling" för platserna efter 1914? Nå, till sist blev det klart - en applåd till den arbetgrupp som jobbade med Väddö fram till 2009, men till sist tvingades lägga ned projektet - normaliserat, logisk struktur, konsekvent formatering - det tog mig bara en eftermiddag att göra databas av de filerna. Nu har jag lagt ett förslag till styrelsen att lämna Unix-världens problem bakom oss och skriva om hela sajten till ASP.NET - jag lär få anledning att berätta om det äventyret!
2013-05-21 Efter två intensiva veckor med tidvis 12 timmar vid datorn om dagen kunde jag i dag ladda upp en ny version av NSFF:s Register över döda i Roslagen 1900-1949.
Registret var ett av de fem på NSFF:s webbplats som bygger på perl-skript som söker i en kommaseparerad textfil; omöjliga att flytta till en Windows-server, omöjliga att underhålla och dessutom klarar de inte svenska bokstäver i söksträngarna. Jag har länge irriterat mig på detta och försökt att lappa över problemet med de svenska bokstäverna, men när det trots detta inte fungerade insåg jag att det var dags att göra något radikalt.
Att konvertera en kommaseparerad textfil till en relationsdatabas är dock rätt jobbigt; man kan i och för sig lätt importera textfilen till Excel, men det är då man ser inkonsekvenserna och förvirringen i textfilen, som faktiskt bara är en avskrift av dödböckerna i församlingarna inom Norrtälje kommun. I bland har prästen satt kvinnors flicknamn tillsammans med efternamnet, i bland bland anmärkningarna. Folk som dog i en församling fast de var kyrkskrivna i en annan står alltsomoftast på två ställen i det gamla registret. Det var dessutom bokstavstroget avskrivet, så där fanns otaliga varianter av stavning.
Konverteringsarbetet handlar framför allt om att separera de data som skall vara sökbara från den ursprungliga texten. I många fall fanns kommatecken mellan efternamn och förnamn, och kvinnors flicknamn föregicks av "f.", men långt från konsekvent. Med hjälp av HITTA- och EXTEXT-funktionerna i Excel särade jag på efternamn, förnamn och tidigare namn, och behövde bara korrigera några tusen fält - hela databasen innehåller litet över 24000 poster.
Att parsa anmärkningsfältet, där epitet, namn, hemförsamling och allt möjligt stod, var extra jobbigt. Epitet skulle till epitetfältet, hemförsamling till hemförsamlingsfältet, och plats till platsfältet. Det blev många HITTA och EXTEXT, med olika målsträngar för HITTA - i bland var någon "i" en plats, ibland "från", i bland föregicks platsen bara av ett komma. Global substitutes som från "i" till "," är dessutom jätteriskabelt - man vet aldrig vad som händer och måste läsa igenom varenda post för att kolla att det blev som man tänkt sig - och det blev det i många fall inte!
Det värsta problemet - som var helt onödigt om jag fått ett tips från Jan Faith-Ell, som realiserade det gamla registret, litet tidigare. Det beror på att Excel anser att världen uppstod den 1 januari år 1900. Alla tidigare datum anser Excel vara en text, och alla data från dag 1 (1900-01-01) på ISO-datumformat konverterar Excel till ett datumnummer, fast det visas som ett ISO-datum. Och det är skvatt omöjligt att få Excel att betrakta sådana data som en text. Hur jag än gjorde när jag importerade Excel-filen till Access så blev alla datum efter 1900-01-01 i stället dagnummer. Jag lyckades till sist piska Access till lydnad genom en mängd omvägar och mödosamma konverteringar, men alldeles i onödan. Jans tips var helt enkelt att använda samma datumformat som i Sveriges Dödbok, där man slopar bindestrecken mellan år och månad och mellan månad och dag. Hokus pokus! Utan bindestrecken har Excel inga problem att hantera datumet som text!
En sista erfarenhet också: Det finns ju något som heter "Autofilter" i Excel. Högst praktiskt, man kan direkt sortera på valfri kolumn, välja vilka rader som skall presenteras etc. Fällan är, att om man lagt till en extra kolumn på slutet efter att man aktiverat autofilter så följer den inte med när man sorterar på en av de autofiltrerade kolumnerna! På det viset förlorade jag ungefär 500 kyrkboksreferenser till de rader där jag varit tvungen att kolla i källan vad det egentligen stod. Lägg aldrig till en kolumn på slutet! Lägg till den före den sista autofiltrerade kolumnen och flytta den sedan!
Nu har jag fyra register till att konvertera; tre är ganska måttligt stora, men det fjärde är ett monster, nästan dubbelt så stort som det här, som tog mig 95 timmar att göra.
2012-08-01 Att ta hand om gamla webbläsares fel är inte lätt. Nyligen slutade den särskilda .css-filen som skulle ta hand om felen i Internet Explorer 7 att fungera. Jag letade länge och väl efter en förklaring till att allting blev förvrängt i IE7, men till sist insåg jag att det inte är värt besväret att försöka skapa specialfunktioner som kompenserar för alla fel i IE7. Så nu är det slut, Kamphavet fungerar i fortsättningen bara i moderna webbläsare - IE 8 eller 9, Firefox, Chrome, Opera eller Safari.
2012-03-29 När Sven-Olov Gahnström efter mycket arbete skapat en Excelfil med länkar till alla historiska lantmäteriakter på Lantmäteriets webbplats som rör Norrtälje kommun laddade vi upp den till föreningens webbplats. Tyvärr visade det sig att den var så stor att det tog en evighet att ladda ned den. Jag beslöt då att testa min idé att lägga den som databas på Kamphavets Windows-server och länka dit från släktforskarföreningens webbplats.

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!

2012-02-06 Efter ett antal månaders jobb med släktforskarföreningens sajt kunde jag ladda upp den med nya designen den 18/1. Sidornas utseende är ensat och förenklat, fast de perl-drivna registren är kvar tills vidare - när jag får tid skall jag börja konvertera dem till databaser. Tanken är att lägga dem på Kamphavets Windows-server och länka dit från de övriga sidorna. Vi får se.
2011-10-17 Sommaren gick åt till att ge rosocken.se en rejäl ansiktslyftning i samband med att vi bildade Rö hembygdsförening, men nu har jag tagit tag i Norrtälje släktforskarförenings hemsida igen.

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.

2011-05-16 Jag har givit mig på den gamla utmaningen att skifta överlägg på en gemensam kartbakgrund. Skälet är förstås att Lantmäteriet tar så hutlöst betalt om man vill använda deras kartor på nätet.

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 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

2011-04-25 För en tid sedan blev jag "websideredaktör" för Norrtälje Släktforskarförening och fick ansvaret för en webplats som innehåller mängder av gamla html-sidor och perl-skript. Tar man upp en av dessa sidor i Visual Web Designer får man något hundratal felmeddelanden per sida, så det finns en del att göra. De flesta felen är lyckligtvis bara formella - t ex får man numera inte använda versaler i taggar, så med några "global substitute" kan man fixa tusentals fel på en gång. Värre är det med perl-skripten; jag har besvär nog med javaskript (som jag nalkas med stor nervositet, jag har nog inte riktigt förstått vad det är egentligen). Efter några veckors eftertanke har jag nog bestämt mig för att skriva om hela webplatsen till ASP.NET och C# - det blir antagligen betydligt mindre jobb än att sätta sig in i perl och i stället för att bli en dålig perl-programmerare kan jag bli en något bättre C#-programmerare.
2010-12-13 För ett tag sedan tog jag steget att köpa licenser för att använda moderna kartor i vissa av sidorna på Rösajten.

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.

2010-11-16 Nu är "Nya Kamphavet" uppladdat till servern och provkört ett tag.

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.

2010-11-15 Efter mycket arbete - som dock låg på is hela sommaren - har jag nu skrivit om Kamphavet till ASP.NET.

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.

2010-02-13 I dag fick jag till sist ordning på bildhanteringen i WordPress och kunde sjösätta den nya bloggen. Det har inte varit lätt, för att använda förnamnet.

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.

2009-12-13 Efter en del trasslande har jag nu fått namnvisningen att fungera i bildarkivet på Rösajten.

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.

2009-11-22 Efter fjorton dagars arbete är "Safari-problemet" löst. Besvären med Safari (och Googles webläsare Chrome) beror på att Microsofts ASP.NET- program inte känner igen att Safari och Chrome är moderna webläsare. Försöker de bara dj...as med konkurrenterna? På ASP-sidan fick jag ett förslag till lösning som skulle tvinga ASP.NET att hantera Safari och Chrome rätt, men av någon anledning fungerade inte det.

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.

2009-11-08 De dynamiska menyerna i den just sjösatta Rösajten fungerade inte i Internet Explorer 8 eller Safari och jag hade ingen aning om varför. Jag lade in en fråga i Asp-sidans forum och efter några timmar hade jag fått lösningen på IE8-problemet.

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.

2009-11-05 Ett av de stora problemen med Kamphavssajten är de genealogiska sidorna. Vi använder ett program som heter MinSläkt för släktforskningen; det är väldigt bra och lättarbetat, men när man vill publicera sina resultat på Internet så skapar det minst två html-sidor per person man har matat in. Totalt har vi hittills publicerat 8918 filer som MinSläkt genererat.

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!

2009-11-01 Den nya Rösajten sjösattes i dag. Det finns flera skäl till att jag ville dela på vår privata sajt Kamphavet och Rösajten. En är förstås att man skall komma direkt dit utan att behöva bläddra i Kamphavet. En annan är att den gamla lösningen med html och asp.net blandat gör det omöjligt att använda Master Pages till sajten. En Master Page är ett modernare sätt att ge alla sidor en gemensam layout och slippa skriva gemensamt innehåll på alla sidor.

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!