Beslut av lösningsalternativ
Det finns i olika sätt att implementera en funktion. Beroende på funktionens komplexitet lämpar sig olika lösningar. Följande punkter (utan inbördes ordning) är viktig att ta ställning till oavsett vilken typ av lösning man väljer:
- Förvaltningsbarhet.
- Redaktörsvänlighet.
- Utbyggbarhet.
- Tillgänglighet.
- Återanvändbarhet.
Ovanstående punkter kan prioriteras olika från fall till fall och kan vara avgörande för vilken lösning som är mest lämpad. Det är viktigt att alltid ha med denna checklista innan man bestämmer sig för typ av lösning.
Sitevision-modul
Att använda en befintlig Sitevision-modul är oftast snabbaste och enklaste sättet att implementera en funktionalitet.
✔️ Fördel
Snabbt och enkelt och underhålls av Sitevision utan extra kostnad.
❗ Nackdel
Vanligtvis är det endast enklare moduler som uppnår krav på funktionalitet och design. Ibland kan man vara tvungen att ändra så mycket i koden (velocitymall) att det blir omöjligt att förvalta. Om modulens kod inte går att pekas ut till en fil är det inte möjligt att versionshantera utan manuell handpåläggning. En del äldre moduler är inte tillgängliga och kan inte göras tillgängliga.
👍 Rekommendation
Om det finns Sitevision-moduler som uppnår kraven på funktionalitet och design samt de icke-funktionella kraven så är rekommendationen att använda denna lösning.
Skriptmodul
Skriptmodulen är en flexibel lösning som har få begränsningar för vad den kan göra. Inställningar i skriptmodulen ska endast göras av utvecklare eller möjligtvis administratör.
✔️ Fördel
Snabbt och enkelt att skapa och flexibel med med få begränsningar vilket gör att man kan göra det mesta med den. Den är också enkel att versionshantera med automatik genom att peka ut skript i filarkivet och utveckla utanför Sitevision.
❗ Nackdel
Det enda sättet att han flera instanser av skriptmodulen utan att kopiera är att länka till den. Detta gör att den inte är lämplig att användas av redaktörer. Redaktörer är vana att plocka moduler från listan av moduler.
👍 Rekommendation
Sitevision planerar att ta bort skriptmodulen i framtiden så rekommendationen vid egenutveckling är oftast WebAppar.
Använd skriptmodulen för enklare dynamiskt innehåll. Den bör endast finnas i mallar där redaktör inte kan skapa och konfigurera. Skriptvariabler ska vara ett sätt att konfigurera skriptet snarare än ett sätt för redaktörer att ändra på skriptets innehåll. Detta har med att skriptvariabler inte är ett bra gränssnitt för administratörer samt att skriptmodulen bör endast finnas i mallar.
Om en skriptmodul används på många olika mallar bör man använda en länkad layout, men man bör då fundera på om man ska använda en annan lösning istället såsom WebApp.
Element
Element är ett sätt att paketera en lösning så att den fungerar som Sitevisions inbyggda moduler. Den kan göra mer eller mindre allt som en skriptmodul och lite till då den kan ha andra Sitevision-moduler i sig. Dessa moduler är dock inte redigerbara. Den är mer redaktörsvänlig än skriptmodulen. Med det menas att den inte skiljer sig från en inbyggd Sitevision modul för redaktörer. Den kan användas på såväl innehållsytor som mallar. Om man har ett element som bara har en instans på siten och som dessutom ligger i mall så är en skriptmodul att föredra då det går snabbare att utveckla och uppdatera en skriptmodul.
✔️ Fördel
Har få begränsningar för vad som går att göra med den. Den är mer redaktörsvänlig än skriptmodulen.
❗ Nackdel
Krångligt att uppdatera och utveckla. Mycket långsammare att utveckla än skriptmodul. För att kunna testa ordentligt måste man exportera elementet och sedan importera. Alla inställningar måste göras om vid varje import. Kan inte versionshantera koden med automatik då det inte går att peka ut kod i filarkivet. Möjligheterna för att konfigurera redaktörsgränsnittet är begränsat. Metadatatyper saknas, ordningen på fälten är svår att styra och man kan generellt inte finjustera det som man vill (tex med bilder, längre texter, listor, länkar m.m).
👍 Rekommendation
Vi rekommenderar att inte använda element alls nu när en alternativ teknik, webapps, finns att tillgå från och med Sitevision v4.5. Detta pga att de nackdelar som finns väger över dess fördelar. Det finns tillfällen då man vill göra en väldigt enkel och trivial funktionalitet som redaktörer ska få tillgång till. Endast då kan det vara värt att använda element.
WebApps
Webapps är den mest avancerade lösningen (om man räknar bort portlet). En WebApp kan och bör byggas helt self-contained. Med detta menas att den kan vara helt självständig utan externa beroenden. Man kan ha klientsidekod som anropar serverkod där både klient- och serverkoden är paketerad i WebAppen, på så sätt hålls hela applikationen ihop i en enda binär. Med webapps kan man också uppnå både server- och klientside rendering med samma mallar.
✔️ Fördel
Snabbt att utveckla. Enkelt att uppdatera och versionhantera. Kan vara helt self-contained.
❗ Nackdel
Går inte att modifiera om man inte får källkoden då det importeras in till Sitevision. Vid mycket små applikationer blir det mycket boilerplate.
👍 Rekommendation
Använd denna teknik vid större och mer komplex funktionalitet. Webapps lämpar sig även för mindre funktioner. Om redaktör kommer att lägga ut en funktion på en sida så är webapp det bästa alternativet. Finns krav att applikationen ska fungera även utan Javascript påslagen passar webapps utmärkt.
RestApp
Restapp är en variant av webbapp där man inte behöver något grafiskt gränssnitt.
Portlet
När ingen av ovanstående sätt går att realisera, använd portlet som kan lösa det mesta.
✔️ Fördel
Har ”inga” begränsningar alls. Kan kommunicera med webservices via SOAP.
❗ Nackdel
Krångligt att utveckla, testa och deploya i cloud.
👍 Rekommendation
Om Sitevision driftas i cloud rekommenderas inte portlet då det är svårt att utveckla och testa portlets i cloud. Använd portlet för integrera med legacy system där integrationen är SOAP eller annan äldre teknik.