[elvystrac] r1681 - architecture and analysis documentation

• From: elvys@xxxxxxxxxxxxxxxxxxxxxx
• To: elvystrac@xxxxxxxxxxxxx
• Date: Mon, 8 Feb 2010 09:43:49 +0100

Author: JirkaH
Date: 2010-02-08 09:43:49 +0100 (Mon, 08 Feb 2010)
New Revision: 1681

Added:
   others/dokumentace/technicalGuide/architecture/4webapp.tex
   others/dokumentace/technicalGuide/architecture/5layoutdesigner.tex
   others/dokumentace/technicalGuide/architecture/6clientapp.tex
   others/dokumentace/technicalGuide/architecture/7communication.tex
   others/dokumentace/technicalGuide/architecture/8deployment.tex
   others/dokumentace/technicalGuide/architecture/9tools.tex
Removed:
   others/dokumentace/technicalGuide/architecture/4software.tex
   others/dokumentace/technicalGuide/architecture/5deployment.tex
   others/dokumentace/technicalGuide/architecture/6tools.tex
Modified:
   others/dokumentace/technicalGuide/analysis/1preface.tex
   others/dokumentace/technicalGuide/analysis/6kioskFunctional.tex
   others/dokumentace/technicalGuide/architecture/0architecture.tex
   others/dokumentace/technicalGuide/architecture/1preface.tex
   others/dokumentace/technicalGuide/architecture/2hardware.tex
   others/dokumentace/technicalGuide/architecture/3management.tex
Log:
architecture and analysis documentation


Modified: others/dokumentace/technicalGuide/analysis/1preface.tex
===================================================================
--- others/dokumentace/technicalGuide/analysis/1preface.tex     2010-02-08 
08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/analysis/1preface.tex     2010-02-08 
08:43:49 UTC (rev 1681)
@@ -20,7 +20,7 @@
 Ta bude umožňovat větší míru interaktivity, umožní zobrazit statický i 
dynamický
 obsah, který se bude dát plánovat na tyto kiosky vzdáleně. Způsob a možnosti
 využítí jsou popsány v kapitole \ref{motivation}, ze
-kterých pak vyplývají základní požadavky projektu.
+kterých pak vyplývají základní požadavky na realizaci.
 
 \section{Motivace\label{motivation}}
 \subsection{Úřední deska}
@@ -33,9 +33,9 @@
 obce spolu s informacemi, na jaké (webové i realné) adrese se dají vyvěšené
 dokumenty prohlížet.
 
-V praxi je toto řešeno několika (ve větších městech i desítkami) vývěskami, kde
-jsou fyzicky za sklo umisťovány vytištěné dokumenty. Vzhledem k omezené ploše
-vývěsky není vyjímkou, že jsou vyvěšeny jen titulní strany dokumentů s
+V praxi je toto řešeno pomocí několika vývěsek (ve větších městech i 
desítkami),
+kde jsou fyzicky za sklo umisťovány vytištěné dokumenty. Vzhledem k omezené
+ploše vývěsky není vyjímkou, že jsou vyvěšeny jen titulní strany dokumentů s
 důležitými (zákonem stanovenými) údaji, dokumenty jsou vytištěné malými písmeny
 či jsou různě překládány tak, aby se co nejvíce využil prostor vývěsky. Občan
 potom pro kompletní obsah dokumentu musí navštívit přislušný úřad, kde jsou
@@ -45,24 +45,24 @@
 
 Dle zkušeností úřednic z magistrátu v Přerově, které mají fyzické vyvěšování
 dokumentů na starosti, je mnohdy samotné vyvěšování poměrně náročná práce. Bez
-ohledu na počasí musí být daný dokument bezokladně vyvěšen, není tedy vyjímkou,
-kdy úřednice musí v dešti či mrazu fyzicky dojít k několika vývěskám. Konkrétně
+ohledu na počasí musí být daný dokument bezodkladně vyvěšen, není tedy 
vyjímkou,
+že úřednice musí v dešti či mrazu fyzicky dojít k několika vývěskám. Konkrétně
 v Přerově mají zkušenosti i s vosím hnízděm uvnitř vývěsky.\\
 
 Pro použití elektronické vývěsky tedy vyplývá několik požadavků. Musí umět
-zobrazit dokumenty v nezměnitelné podobně (jen pro čtení) různých rozměrů, kdy
+zobrazit dokumenty v nezměnitelné podobě (jen pro čtení) různých rozměrů, kdy
 půjde vidět titulní strana s důležitými informacemi. Navíc by bylo vhodné, aby
 se dalo v dokumentu na požádání listovat, případně požadovanou část zvětšit.
 Odpadne tak část problému s místem a malým písmem.
 
-Dále je nutné umět zobrazit popisky různé velikosti a barvy, kdy bude např.
+Dále je nutné umět zobrazit nápisy různé velikosti a barvy, kdy bude např.
 zobrazen název příslušného úřadu.
 
 Vzhledem k potenciálně velkému počtu dokumentů, které je nutné vyvěšovat by 
měla
-elektronická verze umožňovat řadit dokumenty do více záložek, čímž se dosáhne
-dalšího zvětšení možného počtu dokumentů na jedné vývěsce. Dokumenty, 
respektive
-celé panely, by pak měly být řazeny podle kategorií (písemnosti, exekuce 
apod.),
-což přinese větší přehlednost.
+elektronická verze umožňovat řadit dokumenty do více záložek (panelů), čímž se
+dosáhne dalšího zvětšení možného počtu dokumentů na jedné vývěsce. Dokumenty,
+respektive celé panely, by pak měly být řazeny podle kategorií (písemnosti,
+exekuce apod.), což přinese větší přehlednost.
 
 Občan by jistě také ocenil možnost vyhledávat (např. své jméno) mezi vyvěšenými
 dokumenty.
@@ -83,20 +83,21 @@
 
 Elektronická verze v tomto případě umožní řadit nabízené dokumenty např. dle
 města nebo dle typu (byty, domy, parcely) do panelů. Umožní také po zvětšení
-zobrazit více informací o dané nemovitosti s více fotkami apod. Musí být 
možnost
-vzdáleně naplánovat stejný dokument na více vývěsek. Bude tak možno rychle a
-levně reagovat na novou nabídku. Svítící obrazovka navíc přítahne pozornost
-kolemjdoucích. Realitní kanceláře pak může zajímat návštěvnost (zobrazení
-detailu) jednotlivých kiosků, dokumentů či kategorií dokumentů (byty v Praze 
5).
+zobrazit více informací o dané nemovitosti s více fotkami apod. Dále by byla
+vhodná možnost vzdáleně naplánovat stejný dokument na více vývěsek. Bude tak
+možno rychle a levně reagovat na novou nabídku. Svítící obrazovka navíc 
přítahne
+pozornost kolemjdoucích. Realitní kanceláře pak může zajímat návštěvnost
+(zobrazení detailu) jednotlivých kiosků, dokumentů či kategorií dokumentů (byty
+v Praze 5).
 Pro realitní kanceláře by dále mohlo být zajimavé zobrazení textu jedoucího z
 jedné strany obrazovky na druhou, obsahující např. upozornění na novou nabídku
 či jiné novinky.
 
 \subsection{Cestovní kanceláře}
-Cestovní kanceláře dnes vyvěšují informace o svých zájezdech, různé akce apod.
-zpravidla za výlohou svých poboček. Tyto nabídky se poměrně často mění (last
-minute) a proto musí zaměstnanci průběžně vylepovat nové nabídky, změny cen
-apod.\\
+Cestovní kanceláře dnes vyvěšují informace o svých zájezdech, různých akcích
+apod. zpravidla za výlohou svých poboček. Tyto nabídky se poměrně často mění
+(last minute) a proto musí zaměstnanci průběžně vylepovat nové nabídky, změny
+cen apod.\\
 
 Při použití elektronické vývěsky bude možno využít všech výhod uvedených výše.
 Zajimavým lákadlem cestovních kancelaří by pak mohla být možnost přehrávání
@@ -106,9 +107,10 @@
 
 \subsection{Shrnutí motivace}
 Uvedené příklady jistě nejsou vyčerpávající a neuvádějí všechny možná použítí
-této elektronické vývěsky. Z příkladů však vyplývá hned několik požadavků na
-funkcionalitu celého systém. V celém dokumentu jsou pak tyto příklady 
používany,
-aby umožnily čtenáři lepší pochopení problematiky.
+této elektronické vývěsky. Z příkladů však vyplývá několik možných požadavků na
+funkcionalitu celého systému. Tyto požadavky jsou níže analyzovány. \\
+V celém dokumentu jsou pak tyto příklady používany, aby umožnily čtenáři lepší
+pochopení problematiky.
 
 \section{Obecné požadavky řešení}
 \begin{itemize}

Modified: others/dokumentace/technicalGuide/analysis/6kioskFunctional.tex
===================================================================
--- others/dokumentace/technicalGuide/analysis/6kioskFunctional.tex     
2010-02-08 08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/analysis/6kioskFunctional.tex     
2010-02-08 08:43:49 UTC (rev 1681)
@@ -4,12 +4,16 @@
 Podporované formáty dat, které kiosek bude zobrazovat jsou popsány v kapitole 
\ref{content_type_definition}.
 
 \section{Zobrazení rozvržených dokumentů na obrazovce}
-Obrazovka kiosku je zobrazena na obrázku \ref{scheme_kiosk} v kapitole 
\ref{terms_kiosk}. Data jsou zobrazena v jednotlivých \textit{panelech}, které 
jsou tématicky seskupeny do \textit{kategorií}. 
+Obrazovka kiosku je zobrazena na obrázku \ref{scheme_kiosk} v kapitole 
\ref{terms_kiosk}. Data jsou zobrazena v jednotlivých \textit{panelech}, které 
jsou tématicky seskupeny do \textit{kategorií}.
 
-Dokument na aktivní \textit{pozici} bude možno zvětšit, viz \ref{enlargement}.
+Dokument na aktivní \textit{pozici} bude možno zvětšit, viz \ref{enlargement}, 
aktivní pozice se bude dát měnit pomocí připojených tlačítek(šipek).
 
 \subsection{Kategorie a panely}
-Mezi \textit{kategoriemi} se bude možné přepínat pomocí tlačítek, stejně tak 
mezi jednotlivými panely v kategorii. Ve webové aplikaci bude možno nastavit, 
zda a v jaké periodě se mají jednotlivé panely sami střídat - pokud žádný 
uživatel nemačká tlačítka.
+Mezi \textit{kategoriemi} se bude možné přepínat pomocí tlačítek, stejně tak 
mezi jednotlivými panely v kategorii. Jména panelů budou odvezeny od názvů 
kategorií spolu s pořadovým číslem. 
+Tedy např. pro kategorii `Byty` budou panely `Byty 1`, `Byty 2`, atd. 
Neaktivní panely, tj. takové panely, na kterých nejsou zobrazeny žádné 
dokumenty nebudou zobrazeny.
+Vždy ale bude zobrazen minimálně jeden panel, ikdyž bude prázdný, tj. budou 
zobrazeny jen prázdné dokumenty, viz níže.
+Ve webové aplikaci bude možno nastavit, zda a v jaké periodě se mají 
jednotlivé panely sami střídat, pokud je panel neaktivní, tj. pokud žádný 
uživatel nemačká tlačítka. 
+Automatické i ruční přepínaní panelů však nebude možné pokud je některý 
dokument zvětšen.
 
 \subsection{Zobrazení různých typů dat}
   \subsubsection{statický text} Statický (nepohybující se) text bude zobrazen 
vždy v takové velikosti, aby se celý text vešel do dané pozice. Uživatel může 
nastavit velikost
@@ -23,25 +27,33 @@
  typicky nebude zobrazena celá, jen její vrchní část. Vzhledem k tomu, že se 
nepočítá s použitím dotykové obrazovky, myši či trackballu, nebude uživateli 
umožněno
  používat odkazy apod.
   \subsubsection{video} Video bude přehráváno tak, aby nedocházelo k jeho 
deformaci a zároveň aby byly zachovány omezení velikosti dané rozměry 
\textit{pozice}, podobně
- jako u PDF dokumentů. Bude možno nastavit, zda má být přehráváno opakovaně, 
či přehráno až při zvětšení. Při této druhé možnosti by pak byl zobrazen 
definovaný (ve webové aplikaci) snímek videa.
+ jako u PDF dokumentů. Bude možno nastavit, zda má být přehráváno opakovaně a 
přehrávání má začít automaticky, či přehráno až při zvětšení.
+ Při této druhé možnosti by pak byl zobrazen definovaný (ve webové aplikaci) 
snímek videa.
   \subsubsection{prázdná pozice} Pozice, na které není momentálně naplánován 
žádný obsah bude zobrazena jako prázdný rámeček daných rozměrů.
 
 \subsection{Zvětšování dokumentů\label{enlargement}}
 
-Typy dokumentů \textit{PDF}, \textit{video} a \textit{webová stránka} bude 
možno na kiosku zobrazit ve zvětšené verzi. Po kliknutí na příslušné tlačítko 
dojde k zvětšení celé první strany dokumentu na celou obrazovku (či její část, 
v závislosti na rozměrech dokumentu). V \textit{PDF} dokumentech navíc bude 
možno listovat mezi dalšími stránkami a zvětšovat části dokumentu. Při tomto 
dalším zvětšování již nedochází k změně velikosti pozice. Zvětšený dokument se 
při nečinnosti (tuto dobu bude možné nastavit) sám zmenší na původní velikost. 
Nečinností je zde míněno nemačkání žádných tlačítek. Uživatel samozřejmě bude 
mít možnost zmenšit dokument sám pomocí příslušného tlačítka.
+Typy dokumentů \textit{PDF}, \textit{video} a \textit{webová stránka} bude 
možno na kiosku zobrazit ve zvětšené verzi. Po kliknutí na příslušné tlačítko 
dojde k zvětšení celé první strany dokumentu na celou obrazovku (či její část, 
v závislosti na rozměrech dokumentu).
+ V \textit{PDF} dokumentech navíc bude možno listovat mezi dalšími stránkami a 
zvětšovat části dokumentu. Při tomto dalším zvětšování již nedochází k změně 
velikosti pozice.
+ Zvětšený dokument se při nečinnosti (tuto dobu bude možné nastavit) sám 
zmenší na původní velikost. Nečinností je zde míněno nemačkání žádných tlačítek.
+ Uživatel samozřejmě bude mít možnost zmenšit dokument sám pomocí příslušného 
tlačítka.
 
-Podobné chování bude i pro \textit{video} dokumenty, u nich však nepůjde 
zvětšit část videa. K automatickému zmenšení videa dojde při přehrání celého 
obsahu.
+Podobné chování bude i pro \textit{video} dokumenty, u nich však video nepůjde 
již dále zvětšovat, nebude tedy možné zvětšit jen část videa. K automatickému 
zmenšení videa dojde při přehrání celého obsahu.
 
 U \textit{webových stránek} bude umožněno zvětšení na celou (či její větší 
část, toto bude možno nastavit) a na dané stránce poté listovat. Další zvětšení 
nebude možné.
 
 \section{Komunikace se serverem\label{kiosk_communication}}
 
-Kiosek bude pravidelně komunikovat se serverem. Kiosek se tedy bude dotazovat 
serveru na aktuální konfiguraci, tj. \textit{rozvržení obrazovky}, datové 
soubory texty apod. Toto nastavení se bude ukládat do souborů, aby při restartu 
bylo k dispozici nějaká nastavení. Perioda opakování těchto dotazů se bude dát 
nastavit. Při nedostupnosti serveru kiosek zobrazí poslední známou konfiguraci.
+Kiosek bude pravidelně komunikovat se serverem. Kiosek se tedy bude dotazovat 
serveru na aktuální konfiguraci, tj. \textit{rozvržení obrazovky}, datové 
soubory texty apod.
+ Toto nastavení se bude ukládat do souborů, aby při restartu bylo k dispozici 
nějaká nastavení. Perioda opakování těchto dotazů se bude dát nastavit. Při 
nedostupnosti serveru kiosek zobrazí poslední známou konfiguraci.
 
-Dále se bude kiosek serveru dotazovat na nastavení v budoucnosti, aby si 
případně mohl stahovat požadované datové soubory dopředu.
+\section{Správa souborů\label{kiosk_file_management}}
 
-Čas dotazování bude vždy jistým způsobem náhodný, aby nemohlo dojít k 
potenciálnímu zahlcení serveru více kiosky ve stejný čas.
+Všechny soubory budou stahovány do dané složky. Její velikost však bude 
omezena (výchozím omezením bude velikost souborového systému), nepoužívané 
soubory se budou při dosažení daného zaplnění složky automaticky mazat.
 
+Stahování souborů bude probíhat předem, tj. kiosek se bude pravidelně serveru 
dotazovat na seznam souborů, které bude muset v budoucnosti (např. jeden den) 
zobrazovat. Předejde se tak 
+zdržení při zobrazovní obsahu, který ještě není stahnutý. Konkrétní čas 
stahování souborů bude vždy jistým způsobem náhodný, aby nemohlo dojít k 
potenciálnímu zahlcení serveru více kiosky se stejným plánovaním.
+
 \section{Konfigurační soubory}
 
 Aplikace bude mít dva druhy konfiguračních souborů. 

Modified: others/dokumentace/technicalGuide/architecture/0architecture.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/0architecture.tex    
2010-02-08 08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/0architecture.tex    
2010-02-08 08:43:49 UTC (rev 1681)
@@ -58,13 +58,16 @@
 \include{1preface}
 \include{2hardware}
 \include{3management}
-\include{4software}
-\include{5deployment}
-
+\include{4webapp}
+\include{5layoutdesigner}
+\include{6clientapp}
+\include{7communication}
+\include{8deployment}
 %programove nastroje, patri to sem vubec?
-\include{6tools}
+\include{9tools}
 
 
+
 \listoffigures
 \clearpage
 \listoftables

Modified: others/dokumentace/technicalGuide/architecture/1preface.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/1preface.tex 2010-02-08 
08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/1preface.tex 2010-02-08 
08:43:49 UTC (rev 1681)
@@ -1,7 +1,63 @@
 \chapter{Předmluva} 
 
-%O cem je tenhle dokuemnt
+Tento dokument pojednává o architektuře projektu Elvys. Obsahuje detailní 
informace o všech částech systému, o důvodech, které vedly k použití dané 
technologie společně s úvahou 
+o jiných možnostech. Dále je detailně a konkrétně popsáno, jakým způsobem 
jednotlivé části fungují a jak mezi sebou komunikují. V textu se dost často 
odkazuje na požadavky uvedené v
+\textit{Analýze}, proto je výrazně doporučeno nejdříve přečíst ji.
 
 \section{Jak číst tento dokument}
 % ze nejdriv je precist overvirew
+Formatování textu....
 
+V kapitole ...
+V kapitole ...
+
+Dalsi podrobnosti jsou v kapitole...
+
+
+\section{Úvod}
+
+Vzhledem k tomu, že původní zadání projektu bylo velmi obecné (``náhrada 
papírové vývěsky'', viz kapitola \textit{Motivace} v \textit{Analýze}) a řada 
požadavků vyplynula až 
+později, je na místě vysvětlit základní rozhodnutí pro výběr daných 
technologií.
+
+\subsection{Volba formátu dat}
+
+Jedním ze základních rozhodnutích byla volba formátu zobrazitelných dat.
+
+Například u úředních desek bylo možné postupovat více směry. Úřednice mohly 
``vyvěšovat'' dokumenty pomocí webového
+WYSIWYG editoru. V tomto případě by data na kiosku byly zobrazeny ve webovém 
prohlížeči. Znamenalo by to ale zbytečnou práci pro úřednice při zadávání 
dokumentů do systémů, které
+jsou většinou ve formátu MS Word, navíc často obsahují obrázky. Otázkou je 
také bezchybnost a uživatelská přívětivost takových volně dostupných editorů.
+
+Z tohoto hlediska se jeví jako výhodný formát PDF. Jeho výhody jsou 
následující. Jedná se o otevřený, zkomprimovaný formát, je v něm velmi dobře 
definované zvětšování a hlavně do něj dnes lze
+ takřka bezchybně exportovat snad každý dokument. V programech, které export 
do PDF nepodporují, lze export simulovat pomocí PDF tiskárny, např. PDF Creator 
\cite{pdfcreator}.
+
+\subsection{Forma a OS klientské aplikace}
+
+Další otázkou je forma zobrazování dat. Nabízející se v zásadě tři možnosti. 
Ty zde uvádíme spolu s jejich výhodami a nevýhodami.
+
+\begin{itemize}
+  \item \textbf{Webová aplikace s integrovaným PDF prohlížečem} - Aplikace 
podobná Google Books \cite{googlebooks}. 
+      Výhodou tohoto řešení je integrace s webovým prohlížečem, kdy odpadnou 
starosti s vlastní aplikací (instalace, aktualizace). Nevýhodou jsou pak 
poměrně velké nároky na výpočetní kapacitu klienta, 
+      v případě rastrování PDF na kiosku, nedostupnost takovýchto komponent a 
v případě technologie Flash její problematická funkčnost na platformě Linux. Za 
zmínku stojí projekt
+      FlashPaper \cite{flashpaper}, který umožňuje převést převést PDF soubor 
do SWF a ten pak použít na stránkach. Adobe však tento produkt zřejmě z důvodu 
konkurence jiných svých produktů
+      již nepodporuje, navíc její cena je poměrně vysoká.
+
+      V případě rastrování na serveru pak špatná možnost zvětšování dokumentu 
(daný dokument by musel být vyrastrován ve více rozlišeních, které můžou být 
pro různé klienty různé) a 
+      poměrně velké výpočetní a prostorové nároky na server.
+
+  \item \textbf{Začlenění existujících prohlížečů do vlastní aplikace} 
+      Tato možnost by představovala vytvořit aplikaci, která by využívala již 
existujících aplikací, tj. webových prohlížečů, prohlížečů PDF apod. To by 
ušetřilo značnou část práce
+      v porovnání s možností níže. Na druhou stranu by pak byl celý projekt 
závislý na chybách a chování jiných produktů, otázkou je také vizualní 
kompozice cizích programů, nezobrazovaní 
+      různých nástrojových lišt apod. V neposlední řadě můžou být překážkou 
licenční podmínky.
+
+  \item \textbf{Vlastní aplikace} 
+      Vlastní aplikace je na první pohled nejpracnější řešení, na druhou 
stranu je jistě nejflexibilnější. Člověk není omezen webovým prostředím, či 
chováním aplikací třetích stran.
+      V připadě použití vhodné knihovny na zobrazovaní PDF, videí či jiného 
obsahu tak, aby nebylo nutné tyto poměrně komplexní časti vyvýjet samostatně, 
pak již nemusí být vývoj vlastní
+      aplikace tak náročný. V neposlední řadě se bude jistě jednat o 
nejvýkonější řešení a nebude problém přidat podporu zobrazování dalšího typu 
dat, či jinak aplikaci upravit.
+\end{itemize}
+
+Vzhledem k uvedeným důvodům bylo rozhodnuto vydat se cestou vlastní aplikace 
vyvýjené v C++ s použitím frameworku Qt. O volbě konkrétních knihoven se pak 
lze dočíst v kapitole 
+\ref{clientapp}.\\
+
+Jelikož bylo rozhodnuto použití multiplatformního řešení ve formě Qt a C++, 
volba operačního systému nebyla omezena. Vzhledem k požadavku na co nejmenší 
cenu řešení,
+velikosti instalace, hardwarovým nárokům a možnosti vzdálené spravy byla 
zvolena cílová platforma Linux, konkrétně Ubuntu 9.04 v minimální instalaci. 
+O více detailech pojednává kapitola \ref{TODO}.
\ No newline at end of file

Modified: others/dokumentace/technicalGuide/architecture/2hardware.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/2hardware.tex        
2010-02-08 08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/2hardware.tex        
2010-02-08 08:43:49 UTC (rev 1681)
@@ -1,7 +1,50 @@
 \chapter{Hardware}
-%popsat moznosti pouziti hw, platformy, upgradovatelnost a proc je to na 
Mini-ITX, PC architekture vubec...
+Součástí zadání projektu bylo i definování vhodného hardweru pro kiosek. Výběr 
byl omezen hlavně následujícími faktory:
 
-\section{Tlačítka}
-Kiosek bude ovládán pomocí dotykových tlačítek připojených pomocí seriového 
COM portu. Tlačítka po doteku vyšlou signál - písmena abecedy
-v závislosti na zmáčknutém tlačítku. Aplikace na kiosku pak seriový port 
pravidelně kontroluje a simuluje tak zmáčknutí
-klávesy.
+\begin{itemize}
+  \item \textbf{Podpora dostatečného rozlišení} - počítač musel umět rozlišení 
minimálně 1920x1080 (Full HD) a to nejlépe přes digitální rozhraní DVI či HDMI.
+  \item \textbf{Dostatečný výkon}  - i přes to, že byl software vyvýjen s 
ohledem na minimální nároky na hardware, je nutné počítat s určitým výkonem 
zvláště v případě přehrávání videa
+                                    či použití velkého rozlišení.
+  \item \textbf{Tepelná a elektrická náročnost}  - celý počítač je uzavřen v 
poměrně malé skříni. V letním období je navíc nutné počítat s vysokými 
teplotami, které mohou být ještě zvýšeny
+                                   slunečním svitem na šasi kiosku. Bylo tedy 
nutné vybírat takový HW, který je minimálně tepelně náročný a lze jej chladit 
nejlépe pasivně. Vzledem k uvažovanému
+                                   provozu 24 hodin denně, je nutné brát ohled 
taky na příkon celého řešení.
+  \item \textbf{Cena} - jeden z nejdůležitějších faktorů. Na trhu existuje 
několik průmyslových PC splňující požadavky, jejich cena je však ve srovnaní s 
jinými řešeními až 5x vyšší.
+\end{itemize}
+
+Z důvodu poměrně úzkého prostoru v kiosku pro počítač byl jako formát skříně 
zvolena racková skřín velikosti 1U s minimální hloubkou (TODO foto). To 
umožňuje jednoduchý přístup k celému PC a 
+jeho rychlou případnou výmenu za jiný kus. 
+
+Vzhledem k výše uvedeným požadavkům se jako ideální formát základní desky 
ukázal formát Mini-ITX (rozměry 17x17cm). Tyto základní desky již umí nabídnout 
dostatečně výkonné integrované
+grafické karty s podporou akcelerace HDTV videa a s digitálnímy grafickými 
výstupy (i dvěma). Jistým problémem těchto základních desek je jejich 
dostupnost na trhu, zvláště v České 
+republice. V poslední době se však i toto lepší.
+
+Dalším důležitým rozhodnutím z hlediska ceny, ale i životnosti a tepelné 
náročnosti bylo upuštění od klasických pevných disků. Namísto nich se použivají 
USB flash disky, které dnes již mají 
+dostatečnou kapacitu a není problém z nich spouštět celý operační systém. Je 
si však nutné uvědomit, že životnost těchto zařázení je hlavně omezena počtem 
zápisů. Proto je nutné správně 
+nastavit souborový systém, ale i použité aplikace (hlavně různé logování). 
Konkrétní použité nastavení je obsahem přiloženého CD jako nastavení nástroje 
Cfengine, viz
+\ref{cfengine}. V případě nutnosti lze však stále použít klasický pevný disk.
+
+Hlavně kvůli ceně bylo nakonec upuštěno od procesoru VIA, který je jinak 
ideálním procesorem pro toto použití. Místo něj byl použit klasický procesor 
Intel Celeron, který
+v nečinosti není tepelně náročný. 
+
+Dalším důležitým aspektem je také možnost ovládání ventilátorů. Zabrání se tak 
zbytečnému víření prachu v celé skříni. V zimním období jsou ventilátory 
dokonce kontraproduktivní, protože
+víří ledový vzduch a počítač i obrazovku až příliš ochlazují. Z testů 
prototypu v mrazech -20$^\circ$ C byl rozdíl teploty uvnitř skříně mezi 
zapnutými a vypnutými větráky cca 10$^\circ$ C.
+
+Nakonec byla použita následující sestava:
+
+\begin{itemize}
+\item \textbf{Základní deska}
+\item \textbf{Procesor}
+\item \textbf{Paměť}
+\item \textbf{Pevný disk}
+\item \textbf{Zdroj}
+\end{itemize}
+
+Sestava byla také vybrána z možného rozšíření kiosku na 2 obrazovky. K tomu 
ale zatím ještě nedošlo.\\
+
+Vývoj počítačů a hardwarů jde samožřejmě velmi rychle kupředu. Proto je téměř 
jisté, že se v další generaci kiosků hardware změní, nejspíše ve prospěch 
platformy Intel Atom s čipsetem
+ nVidia ION.
+
+\section{Ovládací tlačítka}
+
+Kiosek je ovládán pomocí dotykových tlačítek připojených pomocí seriového COM 
portu. Tlačítka po doteku vyšlou signál - písmena abecedy
+v závislosti na zmáčknutém tlačítku. Aplikace na kiosku pak seriový port 
pravidelně kontroluje a simuluje tak zmáčknutí klávesy. Tyto tlačítka dodal 
zadavatel projektu. 

Modified: others/dokumentace/technicalGuide/architecture/3management.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/3management.tex      
2010-02-08 08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/3management.tex      
2010-02-08 08:43:49 UTC (rev 1681)
@@ -1,10 +1,77 @@
-\chapter{Správa a monitoring}
+\chapter{NEsoftware}
 
-%popsat, ze to musi byt bezpecne a udrzovatelne, ze teoreticky to muze jet na 
ruznych HW apod...
-%celkovy feeling, zadne rozdeleni na analyzu a design
+%VPN atd.p
 
-\section{Správa}
-% na cem to bezi, proc to nam bezi, ajke byly pozadavkyu
+\section{Správa}\label{management}
+Jak vyplývá z požadavků uvedených v \textit{Analýze}, je správa potenciálně 
velkého množství kiosků velmi důležitým aspektem projektu. Bylo nutné vybrat
+takové řešení, které umožní spravovat kiosky s různým hw, umožní instalaci 
nových verzí softwaru, bezpečnostních záplat apod. Navíc je důležité, že dané 
+nastavení se musí po zapnutí projevit i na kioscích, které jsou momentálně z 
jakýchkoliv důvodů vypnuté. U většího množství již není udržitelné se vzdáleně
+připojovat na jednotlivé kiosky a přes SSH nastavovat daný kiosek. U 
nedostupných kiosků pak nezapomenout provést požadované změny. To samé u nově 
instalovaných kiosků.\\
 
-\section{Monitorování}
-% musi to byt skalovatelne, posilat maily, kreslit grafy, pripadne posilat 
SMS...
+Při výběru vhodného nástroje byly použity zkušenosti se správou velkých 
výpočetních farem jednotlivých středisek v gridu LCG \cite{lcg}. Ty ke správě 
stovek až tisíců počítačů používají převážně
+následující produkty:
+
+\begin{itemize}  
+  \item \textbf{Quattor} - je komplexní nástroj na správu velkých výpočetních 
farem. Byl vyvinut v rámci projektu projektu LCG \cite{lcg} v CERNu, kde je 
taky používán na správu
+                         více než sedmi tisíc počítačů. Výhodou je 
škálovatelnost a komplexnost řešení (např. podpora ACL pro různé uživatele 
systému),
+                         nevýhodou pak nutnost psaní vlastních konfiguračních 
modulů pro jednotlivé aplikace (např. modul pro Nagios apod.). 
+                         Další nevýhodou je silná vazba na databázi Oracle, 
podpora jen operačních systému postavených na Red Hat 4 a 5. Pro tento projekt 
by však byl Quattor 
+                         ``kanónem na vrabce''.
+                         Více informací je k dispozici na \cite{quattor}.  
+  \item \textbf{Cfengine} - je léty ověřený de-facto standard na poli nástrojů 
pro správu konfigurací serverů. Oproti Quattoru se jendá o jednodušší řešení. 
Jedntolivé konfigurace jsou
+                           ukládány v textových souborech, nevyžaduje na 
druhou stranu podporu na klientech (krom samotného klienta Cfenginu). Nevýhodou 
může být chybějící podpora
+                           různých oprávnění uživatelů, V rámci projektu 
\cite{lcg} je používán v největším vědeckém výpočetním 
+                         centru v České republice ve Fyzikálním ústavu 
Akademie Věd\cite{TODO}. Více informací je k dispozici na \cite{cfengine}.
+  \item \textbf{Puppet} - je svým zaměřením podobný nástroju Cfengine. Jeho 
výhodou je vyšší míra abstrakce popisovaných nastavení - lze např. říci 
``přidej uživatele Alice'' a není nutno
+                         definovat, že je nutné jej zapsat do souboru 
/etc/passwd apod. Více informací je k dispozici na \cite{puppet}.
+\end{itemize}
+
+Vzhledem ke zkušenosti autorů projektu se systémy Quattor a Cfengine a k 
podobnosti Puppetu s Cfenginem, byl zvolen právě systém Cfengine. 
+
+Ten umožňuje rozdělit konfiguraci kiosků dle jednotlivých služeb, kiosky 
seskupovat do skupin a na ty aplikovat různé pravidla. Konfigurace v Cfenginu 
je navíc deklarativní - administrátor
+definuje stav, ve kterém má být systém, což je rozdíl oproti např. skriptu v 
shellu, kde člověk definuje přesnou posloupnost akcí, které se mají provést. Z 
tohoto důvodu dojde k aktualizaci
+jen dané, určité části např. při výpadku klienta a jeho opětovném spuštění. 
Cfengine podporuje snad všechny operační systémy typu Linux.
+
+V rámci projektu byla veškerá konfigurace kiosků po nainstalovanání minimální 
instalace systému zanesena právě do Cfenginu. V praxi tedy stačí nainstalovat 
příslušný balík, nahrát klientskou
+konfiguraci pro cfengine ukazující na správný server a pak jen spustit agenta, 
který provede všechny potřebné instalace od nastavení X serveru, přes OpenVPN 
klienta až po instalaci samotné
+aplikace projektu Elvys.
+
+Veškerá konfigurace je navíc uložena v textových souborech, což umožnilo 
integraci se systémem správy verzí SVN. Existují tedy zálohy všech konfigurací 
a v případě nešťastného zásahu
+administrátora lze změnu jednoduše vrátit zpátky\footnote{Jen v případě, že se 
změna fatálně nedotkla konektivity k internetu či nastavení samotného agenta 
Cfenginu.}.\\
+
+Důležitým aspektem vdálené správy je také možnost vzdáleně se připojit k 
jednotlivým uzlům a být tak moci opravdu zkontrolovat nastavení na dané 
stanici, či provést jiné zásahy. To může 
+být problém při připojení přes ISP, kteří neposkytují veřejnou IP adresu (což 
je dnes nejčastejší případ). Z tohoto důvodu byla navržena a implementována 
virtuální privátní síť pomocí programu
+OpenVPN, který je více popsán v sekci \ref{security}. To mj. umožní přímé 
připojení ke kiosku, který je za libovolným počtem překladačů.
+
+\section{\label{monitoring}Monitorování}
+
+Monitorování stavu jednotlivých kiosků je možná až překvapivě důležité. Včasné 
rozpoznání problému či možnost zpětné kontroly sledovaných metrik při 
analyzování problémů šetří čas i peníze, 
+navíc se pochopením problému může předejít jeho opakování.
+
+Na poli monitorování existuje celá řada produktů. V rámci snahy používat 
především open source projekty byly zvažovány následující systémy, které 
splňují požadavky uvedené v \textit{Analýze}. 
+Podobně jako v \ref{management} byly brány v potaz zkušenosti jednotlivých 
výpočetních center v rámci projektu LCG.
+
+\begin{itemize}  
+  \item \textbf{Zabbix} - je spíše nováček na poli open-source monitorovacích 
nástrojů. Jeho výhodou je vysoká škálovatelnost vzhledem k možnosti 
distribuovat monitorování na více serverů,
+                         podpora grafování monitorovacích metrik v reálnem 
čase.
+                         Dále je možné vytvořit poměrně kompletní scénáře 
monitorování služeb, kdy jde např. opravdu ověřit, že se na dané adrese 
zobrazuje daná stránka a lze se například
+                         přihlásit do systému.
+                         Nevýhodou je pak nepříliš velká uživatelská 
přívětivost jinak velmi komplexního webového rozhraní. Dále, dle zkušeností s 
pilotním provozem v rámci tohoto projektu,
+                         také poměrně velké výpočetní nároky na server v 
poměru na počet monitorovaných metrik.
+  \item \textbf{Cacti} - nástroj určen především k SNMP monitorování síťových 
zařízení, lze však použít i k monitorování serverů. Cacti využívá jako 
skladiště dat databázi RRD, z čehož těží při
+                         kreslení grafů jednotlivých metrik. Problémem jsou 
však malé možnosti konfigurace (např. změna monitorovacího intervalu) a špatná 
podpora systému varování při
+                         překročení nastavených prahů.
+  \item \textbf{Nagios} - jedná se o známé standardní monitorovací řešení s 
dlouhou historií. Naprosto odpovídá všem požadavkům, navíc existuje velké 
množství rozšíření, které ještě vylepšují
+                         jeho funkčnost. Nagios také v základní instalaci 
nekreslí grafy jednotlivých metrik - existuje však celá řada nástaveb, které 
tento problém řeší.
+\end{itemize}
+
+Nejenom vzhledem ke zkušenostem autorů se systémem Nagios, se stal finálním 
řešením pro monitoring. V rámci projektu bylo nasazeno i monitorování pomocí 
Zabbixu, v praxi se však ukázalo jako
+ménně použitelné.
+
+TODO : popsat jeste nejak co vse se pres nagious kontroluje
+
+\section{\label{security}Bezpečnost}
+
+Dalším požadavkem na projekt byla bezpečnost komunikace mezi kioskem a 
serverem, respektive bezpečnost komunikace vůbec. Také vzhledem k požadavku 
možnosti přímého připojení na daný uzel, který 
+vyplývá z kapitol \ref{management} a \ref{monitoring} bylo rozhodnuto vytvořit 
virtuální privátní síť všech kiosků a použitých serverů. 
+

Deleted: others/dokumentace/technicalGuide/architecture/4software.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/4software.tex        
2010-02-08 08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/4software.tex        
2010-02-08 08:43:49 UTC (rev 1681)
@@ -1,404 +0,0 @@
-\chapter{Software}
-%asi jeste nejake kecy
-
-\section{Webová aplikace}
-       %TODO rozdeleni na subsections, mozna dalsi includy?
-       % rozdeleni na moduly, jeden z nich je statistika, dalsi 
layoutdesigner...
-       
-  \subsection{Přehled}
-  todo: napsat neco o tom, ze to je rozdelene do na sobe nezavislych webovych 
modulu webServer2 a dispatcher. Taky se zminit o appletu
-       
-       
-       \subsection{Rozdělení do modulů, sdílená aplikační logika}
-        - na to taky navazuje připravenost na napsání dalšího modulu- pro 
WS-API, přesunout k sobě. Odkaz na sekci, kde je popsáno, jak tu aplikacni 
logiku mame vlastne oddelenou...\\
-        Build je prováděn pomocí ANT-skriptů, které jsou popsány v 
\ref{build_ant}\\
-        
-       \subsection{Bezpečnost na serveru}
-       Popsat, jak je řešena autentizace, autorizaci radsi nezminovat, popsat 
SSL:
-          \subsubsection{webServer2} - ten SSL zatim nema
-          \subsubsection{dispatcher} - tenhle taky ne
-       \subsection{Popis komunikace serveru}
-       \subsubsection{webServer2}
-          FF, IE8, nutnost JRE pro applet
-       \subsubsection{webAPI??}
-          viz. dale
-       \subsubsection{dispatcher}
-          komunikace mezi kiosky a serverem
-       
-%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%  WebServer2 obecně
-%%%%%%%%%%%%%%%%%%%%%%%%%%             
-       \subsection{WebServer2}
-          popsat architekturu weboveho serveru - JSF+Richfaces, zavislosti,...
-       
-       \subsection{popis datového modelu}
-       
-%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%  DB, ORM
-%%%%%%%%%%%%%%%%%%%%%%%%%%     
-       \subsection{popis 'ORM' frameworku Hibernate}\label{hibernate}
-       
-       
-       \subsection{nastavení hibernate}
-        \begin{itemize}
-           \item vygenerování .hbm.xml mapování z DB modelu
-           \item ruční úprava(přidání dědičnosti, doplnění vlastního kódu)
-           \item generování .java souborů z .hbm.xml souborů
-           \item používání .java souborů
-        \end{itemize}
-       
-  \subsection{popis provádění změn v DB modelu}
-    Existuje více prostředí, na kterých běží webová aplikace a vzhledem k 
používání tohoto řešení již v průběhu vývoje
-    je kladen důraz na zachování starých dat (v co největším rozsahu) při 
přechodu na novou verzi systému.
-    
-    Tím pádem je potřeba po každé změně datového modelu nutno přemigrovat 
starý datový model a data v něm uložená
-    do podoby definované novým datovým modelem. Ve většině případů bude tato 
migrace dat realizována SQL skriptem, 
-    v případě potřeby silnějšího prostředku se migrace bude řešit individuálně.
-    
-    \subsubsection{Čistá DB vs. Migrovaná DB}
-    čistá je vytvořena pomocí vytvářecího skriptu 
-    \subsubsection{Soulad čisté a migrované DB (koherence?)}
-    do migrované se jednoduše může zanést chyba, migrace se musí kontrolovat 
oproti čisté DB.
-    =popsat tady postup 
-       \subsection{Používání Hibernate Session v kódu}
-       
-%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%  GUI
-%%%%%%%%%%%%%%%%%%%%%%%%%%     
-       \subsection{GUI- JSF, Richfaces,..}
-        \subsubsection{lokalizace}
-          \paragraph{lokalizace labelu}
-          \paragraph{lokalizace chybových hlášek}
-        \subsection{vlastní zobrazovací komponenty}
-   \subsection{lokalizace}
-   Aplikace webServer2 podporuje lokalizaci popisků na webu do mnoha jazyků. 
Tato lokalizace může být užitečná, pokud se systémem pracují lidé mluvící jinou 
řečí.
-   Každý uživatel (ať už o tom ví, či ne), má ve svém internetovém prohlížeči 
nastaven světový jazyk, pomocí kterého se prohlížeč identifikuje webovému 
serveru.
-   Server tak může nabídnout anglické popisky člověku, který má v prohlížeči 
nastaven anglický jazyk komunikace a na druhé straně české popisky člověku, 
který má nastaveno české prostředí prohlížeče.
-   
-   Modul webServer2 podporuje vícejazyčnou komunikaci založenou na výše 
zmíněném principu, nicméně lokalizace webové aplikace byla zatím napsána jenom 
pro český jazyk.
-   Použití se zatím předpokládá v česky hovořícím prostředí, v případě 
požadavku je možné lokalizaci pro jiný jazyk vytvořit.
-   
-   Pro lokalizované popisky jsou umístěny v souboru {\em 
labels\_xx.properties}, kde {\it xx} značí zkratku jazyka, kterým se 
identifikuje webový prohlížeč serveru (cs pro češtinu, en pro angličtinu,..).
-   Systém potom vyhledá požadovaný soubor labels\_xx.properties a použije ho 
pro vypisování popisek.  
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%                   
-%%  Plánování
-%%%%%%%%%%%%%%%%%%%%%%%%%%     
-       \subsection{Plánování obsahu kiosku}
-        tady popisu planovaci komponentu. zminim casti, ktere jsou zavisle na 
typu planovani (ikdyz to sem zdanlive nepatri, ulehcim ctenari vyznani se v 
plugovatelnosti typu)
-   
-   zavisle casti jsou:\\
-    tooltip\\
-    modalni okno\\
-   
-   tady popisu modalni okno planovaci komponenty 
-   \begin{itemize}
-      \item{1.krok} V prvním kroku si uživatel v tomto modálním okně zvolí typ 
dat, které budou plánovány. 
-      Toto se bude dít s ohledem na povolené typy plánovaných dat pro danou 
pozici (tyto povolené typy budou specifikovány již při vytváření rozvržení 
zobrazení)
-      Seznam těchto povolených typů se získává z definice rozvržení obrazovky. 
 
-         \item{2.krok} Uživateli se zobrazí možnosti nastavení zvoleného typu 
plánování.
-         \item{3.krok} Uživatel potvrdí plánování. Systém provede potřebné 
validace zadaných údajů a případně uživatele vybídne k opravě.
-        \end{itemize}
-       
-       
-       
-       
-       
-       
-%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%  Plugovatelnost typů
-%%%%%%%%%%%%%%%%%%%%%%%%%%     
-       \subsection{Rozšiřitelnost systému o nový typ plánovaných dat}
-pred touto kapitolou urcite popsat: planovaci komponenta
-
-        Jelikož bude systém umožňovat plánovat na obrazovku kiosku různé typy 
dat, je kladen důraz na navržení systému tak, aby
-         mohla být podpora pro další typ zobrazovaných dat (např. videa) 
jednoduchou cestou doprogramována.  
-        \subsubsection{Nový typ plánovaných dat v databázi}
-          Úprava databáze je shrnuta v následujících krocích:
-     \begin{itemize}
-        \item{} \textbf{content\_type}
-           Přidání nového typu do tabulky \textit{content\_type}.
-        \item{nový potomek frame\_content}
-          Je také potřeba vytvořit tabulku, která bude uchovávat data 
plánování specifická pro nový typ.
-           Tabulka bude 'potomkem' (důvod popsán v kapitole věnované ORM 
frameworku Hibernate - \ref{hibernate}).
-        \item{přidání nového typu společnostem - comp\_permitted\_type}
-          - toto je buď možno udělat ručně, nebo z UC
-     \end{itemize}
-   
-   \subsubsection{Nový typ dat k uploadu}
-      tohle zpusobuje problemy, nemuze byt asi reseno automaticky
-      Kdyz se pridavalo video, tak muselo byt:
-      \begin{itemize}
-        \item{NEAUTOMATIZOVATELNE-nové tabulky v DB}vytvoren novy typ 
dokumentu v databazi (tabulka Video, VideoContent). Tabulka Video 'podedena' od 
tabulky File, tudiz ma definovane zakladni atributy
-        \item{NEAUTOMATIZOVATELNE-načítání dat z tabulky video v UC, které to 
vyžadují} (zobrazení plánování na plánovací komponentě, generování XML zprávy 
pro JH). Tohle načítání je snad řešeno jenom na jednom místě (PlanningBl asi)
-         - elvys.server.bl.planning.PlanningBLImpl: getTimelinesGeneric   
takhle načítá video a soubory
-           - načítá jednak v projektu webServer2 pro plánování
-           - také v projektu dispatcher pro posílání dat kiosku
-        \item{AUTOMATIZOVATELNE-nahrávání souborů nového typu na server} - 
pokud nemá společnost povoleno plánování daného typu dokumentu, tak např. ani 
nemůže na server nahrávat soubory, které s tímto typem dat souvisí 
(.avi,.mpg,..)
-        \item{mozna AUTOMATIZOVATELNE-vybírání souborů daného typu na serveru} 
- planovani, statistiky, reporty,...
-      
-      \end{itemize}  
-     
-     
-   \subsubsection{Nový typ dat při plánováni rozvržení obrazovky}
-     V aplikaci LayoutDesigner není potřeba nic měnit, možnost vytváření 
pozic, na kterých bude povoleno plánování 
-     nového typu je dáno pouze informací v datovém modelu webové aplikace 
(comp\_permitted\_type)
-   
-   \subsubsection{Nový typ dat v plánovací komponentě}
-         
-        
-         Základními typy plánování, které bude možno provádět budou: 
\textit{statický text}, \textit{dynamický text}, \textit{pdf dokument}, 
\textit{webová stránka}.
-        
-        Při práci s plánovací komponentou uživatel zvolí, která pozice 
obrazovky ho zajímá a v jakém čase a systém uživateli nabídne modální okno,
-        ve kterém bude probíhat konkrétní plánování. 
-    
-    
-         Peklo je krok 2 - tam se musi zobrazit spravne gui a zvolit spravna 
aplikacni logika na zaklade volby jednoho stringu v kroku1.
-         Postup pridani videa:
-        \begin{itemize}
-          \item{Registrace jména nového typu v databázi}     
-     \item{Vytvoření view prvku pro modální okno}
-          \item{Vytvoření obsahu 2. modálního okna}
-     \item{Vytvoření třídy obsahující logiku specifickou pro daný typ}
-          *BLImpl
-          
-          \item{Registrace view částí a třídy s logikou}
-          Pro zaregistrování částí systému souvisejících s nově přidaným typem 
je potřeba upravit konfigurační soubor:\\
-          \textit{cz.elvys.webServer.utils.plug.}\textbf{plugins.properties}
-          
-          \textit{view.path.<jmeno\_typu>} : definuje umístění 'view prvku' 
(cesta s lomítky)
-          \textit{view.path.<jmeno\_typu>.innermodal} : definuje umístění 
vnitřního 'view prvku' (cesta s lomítky)
-       \textit{planning.business.logic.<jmeno\_typu>} : definuje umístění 
třídy s aplikační logikou
-       Např.                       
-       
planning.business.logic.video=cz.elvys.webServer.toSpring.planning.impl.PlanningModalVideoBLImpl\\
-          view.path.video=/secured/plug/planningModalVideo.xhtml\\
-       
view.path.video.innermodal=/secured/plug/planningModalVideoInnerModal.xhtml
-          \item{Vytvoření a registrace backing beany pro práci se specifickými 
daty plánování}
-          např.: PlanningModalVideoBean.java
-          dědí od: 
\textit{cz.elvys.webServer.beans.planningrel.plug.PlanningModalSpecBean}
-          musí implementovat:
-            \begin{itemize}
-        \item{getFormData()}
-             \item{initPlanningModalSpecBean(String formName, ContentType 
type)}
-                ContentType představuje obsah formuláře plánování - obecný 
předek pro každý typ
-             \item{initPlanningModalSpecBean(String formName, FrameContent 
frc)}
-             \item{validate()}
-            \end{itemize}
-         
-           Registrace se provádí úpravou souboru po vzoru bean-tříd ostatních 
typů v následujícím souboru: 
-           \textit{webServer2/WebContent/WEB-INF/faces-beans-planplug.xml}
-           \begin{verbatim}
-        <managed-bean>
-           <managed-bean-name>planningModalUrlBean</managed-bean-name>
-           
<managed-bean-class>cz.elvys.webServer.beans.planningrel.plug.PlanningModalUrlBean</managed-bean-class>
-           <managed-bean-scope>session</managed-bean-scope>
-        </managed-bean>
-      \end{verbatim}
-           Omezení:  managed-bean-name musí být ve formátu: 
planningModal<Type>Bean, kde <Type> je jméno typu plánovaných dat,
-           které má velké první písmeno - tedy např. 
planningModalDocumentBean, planningModalVideoBean, ..
-           
-           \item{tooltipy na planovaci komponente}
-              -tooltip je potreba taky upravit
-              
-           \item{nacitani z DB}
-              -tohle se musi delat taky podle typu, ale nechal bych to tak, to 
je uz od plugovatelnosti taky docela vzdalene
-              - planDocumentBLImpl:68
-              
-              - dulezite je, ze kdyz jsou s nactenim 
-           \item{dispatcher}
-           odesílání DocumentConfigu není plugovatelné -> todo
-        \end{itemize}
-        
-        \subsubsection{Nový typ dat na kiosku}
-          Tady také popsat komunikaci s kioskem.
-          
-          - ta by mohla byt taky plugovatelna :O
-        
-       
-       \subsection{nahrávání dat na kiosek}
-  
-    \begin{itemize}
-  
-     \item{}
-     \item{Mazání starých dočasných dat}
-      autodelete=true/ false
-     
-    \end{itemize}
-  
-  
-  \subsection{komunikace s kioskem}
-  
-  \subsection{Archivace starých dat na serveru}
-    \begin{itemize}
-      \item{Společnosti}
-      
-      \item{Uživatelé}
-      
-      \item{Plánování}
-        - planovani- casem jich bude hodne
-        - pri odebrani kategorie - zahodit planovani, ci ne?
-        - pri zmene kategorie
-      \item{Dokumenty}
-        - pro každý dokument v historii musí zůstávat v tabulce záznam o tomto 
dokumentu
-    \end{itemize}      
-    
-   
-    
-  
-  
-  \subsection{}
-  
-  
-   
-        
-        
-       
-%%%%%%%%%%%%%%%%%%%%%%%%%%
-%%  Plánování
-%%%%%%%%%%%%%%%%%%%%%%%%%%     
-  \subsubsection{Skrývání panelů u plánování}
-  Tohle je celkem složitá věc, ještě nemáme ujasněno, jak konkrétně to budeme 
dělat.
-       
-          
-          
-       \subsection{Použití JH supa-dupa toolu na měření textu}   
-  
-       \subsection{Rozhraní přes WebServices}
-       K systému v současné době není možno přistupovat přes webservices, 
ale... mame oddělenou BL od prezentacni vrstvy, takže je to ready.. 
-       
-       \subsection{Dispatcher}
-
-       
-       \subsection{Applet}
-       
-\textbf{Komunikace mezi webovým serverem a appletem}
-\\
-\\
-LayoutDesigner lze spustit pro
-\begin{itemize}
- \item \textbf{vytvoření nového rozvržení} - pro vytvoření nového rozvržení má 
applet následující vstupní parametry
-  \begin{itemize}
-   \item \textbf{companyID} identifikátor společnosti 
-   \item \textbf{userID} identifikátor uživatelele, který s LayoutDesignerem 
pracuje
-  \end{itemize}
- 
- \item \textbf{editaci již dříve vyvořeného rozvržení} - oproti předchozímu má 
navíc parametr 
-  \begin{itemize}
-   \item \textbf{layoutID} identifikátor rozvržení obrazovky
-  \end{itemize}
-
-\end{itemize}
-Vstupní parametr layoutID rozhoduje o způsobu spuštění appletu.
-
-
-\paragraph{} 
-Dále LayoutDesigner získává od serveru následující informace pomocí zasílání 
HTTP POST požadavků
-\begin{itemize}
-\item \textbf{typy dokumentů povolené pro danou společnost}
-Applet zašle identifikátor společnosti a od serveru dostane seznam typů 
dokumentů povolené pro tuto společnost. Každý typ bude v odpovědi uveden na 
samostatném řádku.
-\item \textbf{podporované rozlišení obrazovek kiosků pro danou společnost}
-Applet zašle identifikátor společnosti a od server mu vrátí seznam 
podporovaných rozlišení v následujícím formátu:
-poměr a seznam rozlišení v tomto poměru oddělené mezerou, jednotlivé poměry 
jsou na samostaném řádku
-                    
-                      např. \verb#1,77 1920x1080 1200x675#
-\end{itemize}   
-
-Ukládání rozvržení na server i načítání rozvržení pro editaci probíhá také 
pomocí HTTP POST požadavků. 
-\begin{itemize}
-\item \textbf{uložení rozvržení na server} 
-LayoutDesigner zašle serveru identifikátor společnosti a uživatele a ukládaný 
layout ve formátu xml řetězce. 
-Jako odpověď dostane identifikátor, pod kterým bude rozvržení uloženo. 
-Nově vytvořené rozvržení v xml identifikátor neobsahují a server jim v 
odpovědi určí. 
-Editovaným rozvržením se zvýší jejich revize. Pokud došlo při editování ke 
změně počtu pozic, mohlo by dojít k narušení plánování, je tedy toto rozvžení 
uloženo pod jiným identifikátorem.  
-                
-                
-\item \textbf{načítání rozvržení pro editaci} 
-Applet zašle identifikátor rozvržení obrazovky a identifikátor společnosti. 
Jako odpověď dostane xml odpovídající požadovanému rozvržení, které je dále 
parsováno a zobrazeno v LayoutDesigeru.      
-\end{itemize}
-
-Applet neumožňuje listování seznamem rozvržení, pouze editaci rozvržení 
vybraného na webovém serveru. 
-
-
-
-
-\textbf{Zamykání rozvržení}
-\\
-
-Při editování dřívě vytvoření rozvržení je nutné, aby rozvržení editoval pouze 
jeden uživatel, jinak by mohlo docházet ke konfliktům.
-To je zajištěno pomocí zamykání editovaných rozvržení. Zamykání je realizováno 
pomocí HTTP POST požadavků. LayoutDesigner zašle serveru identifikátor 
společnosti, uživatele a rozvržení a typ požadavku - zda chce rozvržení 
zamknout, odemknout nebo zjisti, zda je zamčeno tímto uživatelem. 
-Pokud je rozvržení načteno ze serveru, uzamkne se a ostaní uživatelé ho 
nemohou editovat. Při ukládání se LayoutDesigner ujistí, zda má uživatel 
rozvržení stále zamknuté, až poté ho uloží na server. Po zavření se rozvržení 
odemkne a mohou ho začít editovat ostatní uživatelé.
-
-
-\textbf{Datové struktury}
-\\
-
-Hlavní datová struktura \textbf{Position} reprezentuje jednotlivé rozvrhované 
pozice a má následující položky
-\begin{itemize}
- \item \textbf{id} - jednoznačný identifikátor pozice 
- \item \textbf{monitor} - absolutní souřadnice\footnote[1]{topX - x-ová 
souřadnice horního levého rohu pozice, topY - y-ová souřadnice horního levého 
rohu pozice} a parametry\footnote[2]{výška a šířka pozice} pozice na obrazovce, 
na které je LayoutDesigner spuštěný 
- \item \textbf{elvys} - absolutní souřadnice\footnotemark[1] a 
parametry\footnotemark[2] pozice na obrazovce kiosku, kde bude rozvržení 
skutečně použito
- \item \textbf{isSelected} - příznak, jestli je pozice aktuálně vybraná
- \item \textbf{isSnappedToGrid} - příznak, jestli je pozice zarovnaná k mřížce
- \item \textbf{permittedDocumentTypes} - seznam typů dokumentů povolených 
zobrazovat na této pozici
-\end{itemize}
-
-       \subsection{Datový model}
-       nějakým způsobem popsat datový model a nekam ten datový model umistit 
(mozna vytisknout na A3, slozit a vlozit jako prilohu??)
-  
-  \subsubsection{Deployment, závislosti}
-    spis tady popsat jenom zavislosti a udelat dalsi "vetsi" include - 
deployment
-  
-  \subsection{Seznam knihoven}
-    \subsubsection{webServer2}
-    \subsubsection{dispatcher}
-    \subsubsection{applet}
-
-
-
-
-
-
-
-  \subsection{Špatné zkušenosti z vývoje}
-    \subsubsection{varchar foreign key}
-
-
-
-\section{Klientská aplikace}
-   % mimojine by tu asi mely byt i duvody, proc je to vlastni aplikace a ne 
webovy prohlizec....coz nebude uplne
-       % jednoduche. TOTO NAPSAT PORADNE.
-       \subsection{Statistiky}
-       %TODO : asi bych tu mel znova napsat o co go???
-       \subsubsection{Typu statistik}
-               \begin{itemize}
-               \item začátek a konec stahování nového dokumentu 
(\verb!download!)
-               \item začátek a konec vyvěšení daného dokumentu (\verb!exhibit!)
-               \item zvětšení dokumentu a jeho zmenšení na původní rozměr 
(\verb!detail!)
-               \end{itemize}
-
-       ....jen u těch typů dokumentů, kde to má smysl, tj. tyto statistiky 
nejsou vedeny pro dynamický a statitický text.
-               
-       \subsubsection{Uchovávání statistik}
-               Z požadavků na robustnost uchovávání statistik na kiosku 
vyplynul požadavek statistiky nejprve
-               zapisovat na disk a poté tyto záznamy upravovat podle toho, jak 
jsou data odesílany na server.
-               Vlastní formát datového souboru byl zavrhnut jako zbytečně 
pracný a neefektivní. Namísto toho bylo rozhodnuto
-               používat relační databázi, ty jsou pro tento druh práce vhodné. 
Vzhledem k zachování samostatnosti aplikace a k
-               malým výkonnostním nárokům byla zvolena databáze SQLITE v3. 
Protože byla použita abstrakce databází v Qt, lze v případě potřeby
-               změnit databázový engine jednoduchou úpravou aplikace.
-
-               {\bf TODO} Schema DB?
-
-       \subsubsection{Odesílání statistik}
-               Statistiky jsou odesílány v pravidelných, konfigurovatelných 
intervalech, dále pak při startu a konci aplikace.
-               Při odesílání je kontrolován odezva serveru, odesílání je pak 
případně opakováno.               
-
-               Způsub odesílání jednotlivých druhů statistik se však liší.     
        
-               Typy \verb!download! a \verb!detail! se odesílají na server až 
když je jejich záznam kompletní, tj. je znám čas začatku
-               i konce dané události. Typ \verb!exhibit! je na server odesílán 
nekompletní, párování těchto záznamů je přenecháno
-               na serveru. Důvodem k tomuto rozdílnému chování byla snaha 
ušetřit serveru práci při párování záznamů při
-               současném zachování dobré odezvy statistik. V případě odesílání 
jen kompletních záznamů by se server o skutečném vyvěšení
-               dokumentu na kiosku dozvěděl až po vypršení doby vyvěšení.
-
-
-

Copied: others/dokumentace/technicalGuide/architecture/4webapp.tex (from rev 
1676, others/dokumentace/technicalGuide/architecture/4software.tex)
===================================================================
--- others/dokumentace/technicalGuide/architecture/4webapp.tex                  
        (rev 0)
+++ others/dokumentace/technicalGuide/architecture/4webapp.tex  2010-02-08 
08:43:49 UTC (rev 1681)
@@ -0,0 +1,368 @@
+\chapter{Software}
+%asi jeste nejake kecy
+
+\section{Webová aplikace}
+       %TODO rozdeleni na subsections, mozna dalsi includy?
+       % rozdeleni na moduly, jeden z nich je statistika, dalsi 
layoutdesigner...
+       
+  \subsection{Přehled}
+  todo: napsat neco o tom, ze to je rozdelene do na sobe nezavislych webovych 
modulu webServer2 a dispatcher. Taky se zminit o appletu
+       
+       
+       \subsection{Rozdělení do modulů, sdílená aplikační logika}
+        - na to taky navazuje připravenost na napsání dalšího modulu- pro 
WS-API, přesunout k sobě. Odkaz na sekci, kde je popsáno, jak tu aplikacni 
logiku mame vlastne oddelenou...\\
+        Build je prováděn pomocí ANT-skriptů, které jsou popsány v 
\ref{build_ant}\\
+        
+       \subsection{Bezpečnost na serveru}
+       Popsat, jak je řešena autentizace, autorizaci radsi nezminovat, popsat 
SSL:
+          \subsubsection{webServer2} - ten SSL zatim nema
+          \subsubsection{dispatcher} - tenhle taky ne
+       \subsection{Popis komunikace serveru}
+       \subsubsection{webServer2}
+          FF, IE8, nutnost JRE pro applet
+       \subsubsection{webAPI??}
+          viz. dale
+       \subsubsection{dispatcher}
+          komunikace mezi kiosky a serverem
+       
+%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%  WebServer2 obecně
+%%%%%%%%%%%%%%%%%%%%%%%%%%             
+       \subsection{WebServer2}
+          popsat architekturu weboveho serveru - JSF+Richfaces, zavislosti,...
+       
+       \subsection{popis datového modelu}
+       
+%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%  DB, ORM
+%%%%%%%%%%%%%%%%%%%%%%%%%%     
+       \subsection{popis 'ORM' frameworku Hibernate}\label{hibernate}
+       
+       
+       \subsection{nastavení hibernate}
+        \begin{itemize}
+           \item vygenerování .hbm.xml mapování z DB modelu
+           \item ruční úprava(přidání dědičnosti, doplnění vlastního kódu)
+           \item generování .java souborů z .hbm.xml souborů
+           \item používání .java souborů
+        \end{itemize}
+       
+  \subsection{popis provádění změn v DB modelu}
+    Existuje více prostředí, na kterých běží webová aplikace a vzhledem k 
používání tohoto řešení již v průběhu vývoje
+    je kladen důraz na zachování starých dat (v co největším rozsahu) při 
přechodu na novou verzi systému.
+    
+    Tím pádem je potřeba po každé změně datového modelu nutno přemigrovat 
starý datový model a data v něm uložená
+    do podoby definované novým datovým modelem. Ve většině případů bude tato 
migrace dat realizována SQL skriptem, 
+    v případě potřeby silnějšího prostředku se migrace bude řešit individuálně.
+    
+    \subsubsection{Čistá DB vs. Migrovaná DB}
+    čistá je vytvořena pomocí vytvářecího skriptu 
+    \subsubsection{Soulad čisté a migrované DB (koherence?)}
+    do migrované se jednoduše může zanést chyba, migrace se musí kontrolovat 
oproti čisté DB.
+    =popsat tady postup 
+       \subsection{Používání Hibernate Session v kódu}
+       
+%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%  GUI
+%%%%%%%%%%%%%%%%%%%%%%%%%%     
+       \subsection{GUI- JSF, Richfaces,..}
+        \subsubsection{lokalizace}
+          \paragraph{lokalizace labelu}
+          \paragraph{lokalizace chybových hlášek}
+        \subsection{vlastní zobrazovací komponenty}
+   \subsection{lokalizace}
+   Aplikace webServer2 podporuje lokalizaci popisků na webu do mnoha jazyků. 
Tato lokalizace může být užitečná, pokud se systémem pracují lidé mluvící jinou 
řečí.
+   Každý uživatel (ať už o tom ví, či ne), má ve svém internetovém prohlížeči 
nastaven světový jazyk, pomocí kterého se prohlížeč identifikuje webovému 
serveru.
+   Server tak může nabídnout anglické popisky člověku, který má v prohlížeči 
nastaven anglický jazyk komunikace a na druhé straně české popisky člověku, 
který má nastaveno české prostředí prohlížeče.
+   
+   Modul webServer2 podporuje vícejazyčnou komunikaci založenou na výše 
zmíněném principu, nicméně lokalizace webové aplikace byla zatím napsána jenom 
pro český jazyk.
+   Použití se zatím předpokládá v česky hovořícím prostředí, v případě 
požadavku je možné lokalizaci pro jiný jazyk vytvořit.
+   
+   Pro lokalizované popisky jsou umístěny v souboru {\em 
labels\_xx.properties}, kde {\it xx} značí zkratku jazyka, kterým se 
identifikuje webový prohlížeč serveru (cs pro češtinu, en pro angličtinu,..).
+   Systém potom vyhledá požadovaný soubor labels\_xx.properties a použije ho 
pro vypisování popisek.  
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%                   
+%%  Plánování
+%%%%%%%%%%%%%%%%%%%%%%%%%%     
+       \subsection{Plánování obsahu kiosku}
+        tady popisu planovaci komponentu. zminim casti, ktere jsou zavisle na 
typu planovani (ikdyz to sem zdanlive nepatri, ulehcim ctenari vyznani se v 
plugovatelnosti typu)
+   
+   zavisle casti jsou:\\
+    tooltip\\
+    modalni okno\\
+   
+   tady popisu modalni okno planovaci komponenty 
+   \begin{itemize}
+      \item{1.krok} V prvním kroku si uživatel v tomto modálním okně zvolí typ 
dat, které budou plánovány. 
+      Toto se bude dít s ohledem na povolené typy plánovaných dat pro danou 
pozici (tyto povolené typy budou specifikovány již při vytváření rozvržení 
zobrazení)
+      Seznam těchto povolených typů se získává z definice rozvržení obrazovky. 
 
+         \item{2.krok} Uživateli se zobrazí možnosti nastavení zvoleného typu 
plánování.
+         \item{3.krok} Uživatel potvrdí plánování. Systém provede potřebné 
validace zadaných údajů a případně uživatele vybídne k opravě.
+        \end{itemize}
+       
+       
+       
+       
+       
+       
+%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%  Plugovatelnost typů
+%%%%%%%%%%%%%%%%%%%%%%%%%%     
+       \subsection{Rozšiřitelnost systému o nový typ plánovaných dat}
+pred touto kapitolou urcite popsat: planovaci komponenta
+
+        Jelikož bude systém umožňovat plánovat na obrazovku kiosku různé typy 
dat, je kladen důraz na navržení systému tak, aby
+         mohla být podpora pro další typ zobrazovaných dat (např. videa) 
jednoduchou cestou doprogramována.  
+        \subsubsection{Nový typ plánovaných dat v databázi}
+          Úprava databáze je shrnuta v následujících krocích:
+     \begin{itemize}
+        \item{} \textbf{content\_type}
+           Přidání nového typu do tabulky \textit{content\_type}.
+        \item{nový potomek frame\_content}
+          Je také potřeba vytvořit tabulku, která bude uchovávat data 
plánování specifická pro nový typ.
+           Tabulka bude 'potomkem' (důvod popsán v kapitole věnované ORM 
frameworku Hibernate - \ref{hibernate}).
+        \item{přidání nového typu společnostem - comp\_permitted\_type}
+          - toto je buď možno udělat ručně, nebo z UC
+     \end{itemize}
+   
+   \subsubsection{Nový typ dat k uploadu}
+      tohle zpusobuje problemy, nemuze byt asi reseno automaticky
+      Kdyz se pridavalo video, tak muselo byt:
+      \begin{itemize}
+        \item{NEAUTOMATIZOVATELNE-nové tabulky v DB}vytvoren novy typ 
dokumentu v databazi (tabulka Video, VideoContent). Tabulka Video 'podedena' od 
tabulky File, tudiz ma definovane zakladni atributy
+        \item{NEAUTOMATIZOVATELNE-načítání dat z tabulky video v UC, které to 
vyžadují} (zobrazení plánování na plánovací komponentě, generování XML zprávy 
pro JH). Tohle načítání je snad řešeno jenom na jednom místě (PlanningBl asi)
+         - elvys.server.bl.planning.PlanningBLImpl: getTimelinesGeneric   
takhle načítá video a soubory
+           - načítá jednak v projektu webServer2 pro plánování
+           - také v projektu dispatcher pro posílání dat kiosku
+        \item{AUTOMATIZOVATELNE-nahrávání souborů nového typu na server} - 
pokud nemá společnost povoleno plánování daného typu dokumentu, tak např. ani 
nemůže na server nahrávat soubory, které s tímto typem dat souvisí 
(.avi,.mpg,..)
+        \item{mozna AUTOMATIZOVATELNE-vybírání souborů daného typu na serveru} 
- planovani, statistiky, reporty,...
+      
+      \end{itemize}  
+     
+     
+   \subsubsection{Nový typ dat při plánováni rozvržení obrazovky}
+     V aplikaci LayoutDesigner není potřeba nic měnit, možnost vytváření 
pozic, na kterých bude povoleno plánování 
+     nového typu je dáno pouze informací v datovém modelu webové aplikace 
(comp\_permitted\_type)
+   
+   \subsubsection{Nový typ dat v plánovací komponentě}
+         
+        
+         Základními typy plánování, které bude možno provádět budou: 
\textit{statický text}, \textit{dynamický text}, \textit{pdf dokument}, 
\textit{webová stránka}.
+        
+        Při práci s plánovací komponentou uživatel zvolí, která pozice 
obrazovky ho zajímá a v jakém čase a systém uživateli nabídne modální okno,
+        ve kterém bude probíhat konkrétní plánování. 
+    
+    
+         Peklo je krok 2 - tam se musi zobrazit spravne gui a zvolit spravna 
aplikacni logika na zaklade volby jednoho stringu v kroku1.
+         Postup pridani videa:
+        \begin{itemize}
+          \item{Registrace jména nového typu v databázi}     
+     \item{Vytvoření view prvku pro modální okno}
+          \item{Vytvoření obsahu 2. modálního okna}
+     \item{Vytvoření třídy obsahující logiku specifickou pro daný typ}
+          *BLImpl
+          
+          \item{Registrace view částí a třídy s logikou}
+          Pro zaregistrování částí systému souvisejících s nově přidaným typem 
je potřeba upravit konfigurační soubor:\\
+          \textit{cz.elvys.webServer.utils.plug.}\textbf{plugins.properties}
+          
+          \textit{view.path.<jmeno\_typu>} : definuje umístění 'view prvku' 
(cesta s lomítky)
+          \textit{view.path.<jmeno\_typu>.innermodal} : definuje umístění 
vnitřního 'view prvku' (cesta s lomítky)
+       \textit{planning.business.logic.<jmeno\_typu>} : definuje umístění 
třídy s aplikační logikou
+       Např.                       
+       
planning.business.logic.video=cz.elvys.webServer.toSpring.planning.impl.PlanningModalVideoBLImpl\\
+          view.path.video=/secured/plug/planningModalVideo.xhtml\\
+       
view.path.video.innermodal=/secured/plug/planningModalVideoInnerModal.xhtml
+          \item{Vytvoření a registrace backing beany pro práci se specifickými 
daty plánování}
+          např.: PlanningModalVideoBean.java
+          dědí od: 
\textit{cz.elvys.webServer.beans.planningrel.plug.PlanningModalSpecBean}
+          musí implementovat:
+            \begin{itemize}
+        \item{getFormData()}
+             \item{initPlanningModalSpecBean(String formName, ContentType 
type)}
+                ContentType představuje obsah formuláře plánování - obecný 
předek pro každý typ
+             \item{initPlanningModalSpecBean(String formName, FrameContent 
frc)}
+             \item{validate()}
+            \end{itemize}
+         
+           Registrace se provádí úpravou souboru po vzoru bean-tříd ostatních 
typů v následujícím souboru: 
+           \textit{webServer2/WebContent/WEB-INF/faces-beans-planplug.xml}
+           \begin{verbatim}
+        <managed-bean>
+           <managed-bean-name>planningModalUrlBean</managed-bean-name>
+           
<managed-bean-class>cz.elvys.webServer.beans.planningrel.plug.PlanningModalUrlBean</managed-bean-class>
+           <managed-bean-scope>session</managed-bean-scope>
+        </managed-bean>
+      \end{verbatim}
+           Omezení:  managed-bean-name musí být ve formátu: 
planningModal<Type>Bean, kde <Type> je jméno typu plánovaných dat,
+           které má velké první písmeno - tedy např. 
planningModalDocumentBean, planningModalVideoBean, ..
+           
+           \item{tooltipy na planovaci komponente}
+              -tooltip je potreba taky upravit
+              
+           \item{nacitani z DB}
+              -tohle se musi delat taky podle typu, ale nechal bych to tak, to 
je uz od plugovatelnosti taky docela vzdalene
+              - planDocumentBLImpl:68
+              
+              - dulezite je, ze kdyz jsou s nactenim 
+           \item{dispatcher}
+           odesílání DocumentConfigu není plugovatelné -> todo
+        \end{itemize}
+        
+        \subsubsection{Nový typ dat na kiosku}
+          Tady také popsat komunikaci s kioskem.
+          
+          - ta by mohla byt taky plugovatelna :O
+        
+       
+       \subsection{nahrávání dat na kiosek}
+  
+    \begin{itemize}
+  
+     \item{}
+     \item{Mazání starých dočasných dat}
+      autodelete=true/ false
+     
+    \end{itemize}
+  
+  
+  \subsection{komunikace s kioskem}
+  
+  \subsection{Archivace starých dat na serveru}
+    \begin{itemize}
+      \item{Společnosti}
+      
+      \item{Uživatelé}
+      
+      \item{Plánování}
+        - planovani- casem jich bude hodne
+        - pri odebrani kategorie - zahodit planovani, ci ne?
+        - pri zmene kategorie
+      \item{Dokumenty}
+        - pro každý dokument v historii musí zůstávat v tabulce záznam o tomto 
dokumentu
+    \end{itemize}      
+    
+   
+    
+  
+  
+  \subsection{}
+  
+  
+   
+        
+        
+       
+%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%  Plánování
+%%%%%%%%%%%%%%%%%%%%%%%%%%     
+  \subsubsection{Skrývání panelů u plánování}
+  Tohle je celkem složitá věc, ještě nemáme ujasněno, jak konkrétně to budeme 
dělat.
+       
+          
+          
+       \subsection{Použití JH supa-dupa toolu na měření textu}   
+  
+       \subsection{Rozhraní přes WebServices}
+       K systému v současné době není možno přistupovat přes webservices, 
ale... mame oddělenou BL od prezentacni vrstvy, takže je to ready.. 
+       
+       \subsection{Dispatcher}
+
+       
+       \subsection{Applet}
+       
+\textbf{Komunikace mezi webovým serverem a appletem}
+\\
+\\
+LayoutDesigner lze spustit pro
+\begin{itemize}
+ \item \textbf{vytvoření nového rozvržení} - pro vytvoření nového rozvržení má 
applet následující vstupní parametry
+  \begin{itemize}
+   \item \textbf{companyID} identifikátor společnosti 
+   \item \textbf{userID} identifikátor uživatelele, který s LayoutDesignerem 
pracuje
+  \end{itemize}
+ 
+ \item \textbf{editaci již dříve vyvořeného rozvržení} - oproti předchozímu má 
navíc parametr 
+  \begin{itemize}
+   \item \textbf{layoutID} identifikátor rozvržení obrazovky
+  \end{itemize}
+
+\end{itemize}
+Vstupní parametr layoutID rozhoduje o způsobu spuštění appletu.
+
+
+\paragraph{} 
+Dále LayoutDesigner získává od serveru následující informace pomocí zasílání 
HTTP POST požadavků
+\begin{itemize}
+\item \textbf{typy dokumentů povolené pro danou společnost}
+Applet zašle identifikátor společnosti a od serveru dostane seznam typů 
dokumentů povolené pro tuto společnost. Každý typ bude v odpovědi uveden na 
samostatném řádku.
+\item \textbf{podporované rozlišení obrazovek kiosků pro danou společnost}
+Applet zašle identifikátor společnosti a od server mu vrátí seznam 
podporovaných rozlišení v následujícím formátu:
+poměr a seznam rozlišení v tomto poměru oddělené mezerou, jednotlivé poměry 
jsou na samostaném řádku
+                    
+                      např. \verb#1,77 1920x1080 1200x675#
+\end{itemize}   
+
+Ukládání rozvržení na server i načítání rozvržení pro editaci probíhá také 
pomocí HTTP POST požadavků. 
+\begin{itemize}
+\item \textbf{uložení rozvržení na server} 
+LayoutDesigner zašle serveru identifikátor společnosti a uživatele a ukládaný 
layout ve formátu xml řetězce. 
+Jako odpověď dostane identifikátor, pod kterým bude rozvržení uloženo. 
+Nově vytvořené rozvržení v xml identifikátor neobsahují a server jim v 
odpovědi určí. 
+Editovaným rozvržením se zvýší jejich revize. Pokud došlo při editování ke 
změně počtu pozic, mohlo by dojít k narušení plánování, je tedy toto rozvžení 
uloženo pod jiným identifikátorem.  
+                
+                
+\item \textbf{načítání rozvržení pro editaci} 
+Applet zašle identifikátor rozvržení obrazovky a identifikátor společnosti. 
Jako odpověď dostane xml odpovídající požadovanému rozvržení, které je dále 
parsováno a zobrazeno v LayoutDesigeru.      
+\end{itemize}
+
+Applet neumožňuje listování seznamem rozvržení, pouze editaci rozvržení 
vybraného na webovém serveru. 
+
+
+
+
+\textbf{Zamykání rozvržení}
+\\
+
+Při editování dřívě vytvoření rozvržení je nutné, aby rozvržení editoval pouze 
jeden uživatel, jinak by mohlo docházet ke konfliktům.
+To je zajištěno pomocí zamykání editovaných rozvržení. Zamykání je realizováno 
pomocí HTTP POST požadavků. LayoutDesigner zašle serveru identifikátor 
společnosti, uživatele a rozvržení a typ požadavku - zda chce rozvržení 
zamknout, odemknout nebo zjisti, zda je zamčeno tímto uživatelem. 
+Pokud je rozvržení načteno ze serveru, uzamkne se a ostaní uživatelé ho 
nemohou editovat. Při ukládání se LayoutDesigner ujistí, zda má uživatel 
rozvržení stále zamknuté, až poté ho uloží na server. Po zavření se rozvržení 
odemkne a mohou ho začít editovat ostatní uživatelé.
+
+
+\textbf{Datové struktury}
+\\
+
+Hlavní datová struktura \textbf{Position} reprezentuje jednotlivé rozvrhované 
pozice a má následující položky
+\begin{itemize}
+ \item \textbf{id} - jednoznačný identifikátor pozice 
+ \item \textbf{monitor} - absolutní souřadnice\footnote[1]{topX - x-ová 
souřadnice horního levého rohu pozice, topY - y-ová souřadnice horního levého 
rohu pozice} a parametry\footnote[2]{výška a šířka pozice} pozice na obrazovce, 
na které je LayoutDesigner spuštěný 
+ \item \textbf{elvys} - absolutní souřadnice\footnotemark[1] a 
parametry\footnotemark[2] pozice na obrazovce kiosku, kde bude rozvržení 
skutečně použito
+ \item \textbf{isSelected} - příznak, jestli je pozice aktuálně vybraná
+ \item \textbf{isSnappedToGrid} - příznak, jestli je pozice zarovnaná k mřížce
+ \item \textbf{permittedDocumentTypes} - seznam typů dokumentů povolených 
zobrazovat na této pozici
+\end{itemize}
+
+       \subsection{Datový model}
+       nějakým způsobem popsat datový model a nekam ten datový model umistit 
(mozna vytisknout na A3, slozit a vlozit jako prilohu??)
+  
+  \subsubsection{Deployment, závislosti}
+    spis tady popsat jenom zavislosti a udelat dalsi "vetsi" include - 
deployment
+  
+  \subsection{Seznam knihoven}
+    \subsubsection{webServer2}
+    \subsubsection{dispatcher}
+    \subsubsection{applet}
+
+
+
+
+
+
+
+  \subsection{Špatné zkušenosti z vývoje}
+    \subsubsection{varchar foreign key}
+
+
+
+

Deleted: others/dokumentace/technicalGuide/architecture/5deployment.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/5deployment.tex      
2010-02-08 08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/5deployment.tex      
2010-02-08 08:43:49 UTC (rev 1681)
@@ -1,45 +0,0 @@
-%subject to change
-
-\chapter{Konfigurace, nasazení řešení a závislosti}
-Celé řešení Elvys sestává ze serverové části(rozdělená na více modulů) a 
klientské části. 
-Popsat tady jak se to cele nasazuje
-\section{Webový server - aplikace }
-  \subsection{Sestavení řešení (build) a závislosti při sestavování} 
-    Sestavení řešení se provádí pomocí vytvořených ANT skriptů umístěných v 
projektech webServer2, resp. dispatcher.
-    Oba tyto moduly využívají sdílený kód a zdroje umístěné v projektu 
elvysCommons a modul webServer2 je navíc závislý na projektu LayoutDesigner.
-    \\ TADY PRIJDE OBRAZEK zavislosti - mam ho v EA, vykopirovat ho
-  \subsubsection{Rozbor procesu sestavování webServer2/dispatcher}
-    \begin{itemize}
-      \item volání závislostí\\
-         sestavení projektu \em{elvysCommons} a projektu L
-      \item hibernate tools
-    
-    \end{itemize}  
-    
-  \subsection{Konfigurace řešení}
-  Oba moduly(webServer2 i dispatcher)
-  \subsection{Aplikační server}
-    - tomcat/JBoss AS
-    - specifické nastavení AS: redirect after error (404, 403)
-  \subsection{webServer}
-    \subsubsection{Konfigurace webServer2 projektu}
-    - konfigurace - slozky na soubory, slozky na screenshoty,
-    - externi aplikace na pocitani stranek pdfka
-    - logovani
-    - build (nasazeni asi ne) pomoci ANTu, nasazeni ruco
-  \subsubsection{Konfigura}
-  \subsection{dispatcher}
-    - konfig
-    - logovani
-    - build(nasazeni asi ne) pomoci ANTU, nasazeni ruco
-  
- \section{Webový server - systémové nastavení }
-    Apache
-    \subsection{JirkaH competency}
-    - certifikáty
-    - stahování souboru bude snad tou dobou uz v me kompetenci, tak to ne
-    - nastaveni aplikaci pro monitoring
- 
-  
-\section{Kiosky}
- Tady popsat, jakym zpusobem

Added: others/dokumentace/technicalGuide/architecture/5layoutdesigner.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/5layoutdesigner.tex          
                (rev 0)
+++ others/dokumentace/technicalGuide/architecture/5layoutdesigner.tex  
2010-02-08 08:43:49 UTC (rev 1681)
@@ -0,0 +1,4 @@
+\chapter{LayoutDesigner java applet}
+
+čě+čěřčšžřýýžáýž98ýžýř
+

Added: others/dokumentace/technicalGuide/architecture/6clientapp.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/6clientapp.tex               
                (rev 0)
+++ others/dokumentace/technicalGuide/architecture/6clientapp.tex       
2010-02-08 08:43:49 UTC (rev 1681)
@@ -0,0 +1,53 @@
+\chapter{\label{clientapp}Klientská aplikace}
+Proc je to vubec C++ a Qt.
+
+podporovane typy
+
+
+\section{Konfiguracni soubory}
+
+\section{Komunikace}
+
+\section{PDF knihovna}
+vicevlaknove, pomale, sprava pameti...cachovani
+
+\section{Podpora videa}
+
+prehravani...
+
+\section{Statistiky}
+       \subsubsection{Typu statistik}
+               \begin{itemize}
+               \item začátek a konec stahování nového dokumentu 
(\verb!download!)
+               \item začátek a konec vyvěšení daného dokumentu (\verb!exhibit!)
+               \item zvětšení dokumentu a jeho zmenšení na původní rozměr 
(\verb!detail!)
+               \end{itemize}
+
+       ....jen u těch typů dokumentů, kde to má smysl, tj. tyto statistiky 
nejsou vedeny pro dynamický a statitický text.
+               
+       \subsubsection{Uchovávání statistik}
+               Z požadavků na robustnost uchovávání statistik na kiosku 
vyplynul požadavek statistiky nejprve
+               zapisovat na disk a poté tyto záznamy upravovat podle toho, jak 
jsou data odesílany na server.
+               Vlastní formát datového souboru byl zavrhnut jako zbytečně 
pracný a neefektivní. Namísto toho bylo rozhodnuto
+               používat relační databázi, ty jsou pro tento druh práce vhodné. 
Vzhledem k zachování samostatnosti aplikace a k
+               malým výkonnostním nárokům byla zvolena databáze SQLITE v3. 
Protože byla použita abstrakce databází v Qt, lze v případě potřeby
+               změnit databázový engine jednoduchou úpravou aplikace.
+
+               {\bf TODO} Schema DB?
+
+       \subsubsection{Odesílání statistik}
+               Statistiky jsou odesílány v pravidelných, konfigurovatelných 
intervalech, dále pak při startu a konci aplikace.
+               Při odesílání je kontrolován odezva serveru, odesílání je pak 
případně opakováno.               
+
+               Způsub odesílání jednotlivých druhů statistik se však liší.     
        
+               Typy \verb!download! a \verb!detail! se odesílají na server až 
když je jejich záznam kompletní, tj. je znám čas začatku
+               i ko    nce dané události. Typ \verb!exhibit! je na server 
odesílán nekompletní, párování těchto záznamů je přenecháno
+               na serveru. Důvodem k tomuto rozdílnému chování byla snaha 
ušetřit serveru práci při párování záznamů při
+               současném zachování dobré odezvy statistik. V případě odesílání 
jen kompletních záznamů by se server o skutečném vyvěšení
+               dokumentu na kiosku dozvěděl až po vypršení doby vyvěšení.
+
+
+\section{Screenshoty}
+
+\section{Stahovani a ukladani souboru}
+dopredne...
\ No newline at end of file

Deleted: others/dokumentace/technicalGuide/architecture/6tools.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/6tools.tex   2010-02-08 
08:07:07 UTC (rev 1680)
+++ others/dokumentace/technicalGuide/architecture/6tools.tex   2010-02-08 
08:43:49 UTC (rev 1681)
@@ -1,2 +0,0 @@
-\chapter{Nástroje použité při vývoji}
-% svn, trac, hudson....

Added: others/dokumentace/technicalGuide/architecture/7communication.tex
===================================================================
--- others/dokumentace/technicalGuide/architecture/7communication.tex           
                (rev 0)
+++ others/dokumentace/technicalGuide/architecture/7communication.tex   
2010-02-08 08:43:49 UTC (rev 1681)
@@ -0,0 +1,8 @@
+\chapter{Popis rozhraní}
+\section{Rozhraní mezi webovou aplikací a kiosky}
+\section{Rozhraní mezi webovou aplikací a LayoutDesignerem}   
+\section{Rozhraní mezi webovou aplikací a pomocnými aplikacemi}
+ \subsection{pageCounter}
+ \subsection{textMeter}
+ \subsection{videoMeter}                                              
+ 
\ No newline at end of file

Copied: others/dokumentace/technicalGuide/architecture/8deployment.tex (from 
rev 1676, others/dokumentace/technicalGuide/architecture/5deployment.tex)
===================================================================
--- others/dokumentace/technicalGuide/architecture/8deployment.tex              
                (rev 0)
+++ others/dokumentace/technicalGuide/architecture/8deployment.tex      
2010-02-08 08:43:49 UTC (rev 1681)
@@ -0,0 +1,45 @@
+%subject to change
+
+\chapter{Konfigurace, nasazení řešení a závislosti}
+Celé řešení Elvys sestává ze serverové části(rozdělená na více modulů) a 
klientské části. 
+Popsat tady jak se to cele nasazuje
+\section{Webový server - aplikace }
+  \subsection{Sestavení řešení (build) a závislosti při sestavování} 
+    Sestavení řešení se provádí pomocí vytvořených ANT skriptů umístěných v 
projektech webServer2, resp. dispatcher.
+    Oba tyto moduly využívají sdílený kód a zdroje umístěné v projektu 
elvysCommons a modul webServer2 je navíc závislý na projektu LayoutDesigner.
+    \\ TADY PRIJDE OBRAZEK zavislosti - mam ho v EA, vykopirovat ho
+  \subsubsection{Rozbor procesu sestavování webServer2/dispatcher}
+    \begin{itemize}
+      \item volání závislostí\\
+         sestavení projektu \em{elvysCommons} a projektu L
+      \item hibernate tools
+    
+    \end{itemize}  
+    
+  \subsection{Konfigurace řešení}
+  Oba moduly(webServer2 i dispatcher)
+  \subsection{Aplikační server}
+    - tomcat/JBoss AS
+    - specifické nastavení AS: redirect after error (404, 403)
+  \subsection{webServer}
+    \subsubsection{Konfigurace webServer2 projektu}
+    - konfigurace - slozky na soubory, slozky na screenshoty,
+    - externi aplikace na pocitani stranek pdfka
+    - logovani
+    - build (nasazeni asi ne) pomoci ANTu, nasazeni ruco
+  \subsubsection{Konfigura}
+  \subsection{dispatcher}
+    - konfig
+    - logovani
+    - build(nasazeni asi ne) pomoci ANTU, nasazeni ruco
+  
+ \section{Webový server - systémové nastavení }
+    Apache
+    \subsection{JirkaH competency}
+    - certifikáty
+    - stahování souboru bude snad tou dobou uz v me kompetenci, tak to ne
+    - nastaveni aplikaci pro monitoring
+ 
+  
+\section{Kiosky}
+ Tady popsat, jakym zpusobem

Copied: others/dokumentace/technicalGuide/architecture/9tools.tex (from rev 
1676, others/dokumentace/technicalGuide/architecture/6tools.tex)
===================================================================
--- others/dokumentace/technicalGuide/architecture/9tools.tex                   
        (rev 0)
+++ others/dokumentace/technicalGuide/architecture/9tools.tex   2010-02-08 
08:43:49 UTC (rev 1681)
@@ -0,0 +1,13 @@
+\chapter{Nástroje použité při vývoji}
+% svn, trac, hudson....
+
+
+\begin{thebibliography}{9}
+  \bibitem{pdfcreator} \textbf{PDF Creator} 
http://sourceforge.net/projects/pdfcreator/
+  \bibitem{googlebooks} \textbf{Google Books} http://books.google.com
+  \bibitem{flashpaper} \textbf{Flashpaper} 
http://www.adobe.com/products/flashpaper/
+  \bibitem{lcg} \textbf{The Large Hadron Collider (LHC) Computing Grid} 
http://lcg.web.cern.ch/lcg/
+  \bibitem{puppet} \textbf{Puppet, configuration management tool} 
http://reductivelabs.com/products/puppet/
+  \bibitem{cfengine} \textbf{Cfengine, configuration management tool} 
http://www.cfengine.org/
+  \bibitem{quattor} \textbf{Quattor, configuration management tool} 
http://sourceforge.net/apps/mediawiki/quattor/
+\end{thebibliography}

Other related posts:

• » [elvystrac] r1681 - architecture and analysis documentation - elvys

1. Home
2. elvystrac
3. Archive
4. 02-2010

---

• » Previous by Date
• » Next by Date
• » Related Posts
• » View list details
• » Manage your subscription

---