Deployment aplikace Site Studio for External Applications

Vraťme se naposledy k problematice WCM v releasu 11g. V minulých článcích jsme si postupně představili základní koncepty a změny oproti 10g (užití JSP a Jdeveloperu jako IDE). Jak se ale bude chovat aplikace v produkčním prostředí?

Odpověď je, možná, nepřekvapující: jako J2EE aplikace

Aplikace se na aplikační server dodává v .EAR souboru, který má tuto strukturu:

+ -- My Application.ear
+ -- MySites.war
+ -- adf/META-INF/
+ -- connections.xml
+ -- META-INF/
+ application.xml
+ weblogic-application.xml


MySites.war obsahuje reference na jeden content server a sites (které jsou uloženy na něm jako obsahové položky, tj. soubory .xml; jinak je najdete podle kritéria "WebSiteObject matches Project")
connections.xml obsahuje odkaz na URL Content Serveru, který obsahuje užité položky obsahu (dokumenty, obrázky, multimédia); bez autentizace je možné přistupovat jen na položky z bezp. skupiny 'Public', které jsou navíc přiřazeny danému site (při výběrech)
weblogic-application.xml obsahuje odkazy na sdílené knihovny Site Studia (a RIDC) na daném Weblogic serveru

Soubor MySites.war má pak tuto strukturu:

+ -- MySites.war
+ -- wcm/templates/
+ -- WEB-INF/
+ web.xml
+ wcm-config.xml
+ weblogic.xml

/templates/ je adresář obsahující všechny JSP/JSPX registrované ve wcm-config.xml
wcm-config.xml je hlavní konfigurační soubor pro Site Studio
weblogic.xml obsahuje reference na sdílené WAR knihovny Site Studia
web.xml je standardní konfigurační soubor pro J2EE aplikace

Jak je vidět z popisu, v architektuře existují 2 servery, aplikační server, který provozuje WCM aplikaci (a má k dispozici některé knihovny) a UCM server, který slouží čistě jako poskytovatel obsahu. I toto je vlastně změna oproti 10g, kdy se UCM server "staral o všechno". Bohužel, i kdyby se jednalo o skutečně dva různé servery, neplatí, že na provozním aplikačním serveru nemusí být licence UCM - vzhledem k instalaci knihoven musí být i tento server licencován pro UCM. Na druhé straně je ale možné využít mechanismus cachování obsahu na provozním aplikačním serveru, čímž je možné dále optimalizovat jak rychlost odezvy, tak zátěž poskytovatele obsahu.
A stále pak existuje možnost vypublikovat statické stránky (což se často využívá u internetových stránek, kde žádná autorizace uživatele pro přístup k dalším sekcím nedává smysl) na web server, kde samozřejmě žádné licence potřeba nejsou.

Dekompozice stránky ve WCM - odshora dolů (část 2.)

Schéma "prostřední" části definice stránky, tj. placeholderů a regionů, je opět nejlépe možné pochopit ze schématu:

Pokud budeme prozatím ignorovat nejnižší vrstvu, tj. elementy, a ponecháme stranou i subtemplates, zbydou nám 4 vzájemně úzce spojené objekty. Přibližme si je nejprve opět pomocí dalšího schématu:


Nejjednodušším objektem je placeholder. Vytváří se na úrovni stránky (tj. její šablony) buď přetažením příslušné ikony do designu stránky, nebo přidáním takovéhoto kódu:

Ke každému placeholderu musí existovat tři další objekty. Jeden, placeholder definition, určuje, jaké operace bude možné s daným placeholderem v přispěvovatelském módu provádět:


Druhým je pak Region Definition, která definuje "obsah" příslušného regionu - v našem příkladě z druhého obrázku má region 5 oblastí: Title, Subtitle, Intro Text, Body Text a Image. Na následujícím obrázku bude příklad regionu se dvěma oblastmi (elementy).


Aby to celé mohlo fungovat, je ještě nezbytné, aby bylo určeno, které oblasti regionu a v jaké podobě budou uživateli zobrazeny. K tomu pak slouží poslední objekt, Region Template, což je opět JSP definující podobu výstupu (při jeho definici je možné použít subtemplates, které opět mohou obsahovat další placeholdery).

Jak je také vidět z druhého obrázku, je teoreticky možné, že by k jedné existovalo více zobrazovacích šablon. V rámci definice definici placeholderu se pak určuje, která z nich se v dané situaci použije.

Poslední nutný link, mezi placeholderem a jeho definicí, se poněkud nelogicky provádí na úrovni site (tam, kde se příslušným stránkám přiřazují jejich primární a sekundární šablony), a to pomocí tlačítka s názvem Placeholder Definition Mappings.

Pro srovnání: dříve se v aplikaci SiteStudio prováděly všechny tyto operace na jednom místě. To je zřejmě daň za rozdělení formy (JSP) a pravidel chování/mapování mezi objekty (což je v podstatě XML).

(pokračování někdy příště)

Dekompozice stránky ve WCM - odshora dolů (část 1.)

Podívejme se nyní trochu detailněji na to, z čeho se skládá stránka, resp. její šablona (Page Template)



Jak je vidět, šablona stránky se kromě statického textu (který většinou bývá minimální) skládá z tzv.

• fragmentů, což jsou menší znovupoužitelné celky, které podobně jako šablona stránky definují "šablonu" pro nějakou konkrétní část stránky (viz příklad: fragment pro navigaci či footer stránky)
• regionů, reprezentovaných placeholdery, kterým je naopak možné přiřadit obsah z úložiště, resp. tento v nich aktualizovat
• kromě těchto dvou konceptů je možné v definici stránky využít i obsah spravovaný třetí stranou; často se jedná o reklamní bannery či výstupy webových aplikací. Pro tento typ zadání se používá HTML tag iframe. WCM však v tomto případě nemá žádnou kontrolu nad obsahem. Pokud by byla kontrola vyžadována, je možné použít technologii mashup, která je k dispozici v rámci produktu WebCenter.

Co je v release 11g nového, je to, že šablony stránek či fragmentů je možné nyní psát také pomocí notace JSP (v 10g to bylo možné výhradně pomocí proprietárního jazyka iDocScript). Vývojovým nástrojem pro psaní (či grafický design pomocí drag&drop) je nástroj JDeveloper. "Starý" způsob přes iDocScript se ani náhodou neruší. Naopak, produkt management do budoucna slibuje, že způsobů, pomocí kterých bude možné šablony vytvářet, bude neustále přibývat. Tak uvidíme...

Primární a sekundární stránky
Aby se snížil počet vytvářených šablon, nabízí WCM (i v 10g) koncept tzv. primárních a sekundárních stránek.
Primární stránka je definice stránky tak, jak ji návštěvník vidí, když se na stránku dívá poprvé. Obsah (tj. i provázání na položky, které vyplňují jednotlivé regiony) je na ní definován staticky. Představme si ovšem, že obsah přestavuje výpis odkazů na dokumenty dle určitého kritéria, např. tisková prohlášení (pozor! Nenechte se zmást - statická je zde definice dotazu, seznam se samozřejmě bude dynamicky měnit podle aktuálního obsahu úložiště). Nyní bychom ale chtěli na jeden klik zobrazit obsah jednotlivých dokumentů.
A přesně k tomuto jsou určeny sekundární stránky, které provádějí provázání dynamicky, a to až v okamžiku kliknutí na příslušný odkaz.
Bývá dobrou praxí, že primární a sekundární stránky využívají stejnou, nebo alespoň podobnou šablonu (v našem příkladu bychom nejspíš chtěli, aby sekundární stránka obsahovala přinejmenším sekce Banner Image, Side Nav Fragment a Footer Fragment).

(pokračování někdy příště)