Podíváme se na to trošku hlouběji a uvidíme co by mohlo vyhovovat.
imcon napsal(a)ZADÁNÍ
A. Ve firmě máme společné šablony vytvářené kaskádovitě.
1. - Ze šablony se vytvoří dokument a nebo se
2. - staršímu dokumentu šablona přiřadí, aby ho bylo možné naformátovat novým stylem.
B. Dokumenty se mění roky, různě se přesouvají, kopírují atd. Zároveň se ale upravují šablony a tedy když se
1. - otevře nějaký z dokumentů, LO se podívá, jestli neexistuje změna v šabloně a pokud ano
2. - dotáže se na to jestli ji má podle ní updatovat dokument.
DOTAZ
Proto potřebuji znát jestli je v dokumentu nalinkovaná šablona (její soubor) opravdu ten pravý a jestli tedy LO aktualizoval styly dokumentu podle nejaktuálnější šablony.
Celkem váhám nad tím, zda ad A.2 je realita, nebo jen představa jak by to mělo fungovat. Totéž platí o B.1, B.2. Z popisu mám představu, že je to součást standardního oběhu dokumentů, které se může říkat VALIDACE.
Popsané kroky je možné automatizovat, ale pokud vím, tak standardní distribuce sama o sobě nic takového zabudované nemá a to co se jeví jako možnost nefunguje většinou vůbec. To znamená, že postup musí někdo dělat manuálně. Má to na krku většinou IT – ale tím je v drtivé většině správce sítě pro kterého je to nikoliv odborná, ale uživatelská znalost – tedy znalost nad rámec své profese.
Dokumenty jsou teoreticky vybaveny potřebnými kolonkami. Tyto jsou součástí „speciálních polí" a dají se tedy pomocí polí volat, respektive vkládat do těla dokumentu. Pro tyto případy jde o údaje z nabídky NÁSTROJE > MOŽNOSTI > LIBREOFFICE > UŽIVATELSKÉ ÚDAJE, které se dají v rámci dokumentu načítat pomocí nabídky VLOŽIT > POLE > DALŠÍ POLE > karta DOKUMENT (položky, AUTOR, ČAS, DATUM, KAPITOLA, NÁZEV SOUBORU, ODESILATEL, POPIS ODSTAVCE, STATISTIKA, STRÁNKA A ŠABLONY.)
Některé údaje je možné vložit a najít také pod volbou SOUBOR > VLASTNOSTI > karta OBECNÉ, karta POPIS, nebo také karta VLASTNÍ VLASTNOSTI.
Stěžejní pro toto zadání je volba VLOŽIT > POLE > DALŠÍ POLE > karta DOKUMENT > položka ŠABLONY s detaily (CESTA, CESTA/NÁZEV SOUBORU, KATEGORIE, NÁZEV SOUBORU, NÁZEV SOUBORU BEZ PŘÍPONY a nakonec STYL)
Bohu žel tato volba pro šablony nefunguje dobře (spíš vůbec) a já ani nevím zda to někdy opravdu fungovalo. Údaje na kartě DOKUMENT se načítají automaticky ze zdrojů pod nabídkou NÁSTROJE > … > UŽIVATELSKÉ ÚDAJE, a z části z volby SOUBOR > … > POPIS.
Popis problému :
Běžný dokument umí načíst data která se týkají umístění, autor, datum vytvoření a poslední úpravy. Neumí načíst hodnoty své šablony. Je to proto, že ani šablona neumí nastavit a načíst své vlastní hodnoty, což běžný soubor umí. Nefunguje mi to ani v případě, že vytvořím šablonu z běžného dokumentu.
Navíc mi při takových operacích padá LO Version: 7.0.2.2 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ
Calc: CL) – během testování možností se mi to stalo 8x. Někdy vyběhne hlášení, že data HSQLDB jsou zastaralá a je nutno nastavit jako výchozí Firebird. Ale ani potom to není lepší.
Podobné problémy zřejmě aktuálně řeší pan M. Vajna, takže se možná už brzo dočkáme opravy. Tento problém se týká více typů speciálních polí > témata z různých karet dialogu POLE.
Takže na Váš dotaz mohu zodpovědět takto :
Teoreticky by měly být údaje ze šablony obsaženy v každém dokumentu, ale tento mechanizmus je nefunkční. Skutečnost přetrvává hodně dlouho, ale je to zřejmě v řešení. Tyto záležitosti se totiž týkají nejvíce korporátních instalací. Běžný jedinec se bez nich obejde.
Napoví nám také skutečnost, že implicitní šablony obsahují pouze název a stručný popis na kartě POPIS < z volby SOUBOR > VLASTNOSTI. (vlastnosti šablony bych viděl nejraději jako volitelné z karty VLASTNÍ VLASTNOSTI – je tam mnoho kolonek a položky šablony by tam mohly být také pod rozbalovací nabídkou PŘIDAT VLASTNOST > roletka NÁZEV. Je zde možnost už dnes využít nabídku ODKAZ, ZDROJ, ČAS, popřípadě jiné existující vhodné, ale při provolbě ŠABLONA by se to mělo automaticky načítat.)
Je schůdné doplnit údaje do patřičných kolonek pomocí maker. Kdesi bych měl mít vzor makra uložený, ale řešit makrem suplování implicitní funkce do šablony může být velice pracné a navíc se zřejmě problém řeší – určitě se o tomto ví.
Ale není od věci vybavit šablonu makrem, která otevírá nové soubory. Zde bych viděl možnost automaticky otevírat nový soubor už pod názvem, který by měl akceptovat systém souborů. Měl by obsahovat také adresu rodičovské šablony. Vzhledem k tomu, že kolonky potencionálně existují, je možné vytvořit jiný typ zápisu protože pokud se sytém opraví, kolidovala by implicitní funkce s explicitním makrem.
Ještě bych viděl jinou možnost :
Tou možností je databáze stylů. Ta existuje, ale kontrola její přístupnosti je omezená, navíc nearchivuje historické – dávno vyřazené implicitní a už vůbec ne styly historické vlastní. Jde stejně o to, že obecně různých stylů a formátů jsou tisíce. Představíme si styly například pod nabídkou FORMÁT.
Samozřejmě šablona obsahuje různé kombinace formátů a stylů, které budou uloženy pod specifickými názvy. Tyto údaje se stohují v rámci user profile „dataplikací" a tyto jsou obtížné už jen při pomyšlení na způsob instalace síťové <> individuální. Stačí aby se stala chyba a data aplikací se mohou smazat.
Řešením je vlastní databáze formátů + stylů i když je jakoby duplicitní. Ale snadno z ní vytvoříme nástroj pro přeformátování jakéhokoliv dokumentu na ten nejnovější styl a to i bez implicitního postupu.
Chtělo by to rozšíření které se spustí pomocí nějakého tlačítka (nejlépe v hlavní nabídce), nebo pod nabídkou SOUBOR > uložit jinak > přeformátovat.
Odpadlo by testování co dokument potřebuje změnit aby odpovídal poslední módě. Pro informaci (nikoliv podmíněně) by souhrny stylů a formátů měly mít souhrnný název podobně jako buildy pro systém LO. Správou šablon by měl být pověřený jeden člověk který takovou databázi obsluhuje – to aby byl zachována systematika (např. názvů pro každý různý typ šablony). Důležité je potom ohlídat aby byly správně akceptovány změny distribucí LO.
Databáze se naplní jednoduchými makry z dotazů na property a podobně. Rekurzivním postupem se také implementují do dokumentu který potřebuje formátovat.
POZNÁMKA
Domnívám se že firmy jako je Collabora vytvářejí zejména korporátní instalace kde tuto potřebu (jsem o tom přesvědčen) řeší. Je otázkou jak, za kolik se dá jejich verze použít, a jaká je na tom licence. Podobné firmy musely řešit například migrované správní celky, ministerstva a podobně.
Takže jde asi jen o to, najit řešení jinde a nemuset řešit již vyřešené. Je ale možné, že nikdo nic takového neřešil přímo, nebo si hlídá know-how.
Doufám, že jsem záležitost osvětlil lépe i s možným řešením na několik způsobů. Docela bych viděl i možnost oslovit přímo Mikloše Vajnu a vznést dotaz zda toto konkrétně řeší, nebo zda by to nezahrnul do svých oprav.