Tittar man på historien av webbplatser för Medietekniksektionen på LiTH ser man ett tydligt mönster:
- Vartannat år slänger man ut föregående webbplats och bygger nytt från scratch och webbplatsen hinner inte riktigt bli klar.
- Året därefter blir det stiltje och inte mycket händer.
- GOTO 1
Detta läsår är man på punkt 1. Man har gjort en webbplats med ganska modernt utseende som kanske frångår den grafiska profilen ytterligare lite och använder en signalfärg som orange allt för flitigt (t.ex. är varannan rad i tabellen över inlägg i forumen i orange) men det kan man ju stå ut med. Värre är att man gjort sig beroende av Ajax för vissa delar, bl.a. för forumet. Det går inte att läsa innehållet i forumet utan att ha stöd för Ajax i webbläsaren. Besöker man forumet utan stöd så får man se:
Laddar trådar
och inget mer händer.
När man använder sig av Ajax bör man vara medveten om vad som händer i webbläsare utan stöd för det, antingen för att man inte har en tillräckligt modern webbläsare eller har ECMAScript avstängt av någon anledning. Ofta är det ingen större svårighet att erbjuda webbsidor som fungerar även för dessa webbläsare men där Ajax ändå ger visst mervärde.
Inte heller har man fixat webbkanaler för nyheter och foruminlägg, vilket var något av det första jag lade till när jag var inblandad i den tidigare versionen av webbplatsen. Men här kan man faktiskt utnyttja det faktum att man använder sig av Ajax här. Man kan hämta inläggen i ett av forumen med en enkel POST-fråga (ja, de använder sig av POST när det bör vara GET här, ofta brukar det vara tvärtom).
Med datat hämtat med POST kan man transformera till ett Atom-flöde med 40 rader XSLT. Tyvärr blir det lite krångligare än nödvändigt:
- datan som skickas är inte giltig XML. Teckenkodningsinformation saknas och det som skickas är gammaldags HTML där enkla element (br) skrivs utan avslutande snedstreck. Webbsidan som visar forumet är angett att vara i XHTML Strict, frågan är då om man verkligen ska infoga data som inte validerar. (I och för sig validerar inte sidan i sig heller.)
- man har inte skiljt på innehåll och presentation utan skickar HTML-kod med innehåll och presentation blandat. Detta borde de för sin egen skull låtit bli, vill man i ett senare skede använda samma data i två olika grafiska skepnader är det bättre att skicka ren data (i form av XML eller JSON) över kanalen och först i webbläsaren applicera formatering.
- URL-er som skickar verkar ha ett konstigt beroende av referrern vid anropet. Saknas det skickas felaktiga URL-er ut.
Detta gör att man måste lägga till teckenkodningsinformation, konvertera br-taggarna till att bli korrekt XML och sedan ägna en hel del kraft åt att plocka ut delar av strängar. Viss information tappar man helt, som klockslag som saknas men det får man ta.