Příklady požadavků
Příklady použití vybraných požadavků řazené abecedně dle názvu uzlu požadavku.
Podřízené stránky
Příklad spuštění akce
Příklad jednorázového provedení akce "moje_akce":
Příklad naplánování úlohy
Příklad jednorázového provedení akce "moje_akce":
Příklad odložení požadavku do-request
Odložení požadavku ukážeme na příkladu s ukládáním dokumentu. Běžným způsobem podáváme dokumenty k uložení takto (nyní výjimečně uváděno celé xml odesílané na server, tedy vč. hlavní obálky request):
Příklad pro rozpracované dokuementy
Požadavek na získání rozpracovaného dokumentu:
Příklady práce se soubory
3 items
Příklad požadavků na pseudo-dokumenty
Uváděný příklad požadavků na pseudo-dokumenty (pseudo-dokumenty viz. též
Evidence historie změn dokumentů
1 item
Příklad seznamu naplánovaných úloh
Základní forma požadavku na seznam úloh je následujcí.
Požadavek register
Příklady použití požadavku pro registraci k pozdějšímu použití prostřednictvím běžného HTTP GET požadavku.
Požadavek register-del
Příklad výmazu registrovaného požadavku pomocí register-del.
Požadavek register-list
Tento požadavek slouží k vypsání registrovaných požadavků.
Identifikace chyb při ukládání XML dokumentů
V dokumentu jsou změněné prvky (tj. pojmenované uzly s textem, které již neobsahují žádné jiné uzly kromě tohoto textu) označeny atributem changed="true" a případné změny v propojení dokumentů pomocí primárních a cizích klíčů jsou označeny change-key="true". Server uloží jen tyto změněné údaje a ostatní ponechá. Případně je ještě provedeno uložení nových opakování, tj. kde skey="#…" (skey ~ segment-key - další podrobnosti viz. druhá kapitola této části viz. segmenty a metadata dokumentů).
Identifikace chyb při ukládání XML dokumentů
Na rozdíl od získávání dokumentů je při jejich ukládání k dispozici hned několik forem hlášení chyby. První z nich je chyba vzniklá při základním ověřování ukládaných typů, tedy prvků ukládaných do sloupců tabulek databáze, kde každý z nich má předem daný určitý typ a velikost (viz. Část A - Definování intranetu). Nevyhovuje-li některý z ukládaných prvků označených atributem changed="true", vede to k chybě při uložení celého dokumentu a vrácení transakce. To znamená, že i již uložené prvky a případně i jiné dokumenty, je-li jich v požadavku více, se vrátí do původního stavu (transaction rollback). Při vzniku chyby při základním ověřování server vrátí v response obálce například takovouto identifikaci:
Ukládání pseudo dokumentů
Uváděný příklad požadavků na ukládání pseudo-dokumentu. Podobným způsobem, jako získávání sestav ve formě pseudo-dokumentů, funguje i jejich ukládání. Tedy ukládání celých sad skutečních dokumentů prostřednictvím jednoho nebo několika pseudo typů definovaných v XDS. Výsledkem je XML informace o uložení či případné vzniklé chybě.
Přímé SQL dotazy do databáze
1 item
Příklad spouštění akcí pomocí zpráv
Při přípravě a dalším vylepšování možností cílové aplikace jsou pomocí spec. nástroje v replikátoru nebo v intranetu připravovány a generovány tzv. transformační procesy. Tyto procesy je možné vyvolávat i nepřímo pomocí záslání zprávy patřičně vybavenému doplňku add-on, který nastavený proces vykoná. Taková zpráva musí mít zvláštní formu. Tuto formu buď zajistí server při obsluze ukládání dokumentu, kde se vyskytuje prvek nastavený jako messenger nebo je možné k zaslání takové zprávy samozřejmě použít požadavek send-message.
Příklad transform
V příkladu nakombinujeme použití dvou požadavků, jeden sql-query na podávání SQL SELECT dotazů do databáze a druhý get-document na získávání instancí strukturovaných xml dokumentů. V příkladu půjde o to, dotázat se na dokumenty vložené do evidence za poslední týden a tyto dokumenty poskládané vrátit v odpovědi.
Příklad XML nastavení
Příklad uložení kmenových XML nastavení uživatele 5 může vypadat takto: