Dynamiske nettsider: når det blir flere sider enn noen orker å lage

Hva «dynamisk» faktisk betyr

En vanlig nettside har én side per side. Vil du ha femti tjenestesider, lager noen femti sider. En dynamisk nettside har én mal og et datasett. Femti oppføringer i datasettet blir femti sider, og endrer du malen, endres alle femti.

Forskjellen merkes ikke den dagen siden lanseres. Den merkes den dagen oppføring nummer to hundre skal inn, eller den dagen alle sidene skal ha et nytt felt.

Hva en slik løsning faktisk gjør

Vi driver et nettsted av denne typen selv — en reiseguide bygget rundt et interaktivt kart, der hundrevis av steder deler én mal og ett datasett. Det er den beste referansen vi har på denne typen arbeid.

Vi oppgir bevisst ingen tall fra det her. Nettstedet er under kontinuerlig utvikling, så et sidetall ville vært utdatert kort tid etter at det ble skrevet — og et tall som blir feil av seg selv er verre enn ingen tall, fordi det ser presist ut. Spør, så viser vi det fram, med det som står der den dagen.

Det som ikke endrer seg, er hva løsningen gjør:

• To filtre som virker samtidig — for eksempel type og område. Ett filter er lett. To som snevrer inn hverandre, er arbeidet
• Kart og liste som holder seg i takt — filtrerer du listen, forsvinner nålene fra kartet i samme bevegelse
• Ingen omlasting — resultatet oppdateres uten at siden bygges på nytt
• Delbar tilstand — filtervalgene ligger i adressen, så et søkeresultat kan sendes videre og åpnes likt av mottakeren
• Interne lenker som skriver seg selv — hver side lenker til naboene sine, og listen oppdateres når det kommer en ny oppføring
• Ny rad blir en ferdig side — med kart, filtrering og lenker på plass, uten at noen bygger den

Det er kombinasjonen som er den tekniske jobben, ikke antallet oppføringer. En løsning som takler to hundre rader, takler som regel to tusen. En som bare takler tjue, gjør det fordi datamodellen ikke ble bestemt først.

Hvorfor det ikke er Crocoblock

Vi har vurdert Crocoblock og JetEngine grundig, fordi de løser akkurat denne typen oppgave og fordi de er det folk kjenner fra norske nettsteder med avanserte filtre.

Konklusjonen var nei, av én teknisk grunn: JetEngine støtter ikke Oxygen. Leverandøren oppgir Elementor, Gutenberg, Bricks og Divi. Skulle vi brukt Crocoblock, måtte vi byttet byggeverktøy for hele nettstedet.

I Oxygen 6 gjør vi det samme med Dynamic Data og egne felter. Det er mindre ferdigpakket og mer oppsett, men det holder oss på ett verktøy — som er hele poenget med å bygge komponenter først.

Hva jobben består i

1. Datamodellen

Hvilke felter har en oppføring? Hvilke av dem skal det kunne filtreres på? Dette er den viktigste avgjørelsen, og den er dyr å endre senere. Et felt du ikke har, kan du ikke filtrere på.

2. Å få dataene inn

Sjelden den morsomme delen. Data kommer i regneark med ulik skrivemåte, manglende koordinater og dubletter. Vi har skrevet om hvordan vi graderer omfanget av slike kataloger fra N1 til N5, nettopp fordi spriket er så stort.

3. Malen og filtrene

Én mal for oppføringssiden, én for oversikten. Filtrene skal virke sammen, oppdatere resultatlisten uten omlasting, og legge igjen et spor i adressen slik at et filtrert søk kan deles.

4. Søkemotorene

Hver oppføring skal være en side Google kan finne. Det betyr en egen adresse, egen tittel og strukturerte data — ikke bare et punkt som dukker opp i et kart etter at JavaScript har kjørt.

Hva vi ikke lover

Vi lover ikke at siden er rask uansett hvor mange oppføringer du legger inn. En oversikt med tolv oppføringer og en med tolv hundre er samme mal, men to helt ulike sider å laste — det er en av grunnene til at vi ikke gir ytelsesgarantier.