Metadata

Det är lätt hänt att lägga in konfiguration för skript/moduler som metadata, därför bör man vid skapande av metadata veta exakt på vilket sätt metadata ska användas.

Både skripts och moduler har möjlighet till konfiguration så därför ska konfiguration undvikas att implementeras med metadata.

Det finns dock undantag då man behöver lägga konfiguration som metadata nämligen då konfigurationen ska ärvas ner i en trädstruktur. Ett exempel på det är när man vill ha en undermeny som ska börja på olika startsidor.
Man vill bara behöva sätta detta metadata på de olika startsidorna och låta det ärvas ner till alla undersidor.

Konfiguration

I både moduler och skript finns möjligheten att peka ut metadatafält i konfiguration. Detta är nästan alltid att föredra mot att hårdkoda ett metadatafälts namn i koden. Detta för att det blir mer flexibelt och enklare att flytta lösningar mellan projekt.

Namnkonvention

Namn på metadata kan följa de regler som finns att läsa om på schema.org då det är applicerbart på den aktuella verksamheten. Schema.org är en community som bland annat standardiserar namngivning för strukturerad data.
På schema.org kan man söka efter det man vill namnge för att få exempel kring namngivning.

Värt att nämna är att metadata som är kvalificerad som konfiguration (behöver ärvas ner) finns förmodligen inte på schema.org men det är en bra inspirationskälla.

Prefix

All metadata som inte är skapat av Sitevision ska ha ett prefix för att särskiljas från övriga metadata. I de flesta fall bör detta vara kundspecifikt för att säkerställa att det inte blir några konflikter med metadata som skapas av Sitevision.
I våra paket är metadatafält prefixade med sol, detta bör således bytas ut mot kundspecifikt prefix när projektet drar igång.

Subgrupper

Om det finns mycket metadata kan det vara bra med subgrupper för att på ett snabbt och enkelt sätt få en överblick över logiska och strukturella tillhörighet. Metadata som har med konfiguration att göra skulle kunna ha subgruppen conf för att uppmärksamma att det är konfiguration.
Med en subgrupp för konfiguration skulle man kunna gå igenom dessa metadata och se om de är kvalificerade som metadata (behöver ärvas ner) eller om de ska vara konfiguration för skripts/moduler.
Ett exempel på metadata som konfiguration kan vara {prefix}.conf.menuStart

Exempel: Vi ska ha metadata för kurskod och startdatum för en kurs.
Vi bestämmer oss för att vi ska ha en subgrupp för kurser som vi kallar course (singular form).
På schema.org hittar vi 2 kandidater med attribut för kurskod och startdatum, nämligen event och course.
Startdatum för event är startDate och kurskod för course är courseCode.
Metadata kommer då få namnen {prefix}.course.startDate och {prefix}.course.courseCode.

Motivering:
Med prefixen {prefix} kan vi snabbt identifiera och särskilja metadata vi själva skapat och metadata skapat av Sitevision.
Med schema.org får vi en standardiserad namngivning och slipper problem med olika namngivningar för samma saker som exempel publishDate, pubDate, publishedDate.

Exempel

1. {prefix}.event.startDate - Startdatum för ett event.
2. {prefix}.article.publishDate - Publiceringsdatum för en artikel.
3. {prefix}.keywords - Nyckelord.
4. sol.subpage.image - Publiceringsdatum för en artikel i paketen som såldes bör bytas ut till kundspecifikt prefix.

Metadata utanför mallar

I de allra flesta fall kommer metadata hamna i någon av de specifika delmallarna. Men det finns tillfällen då man vill lägga metadata utanför delmallar, alltså på sidor. Detta förklaras enklast med ett exempel.

Nyheter (Sida)
  |
  +--- Arkiv 1
  |
  +--- Arkiv 2
  |
  +--- Arkiv 3

I strukturen ovan ser vi sidan ”Nyheter” som listar alla nyheter som finns i de 3 underliggande arkiven. Man vill kategorisera nyheterna efter det arkiv som de ligger i. För att göra det enkelt för redaktörer vill man att det ska räcka med att redaktörer lägger nyheten i rätt arkiv för att den ska få rätt kategori.
Detta uppnås genom att lägga metadata på sidan ”Nyheter”. Detta metadata ärvs ner till alla undernoder då metadata ligger på sidan och inte i mallen. Varje arkiv sätter sin kategori, vilket gör att redaktörer inte behöver sätta detta metadata för varje enskild nyhet.

Ett annat specialfall är när man lägger metadata på mappar. Ibland kan detta vara nödvändigt då sidors namn, men inte mappars, kommer med i URL.