Mnoho implementací sitecore dnes obsahuje více než jeden web. Ať už to jsou firemní stránky stránky pro produkty nebo služby. Pro sitecore není více webů žádný problém. Nastavíte si vlastní šablony, renderingy, CSS styly, skripty, obrázky atd.

Více sofistikovaná řešení jsou v souladu s firemním design manuálem, pravidly pro stylování jak mají jejich stránky vypadat, aby měly stejný vizuální styl. V takovém případě weby sdílejí CSS styly, obrázky, skripty apod. To nejen šetří čas na vývoj, ale tímpádem i peníze. Jenže na straně vývojářů je stále dost práce pro vytvoření šablon, renderingů a programovacího kódu pro vytvoření nového webu.

Vytvoření sady znovupoužitelných komponent

Mít stránky, které se liší jen obsahem, ale ne vzhledem přímo navádí k použití znovupoužitelných komponent. To znamená sdílet šablony, renderingy, styly a vše ostatní, ale ne obsah. Obsah má každý web jiný. Teoreticky při sdílení komponent mezi weby už stačí jen nastavit konfiguraci pro každý web. Samozřejmě také na IIS musí být definované vazby a to nezmiňuji DNS apod., ale žádná kódování navíc. Spousta práce je ušetřena a autoři si mohou sami vytvořit nový web.

Každý web má rozdílné workflow

A co workflow? Musí být stejné pro všechny weby používající sdílené komponenty? …….. Nemusí!

Můžeme mít rozdílné workflow pro každý web používající stejné komponenty a přitom mít rozdílné editory, způsob schvalování atd. Řeč je o dědění workflow. Nastavíte workflow na webu a to se bude dědit při vytvoření nové komponenty na novou komponentu.

Zdroje dat komponent používají stejné workflow jako web, na kterém jsou použity

Aby sdílení komponent fungovalo je třeba dodržet stejnou strukturu zdrojů dat pro všechny weby. Samozřejmě, nic nebrání vytvoření specifických komponent pro web, které mohou být umístěné kdekoliv, ale v případ sdílených komponent musí komponenta vědět, kde zdroj dat hledat a toho docílíme jen stejnou strukturou.

Řešení

Komponenty napříč projektem používají stejnou strukturu pro zdroje dat

Je to celé o struktuře.

Každá komponenta, kterou vytvoříte musí mít zdroj dat v adresáři se stejným jménem pro každý web. Abychom autorům usnadnili proces vytváření struktury nového webu, autoři mohou využít branch template, pomocí které se struktura vytvoří. Obdobně by šlo také použít sitecore powershell.

Například, když máte komponentu „image box“ pak musí být relativní cesta k adresáři „image-boxes“ pro všechny weby vždy stejná. Díky tomu, že je cesta vždy stejná, můžeme nastavit cestu ke zdroji dat na renderingu. Sitecore umožňuje relativní cesty pomocí sitecore query, stejná možnost je také u zdroje polí na šablonách.

Příklad relativního zdroje dat

query:./ancestor-or-self::*[@@templatename='Site Root']/resources/components/#image-boxes#

Řešením je tedy použít sitecore query. Všechny weby v projektu jsou založené na šabloně Site Root, a tímto způsobem naleznete vždy kořenový uzel webu, od kterého se struktura odvíjí. Takže když autor vytvoří novou komponentu „image box“ například pro produktový web, pak bude komponenta vždy umístěna v adresáři „image-boxes“.

Stejnou logiku lze použít pro odkazování na itemy v seznamových typech polí do číselníku hodnot. Můžete se odkazovat na sdílený číselník hodnot pro všechny projekty uvedeným absolutní cesty nebo uvedením relativní cesty budete mít číselník hodnot pro každý web odlišný.

Poznámka: Nezapomeňte v sitecore query obalit cesty obsahující pomlčku znakem #.

Workflow pro web

V tomto případu použití má každý web vlastní workflow. Při vytvoření nového webu, vytvoříte také nové workflow, které na webu nastavíte. Každý web spravuje jiný tým s jinými požadavky na workflow. Nepřipusťte aby komponenty ve webu používali jiné workflow než samotný web a zároveň nemůžete nastavit workflow specifické pro jeden web jako výchozí workflow ve standard values, protože tím by jste workflow vnutili všem komponentám na všech webech.

Výchozí abstraktní workflow

V takovém případě potřebujeme workflow dědit. Tím každá nově vytvořená komponenta podědí workflow z webu. Pro dosažení tohoto cíle si vytvořte jako výchozí nějaké abstraktní workflow. Abstraktní je jen termín, který říká, že workflow nebude reálně na žádném webu použito, bude pouze nastaveno jako výchozí workflow ve standard values.

My jej nazíváme „Parent workflow“, protože právě to je jeho smyslem. Při vytvoření komponenty jež má jako výchozí nastavené „parent workflow“ se jako workflow komponenty nastaví workflow nadřízeného itemu pod kterým je komponenta vytvářena. Tím se zajistí, že všechny komponenty na webu mají stejné workflow i když jsou sdílené mezí různými weby. Toto „parent workflow“ musí být nastavené jako výchozí ve standard values každé sdílené komponenty.

Konfigurace pro event handler

Nahrazení workflow při vytvoření itemu vyžaduje implementaci nového event handleru naslouchajícímu na událost item:versionAdded.

<sitecore>
   <events timingLevel="custom">
      <event name="item:versionAdded">
         <handler type="Custom.Events.SetParentWorkflow,Custom" method="SetWorkflow" />
      </event>
   </events>
</sitecore>

Event handler kontroluje při vytvoření pole __Workflow, které je naplněno sitecore z výchozího workflow ve standard values. Namísto výrazu „ID of item“ v níže uvedeném kódu patří skutečný GUID abstraktního „Parent workflow“.

Pokud handler zjistí, že je nastaveno „Parent workflow“ pak jej nahradí stejným workflow, jaké je nastavené na rodičovském itemu.

Klíčem tedy je nastavit správné workflow na webu, vytvořit shodnou strukturu webu a na standard values sdílených komponent nastavit jako výchozí „Parent workflow“.

protected void SetWorkflow(object sender, EventArgs args)
{
var item = Event.ExtractParameter(args, 0) as Item;
if (item.Fields["__Workflow"]?.Value != "ID of item")//sitecore/system/Workflows/Parent Workflow
{
    return;
}
try
{
    var master = Sitecore.Configuration.Factory.GetDatabase("master");
    var targetWf = master.GetItem(item.Parent.Fields["__Workflow"].Value);
    item.Editing.BeginEdit();
    item.Fields["__Workflow"].Value = targetWf.ID.ToString();
    item.Fields["__Workflow state"].Value = targetWf.Fields["Initial state"].Value;
}
finally
{
    item.Editing.EndEdit();
    item.Editing.AcceptChanges();
}
}

Úskalí

Implementace vyžaduje pečlivost. Snadno lze zapomenout nastavit správné workflow na webu nebo na sdílené komponentě. Takové chyby se později hůře napravují. Důkladné testování je v takovém případě nezbytné.

Když jsme sami začali s implementací sdílených komponent. Při vytváření struktury webu jsme na jednom zkopírovaném adresáři zapomněli nastavit správné workflow a zjistili jsme to až později, kdy adresář obsahoval větší množství komponent, všechny měli samozřejmě stejné workflow jako zkopírovaný adresář. Takových chyb je dobré se vyvarovat hned zpočátku.

Konfigurace sdílených komponent

Stejný principu sdílení jde aplikovat na každý item. Můžete například sdílet konfigurační šablony pro sdílené komponenty a pomocí nich definovat rozdílné chování sdílené komponenty dle rozdílné konfigurace na jednotlivých webech.
Např. můžete nastavit na jednom webu krátký formát data a na jiným dlouhý formát data ve stejné sdílené komponentě.

Dodržujte pravidla

Stačí dodržovat tato pravidla:

  • Udržovat stejnou strukturu webu – Site Root, strom komponent
  • Nastavit relativní cesty pro zdroje dat kde je to potřeba – datasource location, field source
  • Nastavit abstraktní (parent) workflow ve standard values sdílených komponent

Pokud budeme dodržovat tato pravidla, pak můžete mít jednu sdílenou službu, která čte například konfiguraci sdílených komponent podle kontextu webu aniž by jste se museli opakovat.

Vyladění User Experience

Stránky sestavené z komponent mohou obsahovat takových komponent desítky. Uživatelé tíhnou ke kopírování existujících stránek když chtějí udělat podobnou stránku a poté si na ní jen změní obsah. Některým uživatelům je obtížné vysvětlit že, duplikováním itemu zůstanou komponenty stejné. To znamená, že změnou obsahu komponent duplikované stránky se samozřejmě mění také obsah původní stránky. Abychom se vyhnuli takovým nedorozuměním, vytvořili jsme příkaz pro duplikování item včetně komponent. Tento příkaz rozšiřuje sitecore příkaz item:duplicate. Každý zdroj dat je také zduplikován a cesty ke zdrojům dat jsou nahrazeny v shared i final layout.

Další zjednodušení přináší příkaz „Create microsite“. Tento příkaz vytvoří celou strukturu webu pomocí branch template. Při vytvoření nové komponenty pak musí vývojář nejen vytvořit šablony, renderingy a zdroje dat pro tyto renderingy, ale také novou strukturu zahrnout do branch template. Potom všechny nové weby budou mít vždy strukturu odpovídající zdrojům dat jednotlivých komponent.

Rozdílné chování komponent

Komponenty mohou mít drobné odlišnosti v chování na každém webu, takže komponenta může být sdílená a přesto mít rozdílné chování nebo vzhled v závislosti na aktuálním kontextu.