Skip to end of metadata
Go to start of metadata

Kopiera med relationer (KMR) är en funktion för att kopiera dokument och enheter som är kopplade till varandra. Exempelvis en dokumenthierarki, alla dokument och kategorier i en viss kategori, eller till och med allt i en enhet.

Kopiera med relationer har tillkommit för att underlätta kopiering och uppdatering av webbplatsfunktionalitet och innehåll. Istället för att kopiera enskilda kategorier och dokument kan relaterade dokument automatiskt identifieras och kopieras.

Förutom själva kopieringsfunktionen har KPM även stöd för att vid inklistring bibehålla de relationer som finns i den information som kopierats. Om en exempelvis en EPT-kategori kopieras kommer även tillhörande redigeringsformulär och presentationsmallar att kopieras.

KPM fungerar även tillsammans med Content Studio Shell Extensions och kan användas för att spara ned "funktionsmoduler" till exempelvis skrivbordet.
"Kopiera med relationer" används alltså oftast för att kopiera ett (eller flera) dokument eller en funktion från en webbplats till en annan, så att (utgående) relationer (länkar m.m.) till andra objekt bibehålls, trots att de kanske ska referera till helt andra ID-nummer på destinationswebbplatsen.
Denna artikel försöker redovisa vad som hanteras av detta kommando, och vad som inte hanteras.

Några användningsscenarion är inkluderade i slutet av artikeln.

Definitioner:

  • Med "Objekt" menas "Enhet", "Kategori", eller "Dokument" i Content Studio.
  • Med SRC menas den webbplats man kopierar ett objekt ifrån, dvs. ursprungswebbplatsen.
  • Med DEST menas den webbplats som man kopierar till, dvs. destinationswebbplatsen.
  • ID är en identiferare för objekt. ID är alltid unik inom en webbplats, men inte mellan webbplatser (globalt). "Samma" objekt på två olika webbplatser kan ha olika ID.
  • GUOID är en globalt unik objekt-identifierare, som är avsedd att identifera objekt med gemensamt ursprung, på olika webbplatser. GUOID skapas när objektet skapas, och används endast av KMR-funktionen (f.n.). Objekt med samma ursprung kan ha olika ID på olika webbplatser, men de kommer alltid att ha samma GUOID.

När man använder KMR-kommandot på en webbplats (SRC) kommer viss information i de valda objekten att genomsökas, i syfte att finna relationer till andra objekt på webbplatsen. Content Studio kommer att fråga om informationen ska analyseras (synkroniseras) och förberedas för att kunna klistras in med bibehållna relationer:

Kopiera med relationer – synkronisering av relationer

När informationen analyserats kontrollerar Content Studio om det finns beroenden till dokument eller kategorier som ligger utanför det område som kopieras – exempelvis dokument i kategorier som ligger i andra enheter eller ovanliggande kategorier. Om Content Studio hittar relationer utanför kopieringsurvalet visas en dialogruta där användaren kan välja att inkludera eller exkluderas dessa objekt:

Kopiera med relationer – objekt utanför kopieringsurvalet


Om användaren svara Ja på denna fråga kommer alla utomstående objekt att analyseras och inkluderas i kopieringen. Processen är rekursiv och kan innebära att en stor mängd information kopieras.
Så småningom kommer de inkluderade objekten att ligga på klippbordet i Windows, i ett XML-format som Content Studio (CS) förstår.

Vad händer vid "klistra in"?

Avslutningsvis väljer användaren att "klistra in" kopierad information på en destinationswebbplats (DEST) i en kategori.
Content Studio kommer då att för varje objekt…

  1. Avgöra om objektet redan finns på DEST, genom att (på hela webbplatsen) söka efter en unik identifierare (GUOID), som CS har kontroll över.
  2. Om objektet finns på DEST, erbjuds användaren att…
    1. ersätta (skriva över) objektet på DEST. (Det vanligaste valet).
    2. skapa ett nytt objekt (med nytt ID och ny GUOID, dvs ungefär som om man skapade det på nytt på DEST med motsvarande innehåll.) Observera att objektet då lagras på platsen där man valde "klistra in".
  3. Om objektet inte finns på DEST kommer CS att
    1. skapa nytt objekt som får nytt ID, men samma GUOID.
    2. Om objektets förälder redan finns på DEST får användaren välja om det skall läggas under föräldern eller där man valde att "klistra in".
  4. CS kommer att återetablera de relationer som tidigare identiferats. Det handlar som regel om att CS döper om referenser till ID-nummer så att det stämmer på DEST. (Vilka relationer som hanteras framgår nedan.)

Vilka relationer hanterar KMR?

KMR söker bara efter utgående referenser från de valda objekten. Eventuella inkommande referenser eftersöks inte, vilket har bedömts vara en rimlig ansats.

KMR söker efter följande (utåtgående) relationer

  • Allt i HTML som är en URL
  • dokumentID och kategoriID som valts i fält i AS-komponenter. (KMR söker efter Datatyp=dokument-ID eller kategori-ID)
  • Kopplade presentationsmallar, kopplade redigeringsformulär. (dvs. EPT-relationer)
  • Dokumenthierarkier
  • Behållare och egenskaper på behållare

KMR söker inte efter följande relationer

  • Dokumentdirektiv (Header i ASPX-sidor) kontrolleras f.n. inte, men kopieras. Här kan det finnas relationer till User controls, Master pages, som då måste justeras manuellt.
  • MLC-relationer mellan objekt. (MLC=Multi-Language-Cluster).

Vad kopieras vid användning av KMR?

De objekt som valts ut kopieras givetvis. Och deras "innehåll" likaså. Men hur är det med metadata?

Följande metadata kopieras

  • Enheter:
    • Egenskaper
    • Dokumentdirektiv
  • Kategori
    • Egenskaper (utom händelser)
    • Bildbehandlingsinställningar
  • Dokument
    • Relation till förälder (Enhet/kategori)
    • Relation i dokumenthierarki
    • Egenskaper såsom namn, filnamn, Virtuell URL mm

Följande metadata kopieras inte

  • Enheter:
  • Kategori
    • Händelser
    • Säkerhetsinställningar
    • Publiceringsdatum
    • Dokumenttypsdeklaration
    • Teckenuppsättning
    • Arbetsflöden och logg
    • MLC
  • Dokument
    • Teckenuppsättning
    • Säkerhetsinställningar
    • Arbetsflöde
    • Dokumenttyp

Några användningsscenarion

Scenario 1: Kopiera valda dokument till annan webbplats

Anta att vi vill kopiera ett antal dokument från SRC till DEST.
Anta för enkelhets skull även att de valda dokumentens föräldrakategori även finns på DEST, och att det är där vi vill att eventuellt nya dokument skall lagras.
Det är i princip ingen skillnad att välja en kategori eller ett dokument när man kopierar med relationer. Om man väljer en kategori kommer alla dess barn och barnbarn inkluderas.

Huvudscenario

  1. Användaren markerar ett antal dokument SRC, och väljer "Kopiera med relationer".
  2. Efter en stund dyker det (vanligen) upp en ruta som säger:
  3. Användaren svarar Ja, eftersom vi vill bevara relationer. (Det är mycket ovanligt att man svarar nej på denna fråga.)
  4. Om något av de valda objekten har relation till utomstående objekt (som inte valdes av användaren i steg 1), kommer en ny ruta som frågar: "Vill du inkludera utomstående objekt i kopieringen?".
  5. Användaren svarar Nej. Man vill inte att utomstående objekt kopieras. (Relationerna till dessa utomstående objekt kommer dock att bibehållas.) Not: I de flesta fall brukar vi rekommendera att man svarar Nej på denna fråga, eftersom man f.n. får veta hur många, men inte vilka utomstående objekt som inkluderats. Det är bättre att man tar reda på vilka objekt som skall kopieras, innan man påbörjar kopiering, och sedan aktivt väljer dessa.
  6. När KMR är klart försvinner statusdialogen som ser ut så här:
  7. Därefter byter användaren till det webbläsarfönster som visar admin-vyn för DEST.
  8. Användaren väljer "klistra in" dokumenten på DEST, i den kategori som motsvarar dokumentets kategori på SRC.
  9. Klart.

Not: Vad hade hänt om användaren valt att klistra in dokumenten i en annan kategori på DEST, än den som motsvarar föräldrakategorin på SRC? Då hade användaren fått välja ifall man vill lagra under den kategori som motsvarar föräldrakategorin på SRC, eller om man vill lagra som nytt dokument där man valde "klistra in".

Scenario 2: Kopiera en modul inom en webbplats

Anta att vi har skapat en modul, som består av en kategori, K, och två underdokument, A och B, som refererar till varandra.
Vi vill nu kopiera denna modul inom webbplatsen, (kanske för att kunna göra en modifierad variant).

Dokumentens inbördes relationer vill vi bevara efter kopieringen. (Eventuella referenser till utomstående objekt kommer också att bevaras).

Om man skulle kopiera denna kategori med det "vanliga" kopiera- kommandot kommer (efter inklistring) de nya dokumenten att referera till de gamla dokumentens ID. Det vill vi inte, utan istället vill vi att de nya dokumenten skall referera till de nya dokumentens ID. Genom att använda KMR och kopiera K till ny plats på webbplatsen löser vi detta.

Således:

  1. Använd KPM på kategori K.
  2. Välj "klistra in" i den kategori där du vill lagra den nya kopian av K.
  3. KMR ser nu att K redan finns på webbplatsen och undrar om du vill skriva över denna ("ersätta"). Svara Nej på frågan nedan. Du vill inte ersätta K, utan skapa en ny kopia där du valde "klistra in".

  1. På samma sätt ser KMR att de dokument som ingår också finns som original på webbplatsen. För att slippa svara på alla dessa frågor, bör du kryssar i "Tillämpa på alla objekt" innan du väljer "Nej".
  2. Slutligen skall du välja ett namn på den nya kategorin.
  3. Klart.

Scenario 3: När man vill göra flera delkopieringar.

Om man vill kopiera så stora mängder att RAM-minnet tar slut (datat mellanlagras på klippbordet), kan man behöva dela upp kopieringen i ett par mindre kopieringar.
Låt oss tänka oss att vi vill kopiera två objekt, A och B. A har referens till B och B har en referens till A. Anta att vi ska kopiera dem var för sig separat. Hur gör vi då för att se till att de refererar till varandra efter slutförd kopiering? Anta att varken A eller B finns på DEST sedan tidigare.

  1. Kopiera A från SRC till DEST mha KMR. A kommer då att nyskapas på DEST, och referensen till B kommer inte att ändras eftersom ingen B finns på DEST.
  2. Kopiera B från SRC till DEST mha KMR. B kommer då att nyskapas på DEST, och referensen till A kommer att ändras eftersom A finns på DEST. B refererar nu korrekt till A, men A refererar inte korrekt till B.
  3. Kopiera A en gång till från SRC till DEST mha KMR. A kommer då att uppdateras på DEST, och referensen till B kommer att ändras eftersom B finns på DEST. Deras inbördes referenser stämmer nu.


Anta nu att man vill göra en omfattande kopiering av, låt säga, 10 separata kopieringar. I det fallet är rekommendationen att

  1. Utför alla 10 kopieringar mha KMR från SRC till DEST.
  2. Upprepa sedan steg 1 ovan en gång till. Då kan man vara säker på att alla relationer (som hanteras) blivit återetablerade på DEST.

I steg ett kommer då samtliga objekt att kopieras och vissa relationer (men inte alla) att etableras. I steg två säkerställer vi att samtliga relationer etableras.

När behöver man hjälpa CS på traven, i att hitta relationer?

Det finns förstås lägen där kopiera med relationer inte kan identifiera en referens till ett visst objekt. Detta kan gälla när det sker i källkod. Då kan man "tagga" upp sin källkod med virtuella funktioner vars enda syfte är att tala om för KMR att detta är en objektreferens.
Dessa funktioner heter:

  • CSF_LookUpDocumentId(123456)
  • CSF_LookUpDocumentFileName(Images/Icons/MyGif.gif)       'OBS Inga fnuppar...
  • CSF_LookUpCategoryId(12346)
  • CSF_LookUpUnitId(123456)

Exempel: C#
int myCat = CSF_LookUpDocumentId(123456);
string myUrl = " CSF_LookUpDocumentFileName(Images/Icons/MyGif.gif)";

Övriga noteringar

Om man med KMR skriver över ett utkast på DEST kommer utkastet inte att kunna återskapas efter KMR klistrat in innehållet.
KMR hanterar endast utgående relationer från valda objekt. Inkommande relationer hanteras inte. Detta är en ganska rimlig ansats, och anses inte vara en brist. Det är dock bra att känna till detta.
I de flesta fall brukar vi rekommendera att man svarar Nej på frågan "Vill du inkludera utomstående objekt i kopieringen?", eftersom man f.n. inte får en tydlig feedback på vilka utomstående objekt som inkluderats.

Labels
  • None