Det här är text nummer tre i serien om hur sandman.net blir till och ska handla om Atlas - verktyget jag själv skrivit om som tar hand om tekniken bakom siten så att säga. Men innan jag börjar tala om själva Atlas så skulle jag vilja skriva lite om historien bakom sandman.net's tekniska utveckling.
Bland det roligaste med det jag pysslar med är att bygga tekniken bakom det som man ser på sidorna. Det har inte alltid varit så dock, jag började i den här branschen som en renodlad grafiker och visste knappt hur man programmerade videon (jo, det gjorde jag!). Men efter hand insåg jag att om jag ville ha något gjort på mitt sätt så fick jag lov att göra det själv. Fram tills dess hade min hemsida bara varit helt statisk och rätt så trist.
Men jag började sakta titta på perl, eftersom det var det min programmerar-kollega använde sig utav. Jag frågade mycket och klurade själv på hur man skulle få perl att göra det man ville att det skulle göra. Inom kort hade jag byggt mitt första publiceringsverktyg! Det var ett formulär på min hemsida som bara jag kunde komma åt, var innehåll skickades till ett perl-script. Det scriptet hade jag skrivit helt själv och vad det gjorde var att ta all data från formuläret och skriva ned det i en fil på serverns hårddisk. Jag skrev dock ned hela filen på en rad, så jag seprarade alla fälten med texten "UTTERUTTER" (hade någon av er skrivit det i eran text i gästboken på den tiden hade det blivit väldigt tokigt). Så ett inlägg i gästboken kunde se ut så här:
"KentUTTERUTTERTjena!UTTERUTTERTjena Sandman! Hur är det?UTTERUTTERkid@kenta.nu"Och sen så hade jag ju ett annat perl-script som läste dessa filer och skrev ut dem på skärmen. Helt fantastiskt tyckte jag då!
Med tiden så fann jag MySQL och sedermera Roxen - vilket gjorde perl-script mindre nödvändiga. Dock är RXML, som Roxen använder sig av, en inte speciellt kraftfull programmeringsmiljö, och mina krav gjorde att den tog mer resurser för att utföra dem. Perl-script användes fortfarande till de mest krävande saker som lista texter och liknande.
Efter att ha varit ett stort Roxen-fan rätt så länge så insåg jag till slut att det inte fungerar i längden, så jag började snegla på Apache och PHP och inom kort hade jag en installation färdig att experimentera med på min server. Det jobbigaste med sådant är ju att lära om, förstås. Något man har lärt sig fungerar på ett visst sätt kan man helt plötsligt inte använda sig utav. Sen var jag ju givetvis hjälpt av att jag kunde perl, då PHP är väldigt likt.
Pluto
Aaaaah, gamla pluto. Dom stackarna använder det fortfarande.
Aaaaah, gamla pluto. Dom stackarna använder det fortfarande.
Pluto
Det är kanske värt att nämna att jag innan dess byggt ett helt innehållssystem för ICA Förlaget baserat på Roxen, så helt oanvändbart är det ju inte. Det systemet hette Pluto och hanterade det mesta som ett innehållssystem bör hantera. Nackdelen med Pluto var dock att jag inte tänkte igenom riktigt hur det skulle användas innan jag började bygga det, så det var väldigt bundet till hur vi jobbade på ICA Förlaget, och varje ny databas man ville hantera via Pluto krävde ett nytt interface som listade, införde nya poster och redigerade befintliga poster. Det blev till slut ett enda virrvarr av underliga och annorlunda lösningar för de olika behoven.Så det hela behövde byggas om - men jag tyckte att det var dumt att bygga ett nytt system specifik för ICA Förlaget, speciellt då jag misstänkte att jag kanske inte skulle bli kvar där alltför länge. Så jag började fundera och skissa på Atlas - ett innehållssystem som skulle vara flexibelt och utbyggbart och framförallt- modulbaserat!
Atlas
Atlas bygger på tre hörnstenar; Användare, Ursprung och Moduler som är sinsemellan länkade. Du kan till exempel ha en användare, Sandman, som har rättigheter till ursprunget 'sandman.net' som har modulerna Artiklar, Omröstningar och Medlemmar, men du kan ge Sandman specifika rättigheter för de olika modulerna. Detta betyder att du kan lägga upp nya moduler som är specifika för ett ursprung eller för en användare och så vidare. Det hela blir mycket abstrakt om man ågr in på det mer, eftersom man sedan kan sätta specifika rättigheter på en viss modul efter vissa regler som är lite svåra att förklara här, så jag låter bli.
Ett ursprung i det här fallet är en källa till innehåll egentligen. I ett företag så skulle ursprung kanske vara avdelningar, eller i ICA Förlagets fall så var ursprung tidningar och liknande produkter. ICA kuriren är ett ursprung till exempel. Sen är de anställda användare givetvis, som i sin tur måste ges rättigheter för att skriva en artikel på ICA kurirens hemsida.
Flexibilitet
Detta med rättigheter och användare är ju något som är fullständigt självklart att det ska finnas i ett sådant här system, så det är ju inget nytt. Men något som i alla fall jag tror är en aning unikt i Atlas är dess flexibiltet vad gäller databaser. Istället för som jag gjorde med Pluto, där varje ny "modul" krävde sitt eget interface, så har jag i atlas skrivit ett generellt "Databasbehandlings"-script (som egentligen är två script). En modul i Atlas kan nämligen beskrivas tillhöra en specifik databas och en specifik tabell i den databasen. Och med hjälp av ytterligare specificering vad gäller vilka fält man ska kunna redigera, vilka som ska visas i listningar och vilka man ska kunna söka på så kan jag med detta verktyg redigera vilken databas som helst!
I modulbeskrivningen så specificerar jag alltså precis hur man redigerar den här databasen, till exempel min DVD-samling. Jag säger att i formuläret så kan jag redigera IMDB-numret, titeln, året, datumet osv, och i listningar så ska titeln och datumet visas och så vidare. När detta är klart så är det en smal sak att se, söka lägga till och redigera poster i den databasen. Och det fungerar med i stort sett vilken databas som helst. Systemet har till och med stöd för bilder, då jag kan specificera vilken sökväg bilder ska läggas i där både scriptet och servern har tillgång till dem. Vare fält som ska redigeras kan jag specificera typ på också, så att det är en popup, eller en textruta eller att man får välja ett datum.
Den här funktionen är helt oumbärlig för mig och gör att nya databaser och lösningar är enkla att underhålla.
Den här funktionen är helt oumbärlig för mig och gör att nya databaser och lösningar är enkla att underhålla.
Men som någon kanske gissat så har det sina begränsningar. Jag kan till exempel inte redigera två databaser samtidigt med den (än!) som man kanske skulle behöva om man använder relationsdatabaser en hel del (t.ex, man vill ha kategorier för DVD-filmerna i en extern databas och kunna välja dem i en popup i scriptet osv). Men det gör inte så mycket, för jag har inget emot att göra specifika lösningar för vissa saker. Det fina i det här är att om en modul har en egen förstasida, list-script eller edit-script så väljer atlas att länka till den automatiskt istället för att använda det här systemet. Så om jag vill hantera Artikel-databasen med ett specifikt script (vilket jag vill, rätt mycket relationer där) så kan jag fortfarande använde mig utav det generella list-scriptet för att lista och söka i databasen, jag kommer bara till ett annat script när jag klickar på en post.
Atlas har även ett inbyggt, kontextuellt, hjälpsystem som visar en liten symbol när det finns inskriven hjälp för en viss funktion i Atlas eller på siter som drivs med hjälp av Atlas.
Artiklarna
Den viktigaste modulen i Atlas är givetvis Artikel-modulen. Det är med den man publicerar texter på hemsidan, vilket förmodligen är anledningen till att man vill ha ett innehållssystem från början. Atlas artikelmodul är även den i sin tur moduluppbyggd. Man kan, på ursprungsbasis, bestämma vilka moduler man vill ha, vilket både påverkar vad som visas på siten och vilken sorts information du kan binda till en artikel.Till exempel så har sandman.net modulerna Kategorier, Skribent, Länkar, Relationer, Liknande och Kommentarer bundet till sig. Vilket betyder att jag kan kategorisera mina artiklar, den som skrivit texten kommer visas när man läser den (vilket i sin tur är ihopkopplad med medlemsmodulen), jag kan lägga till länkar till texten, separat eller till specifika stycken, jag kan relatera texten med andra texter och med hjälp av nyckelord kan jag få Atlas att automatiskt tipsa om liknande artiklar, och slutligen så kan man kommentera texterna.
Ett annat ursprung som sköts via Atlas här på sandman.net är Pro Evolution Soccer siten (www.pes.nu) som jag utvecklat. Den har, utöver dom modulerna aktiverat bildmodulen samt en specifik modul för speldatabasen.
Artikeldatabasen har även ett fält för metadata, vilket betyder att om man vill binda en specifik sorts uppgift till vissa artiklar så kan man definiera ett meta-fält för ett ursprung. sandman.net har till exempel "path" som metadata, som används för arkivet, för att placera de artiklarna i ett sökvägsupplägg.
Som jag nämnde så har detta kopplingar till medlemsmodulen, som också är en del av Atlas. Alla som är medlemmar vet hur den fungerar, och den sköts av en egen databas som innehåller medlemsbilder, favoriter och liknande. Många moduler är ihopkopplade med medlemsdelen på så sätt att om atlas listar texter och skribenten är medlem så kan mer information om den personen visas i listningen.
Så hur funkar det, rent tekniskt?
Ja, hur ska man förklara detta utan att bli FÖR teknisk? Atlas har ett så kallat init-script som måste köras för varje site som ska använda atlas. Det heter, passande nog, init.php och körs automatiskt för varje sida som laddas. Det scriptet gör generella saker som kontrollerar om man är inloggad och hämtar information om medlemmen i så fall, samt definierar en hel del php-funktioner som alla sidor måste ha tillgång till, såsom ikon-funktionen som skalar och visar ikoner där man vill ha dem, samt saker för att ta hand om metadata och skriva ut text.Sen har varje atlas-site ett "head.php" och ett "foot.php" som innehåller layouten för den specifika siten och som laddas automatiskt med hjälp av "php_value auto_prepend_file" och "php_value auto_append_file".
Sen har jag skrivit specifika funktioner för medlemmar, sidnavigering, trådade svar, omröstningar, xml-parsning, formulärhantering, tidräkning och artiklar för att nämna ett par, men de laddas ju bara för de sidor där dom behövs.
Script för att läsa och lista texter, forum och medlemssidor är ju också globala, så dem länkas in direkt i webserver-konfigurationen. Så man kan slänga upp en rätt avancerad site med hjälp av bara tre filer, en index.php, en head.php och en foot.php - Sen har man en site med medlemsregistrering, forum, kommentarer, omröstningar, bilddatabas och så vidare och så vidare... Väldigt smididgt. Återanvända kod är A och O i atlas.
Flexibilitet
Men i och med att alla funktioner ska kunna användas samtidigt av flera ursprung så måste dom vara ordentligt flexibla. Man måste kunna specificera att man inte vill ha "dagboksdelen" på medlemssidan eller att man måste vara medlem för att få skriva i forumet och sådant. Detta är något som är under konstant utveckling och mer och mer saker går att göra specifika för ett givet ursprung.Ja, det blev en lång text det där... De flesta av er tycker nog att den var helt ointressant, men det var några som frågade om det i alla fall. Är något oklart så kommentera den här texten och fråga så ska jag se om jag kan svara!
