WYSIWYG administrace webových aplikací

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

WYSIWYG administrace webových aplikací Zdeněk Mrázek

Vedoucí práce: Radomír Černoch MSc.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 22. května 2012

iv

Poděkování Chtěl bych poděkovat zejména vedoucímu bakalářské práce panu Radomírovi Černochovi za důvěru, kterou v projekt se mnou od první chvíle měl. Za ochotu a odvahu udělat ten první krok do neznáma. Za nemalý čas, kterým do projektu přispěl, za jeho trpělivost a píli. Více takovýchto schopných lidí!

v

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Krupce 24. 5. 2012

...........................................................................

Abstract The main point of document is the description of an application that allows administration without switching to the separate administration interface. All administration is through the user friendly WYSIWYG editor and provides direct feedback of web aplication wich is developed. The aplication includes a library functions for develop web aplication and creating widgets for web aplications. Part of project is an example of use.

Abstrakt Dokument se zabývá popisem aplikace, která umožňuje administraci webových aplikací bez nutnosti přepínání se do administračního rozhraní. Tato administrace probíhá z uživatelsky přívětivého WYSIWYG editoru a poskytuje přímou zpětnou vazbu na vyvíjený projekt. Aplikace obsahuje knihovní funkce pro vývoj a rozšíření webových aplikací. Součástí aplikace je i ukázková implementace.

vi

Obsah 1 Úvod 1.1 Od sálových počítačů k osobním . . . . . . . . . . . . . . . . 1.2 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Content Management System – Systém pro správu webového obsahu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1

2 Srovnání stávajících CMS 2.1 Kritéria . . . . . . . . . . . . 2.2 Které CMS se budou testovat 2.2.1 SilverStripe . . . . . . 2.2.2 Joomla . . . . . . . . 2.2.3 Drupal . . . . . . . . . 2.2.4 WordPress . . . . . . 2.3 Šablonovací systém . . . . . . 2.4 WYSIWYG editace . . . . . . 2.5 Rozšiřitelnost . . . . . . . . .

2

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3 3 3 4 4 4 4 5 7 8

3 Použité technologie 3.1 HTML 5 . . . . . . . . . . . . . . . . 3.2 WYSIWYG . . . . . . . . . . . . . . 3.2.1 Mercury editor . . . . . . . . 3.2.2 Aloha editor . . . . . . . . . 3.2.3 Konečné rozhodnutí . . . . . 3.3 Nette . . . . . . . . . . . . . . . . . . 3.3.1 MVC . . . . . . . . . . . . . 3.3.1.1 Model . . . . . . . . 3.3.1.2 View . . . . . . . . 3.3.1.3 Controller . . . . . . 3.3.2 Zpracování požadavku . . . . 3.3.3 Adresářová struktura aplikace 3.3.4 Latte . . . . . . . . . . . . . 3.3.5 Routování . . . . . . . . . . . 3.4 Dibi . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

11 11 11 12 13 13 13 14 14 14 14 14 15 15 16 16

vii

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

OBSAH 3.5

viii jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Popis API 4.1 AvailibleWidgets.xml . . . . 4.2 Widget . . . . . . . . . . . . 4.3 Akce widgetu . . . . . . . . 4.4 Akce widgetu nad položkou 4.5 Makro ActionList . . . . . . 4.6 Parametry widgetu . . . . . 4.7 Parametr urlParam . . . . . 4.8 Makro easy-edit . . . . . . . 4.9 Web container . . . . . . . .

. . . . . . . . .

5 Uživatelské rozhraní 5.1 Šablona . . . . . . . . . . . . 5.2 Stránka . . . . . . . . . . . . 5.3 Náhled uživatelského rozhraní 5.4 Nástrojová lišta . . . . . . . . 5.4.1 Save as template . . . 5.4.2 Widget . . . . . . . . 5.4.3 Edit, new page . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

16

. . . . . . . . .

18 18 19 19 20 20 20 21 21 23

. . . . . . .

24 24 24 25 25 26 27 28

6 Tutorial 30 6.1 Článek náhledy . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.1 Základní funkcionalita . . . . . . . . . . . . . . . . . . 31 6.1.2 Rozšiřující vlastnosti . . . . . . . . . . . . . . . . . . . 34 7 Pohyb Uživatele 7.1 Login . . . . . . . 7.2 Nová stránka . . . 7.3 Inicializace widgetu 7.4 Práce se šablonou . 7.5 Zbytek aplikace . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

40 40 40 40 41 41

8 Závěr 42 8.1 Budoucí vývoj aplikace . . . . . . . . . . . . . . . . . . . . . . 42

Seznam obrázků 2.1 2.2 2.3

Drupal administrace . . . . . . . . . . . . . . . . . . . . . . . Drupal editace obsahu . . . . . . . . . . . . . . . . . . . . . . WordPress prostředí . . . . . . . . . . . . . . . . . . . . . . .

6 8 9

3.1

Ukázka WYSIWYG editoru tinyMCE . . . . . . . . . . . . .

12

5.1 5.2 5.3 5.4 5.5 5.6

Náhled uživatelského Nástrojová lišta . . . Uložit jako šablonu . Widget panel . . . . Widget akce . . . . . Edit, new page . . .

25 25 26 27 28 28

rozhraní . . . . . . . . . . . . . . . . . . . . . . . . .

ix

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Kapitola 1

Úvod 1.1 Od sálových počítačů k osobním Vývoj počítačů prodělal za posledních několik dekát nejmohutnější technologický rozmach. V začátcích velké sálové počítače, které mohli používat jen vyvolení se postupně vyvinuli v počítače jak je známe nyní. Počítač se stává pomocníkem každé domácnosti a své využití najde ve všech oborech lidského působení. Počítač se stáva více a více běžným a práce na počítači nezbytnou schopností. Spolu s masovým příchodem počítačů, přichází také nároky na jeho použitelnost. Bez kvalitního softwaru, by byl výkon, který každým rokem roste, k ničemu. Od dob softwaru, kdy hlavní prioritou byla funkcionalita se nyní klade větší důraz i na uživatelské prostředí, na práci se softwarem a jednoduchost. Průlom při tvorbě webových aplikací pro běžného uživatele přichází s WYSIWYG editorem 3.2. WYSIWYG editor umožňuje editaci bez nutnosti znalosti značkovacího jazyka. My jsme se pokusili vytvořit prototyp aplikace, který tuto WYSIWYG editaci ještě více rozšiřuje a tvorbu webových aplikací tak uživatelsky více zpřístupňuje.

1.2 Motivace Aplikace poskytuje knihovní funkce pro tvorbu a správu webových stránek. Obsahuje jedinečnou správu celé aplikace prostřednictvím WYSIWYG editoru. Součástí práce je také ukázková aplikace, která je posána v kapitole 6. Systém poskytuje jednoduché API 4 pro práci a vývoj rozšíření – widgetů, které jsou popsány více zde 4.2. Prostřednictvím API definujeme také

1

KAPITOLA 1. ÚVOD

2

chování tohoto rozšíření ve WYSIWYG editoru a jeho administraci. Veškerá administrace webových stránek se tak odehrává přímo ve WYSIWYG editoru. Systém poskytuje také běžné zvyklosti jiných CMS jako je tvorba stránek nebo šablonovací systém 5.1. Součástí dokumentu je také kritické srovnání stávajicích CMS a vymezení se proti vyvíjené aplikaci. Srovnání najdeme v kapitole 2.

1.3 Content Management System – Systém pro správu webového obsahu Je systém zajištující správu dokumentů, nejčastěji s webovým obsahem. Úlohou CMS systému je zprostředkovat uživateli (který nezná žádný značkovací jazyk) nástroje pro tvorbu webové aplikace a poskytnout co největší možnost administrace obsahu. Součástí jsou nástroje pro tvorbu, modifikaci a publikaci dokumentů zpravidla prostřednictvím webového rozhraní, často s využitím jednoduchého WYSIWYG editoru 3.2 nebo jiného systému pro formátování textu.

Kapitola 2

Srovnání stávajících CMS Cílem kapitoly je kritické srovnání stávajících CMS systémů. Srovnávat se budou zejména vlastnosti související s aplikací. Tato kapitola slouží jako průzkum současných systémů. Má zjistit nedostatky, odhalit mezery a prostor pro zlepšení současných CMS. Popisuje také klady jednotlivých CMS systémů a řešení jednotlivých komponent systému, které jsou důležité vzhledem k aplikaci.

2.1 Kritéria • Maximální jednoduchost použití CMS, intuitivita a „user-friendly“ prostředí. • Rozšiřitelnost – modulárnost, podpora programátora pro psaní takovýchto rozšíření. • Rešerše šablonovacích systémů, logika šablonovacích systémů a jejich využití. • WYSIWYG editace. To jsou velmi abstraktní pojmy, které upřesníme zvlášť u každého CMS.

2.2 Které CMS se budou testovat Zajímají nás nejrozšířenější, nejúspěšnější a nejvíce podobné CMS našemu modelu CMS. Konkrétně tedy tyto systémy: SilverStripe, Joomla, Drupal, WordPress. Mají nejširší uživatelskou základnu, podporu ze strany vývojářů a do budoucna i jistý vývoj.

3

KAPITOLA 2. SROVNÁNÍ STÁVAJÍCÍCH CMS

4

2.2.1 SilverStripe SilverStripe je volně šiřitelný open-source projekt, vyvíjený pod Saphire frameworkem, který pochází od stejných vývojářů jako samotné CMS. Vize projektu je taková, že CMS instaluje a konfiguruje programátor, který i doimplementuje „typy“ stránek a to následně předá zákazníkovi. Typu stránky rozumíme jako množině políček definujících strukturu dokumentu. SilverStripe poskytuje administraci webového obsahu prostřednictvím jednoduchého formuláře na straně administrace. Programátor povolí bloky stránek k editaci a ty se pak objeví v administraci jako políčka jednoduchého formuláře v bloku pod sebou. Dovoluje také některá políčka s formátovaným textem rozšířit o WYSIWYG editaci . SilverStripe se snaží striktně oddělit role programátora a samotného redaktora obsahu. Testovaná verze 2.4.7.

2.2.2 Joomla Joomla je také jeden z volně šiřitelných open-source CMS systémů. Je napsán v jazyce PHP stejně jako všechny zde probírané CMS. Joomla podporuje caching stránek , indexaci stránek, RSS (je z rodiny XML formátu, sloužící pro odběr, např. novinek), tisknutelné verze stránek, zobrazování novinek, blogy, diskusní fóra, hlasování, kalendář, vyhledávání v rámci webserveru, lokalizace a vícejazyčné verze. Poskytuje administraci obsahu a rozšíření. Testovaná verze 2.5.1.

2.2.3 Drupal Systém Drupal je stejně jako SilverStripe a Joomla také volně šiřitelným open-source projektem napsaným v jazyce PHP. Umožňuje tvorbu internetových časopisů, blogů, internetových obchodů a jiných komplexních systémů. Nabízí velké množství přídavných modulů ke stažení. Nabízí přímou administraci obsahu stránky, bez nutnosti přepnutí do administrační části webu. Tato administrace probíhá přidáním dvou tlačítek na stránku. Pod prvním tlačítkem je zobrazen obsah tak, jak jej uvidí uživatel, pod druhým pak odkaz pro editaci obsahu. Což je velmi podobné modelu CMS, který chceme vyvíjet. Z našeho pohledu nejzajímavější CMS. Součástí standartního balíčku Drupal jsou i nástroje pro sledování stránek. Např. nejvyhledávanější fráze, počet zobrazení stránky s kódem 404, apod. Drupal dovoluje i personalizaci administrační části webu, je možné měnit vzhled a rozložení. Testovaná verze 7.12.

2.2.4 WordPress Pátý systém je opět volně šiřitelný CMS, redakční systém napsaný v PHP podporující několik databázových systémů. Počet stažení verze 3.0 dosahu-


5

je téměř 10ti miliónů uživatelů. 22% všech nově vzniklých webových prezentací používá WordPress a to ho řadí mezi nejpoužívanější CMS vůbec. Má nejpříjemnější uživatelské rozhraní z testovaných systémů. Také nabízí administraci přidaných modulů. Obsahuje systém šablon, WYSIWYG editaci, lokalizaci a internacionalizaci a další. Cashování obsahu není součástí standartního balíčku, lze jej ale snadno doinstalovat jako přídavný plug-in. WordPress obsahuje přes 18 000 dostupných plug-inů. Rozděluje stránku na kontejnery, do kterých má možnost uživatel vkládat obsah. Testovaná verze 3.3.1.

2.3 Šablonovací systém Mezi kancelářskými aplikacemi jsou šablony de facto standardem. Umožňují totiž snadno sjednotit formální úpravu dokumentů a zároveň u konkrétního dokumentu detaily formátování upravit. Je s podivem, že CMS systémy tuto vlastnost neobsahují. V oblasti CMS se pod šablonou zpravidla chápe rozložení pluginů do kontejnerů na stránce. SilverStripe SilverStripe definuje tzv. typy stránky, což je množina políček, které tvoří strukturu dokumentů, např. název článku, abstrakt a vlastní text. Typy stránek definuje programátor v době návrhu webové aplikace, uživatel je tedy nemůže upravovat. Nasazení SilverStripe proto předpokládá spolupráci programátora, jehož rolí je připravit systém pro konkrétní potřeby zákazníka. Každý typ stránky má přiřazenou šablonu, která převádí dokument do HTML podoby a určuje výslednou podobu dokumentu ve webovém prohlížeči. SilverStripe používá šablony pouze pro zobrazení dokumentů návštěvníkům webu. Editace dokumentů se prování v administračním rozhraní, které je nezávislé na šabloně a má podobu sady políček v jednoduchém webovém formuláři. Z výše uvedeného plyne největší omezení systému. Uživatel nemá možnost měnit samotnou šablonu, např. zrušením abstraktu u krátkého dokumentu. Podobné změny je nutné provádět ve spolupráci s programátorem. Joomla Na druhou stranu Joomla definuje každou webovou stránku jako článek. Nabízí základní administraci šablon z webového rozhraní. Lze měnit např. logo, titulek stránky nebo popis stránky pro vyhledávače. Joomla poskytuje nástroje pro programátora k definici vlastností, které budou přístupné v administraci. Joomla obsahuje předem definované webové kontejnery, se kterými nelze manipulovat, ani nijak spravovat z administrační části webu. Z toho vyplývá,


6

že joomla rozhoduje o tom, který obsah vygeneruje do webového kontejneru. Uživatel tuto skutečnost neovlivní. Drupal Drupal má z námi testovaných CMS nejsilnější administraci šablon. Poskytuje uživateli úplnou administraci šablony až na úroveň DOM modelu. Drupal rozděluje stránku na jednotlivé pole, kterým v administraci přiřazuje obsah. Obsah může být i widget, ale s podstatným rozdílem, widget je volán bez parametrů. Hlavním nedostatkem zůstává stejně jako u ostatních CMS to, že Drupal nenabízí konkrétní instanci šablony modifikovat podobně, jako to dělají běžné kancelářské aplikace s dokumenty.

Obrázek 2.1: Drupal administrace

WordPress Obsahuje tzv. témata, která můžeme přirovnat k šabloně. K tomuto tématu poskytuje administraci jak na úrovni dokumentu (titulek stránky, popisek), tak i obsahu šablony. WordPress rozděluje dokumenty webové aplikace na dva typy: prvním je článek (stejně jako u Joomla) a druhým pak stránka. Vkládání widgetu na stránku probíhá systémem drag & drop. Widgetu se dají předat parametry při vložení. Další vlastností systému WordPress oproti konkurenci je, že nabízí kódování šablon přímo v administraci. Na šablonu se dá kliknout a otevře se jako prostý text k editaci pro rychlé úpravy. Nevýhoda šablonovacího systému je stejná jako u systému Drupal popsaného výše. Shrnutí Došli jsme k zjištění, že ani jeden ze systému nenabízí zamýšlenou logiku šablonovacího systému, jako je tomu u běžných kancelářských aplikací. Přitom tento systém je širokou veřejností dobře znám, nezavádí


7

do systému nové věci, které by uživatel musel pracně dohledávat. Je proto s podivem, že jej žádný CMS systém doposud neimplementoval. Systém Drupal nabízí nejširší možnost administrace, a to dokonce na úrovni DOM modelu. To je hloubka, která místy až dezorientuje uživatele.

2.4 WYSIWYG editace WYSIWYG je akronym anglické věty „What you see is what you get“, česky „co vidíš, to dostaneš“. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce vzhledově totožná s výslednou verzí dokumentu. Implementace WYSIWYG editoru přidá standardnímu textovému poli sadu nástrojů, které jsou schopny generovat HTML kód a tím formátovat text. SilverStripe Editace dokumentu probíhá pomocí formulářových polí v administračním rozhraní. Typ stránky definuje některá pole pro WYSIWYG editaci. Administrační formulář je bohužel nepřehledný, protože je nezávislý na šabloně, a všechna políčka jsou zobrazená lineárně pod sebou v bloku. Uživatel si tedy musí pamatovat názvy jednotlivých políček a rozumět jejich roli. Je proto otázkou, zda lze editace dokumentů v SilverStripe označit za WYSIWYG, když celková podoba stránky se liší od podoby při editaci a výsledný vzhled zachovávají pouze jednotlivá pole. Joomla Joomla také nabízí WYSIWYG editaci, která se v podstatných rysech neliší od systému SilverStripe. Drupal Drupal nenabízí WYSIWYG editaci obsahu v standardním balíčku, lze jej stáhnout jako rozšíření. Zato nabízí možnost editovat obsah webového kontejneru přímo na stránce pomocí dvou tlačítek. První jej zobrazí tak, jak jej vidí uživatel a druhé nabízí administraci aktuálně zobrazeného obsahu. Hlavním rozdílem je, že editace probíhá přesměrováním na stránku s editací. Pro toto zobrazení neexistuje jednotné rozhraní pro typ vkládaného obsahu. To znamená, že administrace webového kontejneru se odvíjí od typu webového kontejneru. WordPress WordPress také nabízí WYSIWYG editaci, která se v podstatných rysech neliší od systému SilverStripe.


8

Obrázek 2.2: Drupal editace obsahu Shrnutí Všechny CMS systémy nabízejí WYSIWYG editaci tak, že definují webový kontejner, kde by mohl uživatel chtít formátovaný text a ten pak v administraci obohatí o nástroje WYSIWYG. Systémy se liší uživatelskou přívětivostí a jednoduchostí použití. Systém Drupal je v tomto ohledu nejlepším, přestože stále obsahuje prostor pro zlepšení.

2.5 Rozšiřitelnost Rozšiřitelnost nebo také modulárnost je jedna z nejdůležitějších vlastností vyvíjeného systému vůbec. Stránka je rozdělena podle DOM modelu na webové kontejnery, pro které poskytuje CMS administraci. Modul, plug-in, nebo widget (není jednotný název) se dá rozdělit do dvou kategorií podle funkční odpovědnosti. První kategorii je modul rozšiřující vnitřní strukturu a funkcionalitu samotného CMS, např. do systému přidáme modul rozšiřující textové vstupní pole o WYSIWYG nástroje pro formátování textu. Druhou skupinou je modul, jehož funkčním požadavkem je generovat obsah do webového kontejneru a tvořit tak logiku webové aplikace. Např. modul kalendář. SilverStripe SilverStripe definuje tzv. typy stránky, což je množina políček, které tvoří strukturu dokumentů, např. název článku, abstrakt a vlastní text. Typy stránek definuje programátor v době návrhu webové aplikace, uživatel je tedy nemůže upravovat. Rozšiřitelnost pomocí widgetů je pevně svázána s typem stránky. Sadu, vzhled a administraci widgetů určuje šablona stránky, kterou uživatel nemůže upravovat. To má výhodu v jednoduchosti použití, uživatel má k dispozici množinu programátorem na míru šitých stránek a nastavuje ji jako celek. Naopak nevýhodou je, když uživatel vytváří stránku v rozporu se šablonou, je odkázán na pomoc programátora. Joomla Systém Joomla neposkytuje takovou podporu programátora jako SilverStripe, proto většinu rozšíření tvoří moduly první kategorie, tj. modul, který rozšiřuje funkčnost samotného CMS. Každý dokument v Joomle je brán jako článek, z tohoto důvodu všechen obsah, který nesouhlasí s modelovým obsahem typu „článek“, nemá podporu ze strany CMS.


9

Pro takováto rozšíření neposkytuje ve srovnání s konkurencí dostatečnou podporu a je nepostačující. Drupal Podobně jako systém SilverStripe umožňuje Drupal definovat různé typy obsahu. Na rozdíl od SilverStripe však umožňuje administraci pomocí GUI. A to vše na straně administrace. Stejně tak poskytuje administraci modulu jako takového. Nedostatkem je nemožnost předat parametr widgetu při jeho inicializaci v dokumentu. WordPress WordPress označuje první kategorii rozšíření jako modul a druhou jako widget. Jak k modulu, tak i k widgetu poskytuje WordPress administrační prostředí. Tj. individuální nastavení vlastností modulu, widgetu. Widget se do stránky vkládá přes speciální drag & drop systém. Widget se tahem myší přesouvá do webového kontejneru na stránce, který je v administračním prostředí zobrazen políčkem s již obsaženými widgety. Každé políčko nese název, který identifikuje webový kontejner v dokumentu. Nevýhodou je nemožnost inicializace widgetu do míst, kde je text článku tedy hlavní obsah stránky. Políčka jsou identifikována názvem, který se snadno zapomíná a uživatel neví, kam widget na stránku přesně přesouvá.

Obrázek 2.3: WordPress prostředí Jak vypadá struktura widgetu můžeme vidět níže:


10

class My_Widget extends WP_Widget { function My_Widget() { // widget actual processes } function form($instance) { // outputs the options form on admin } function update($new_instance, $old_instance) { // processes widget options to be saved } function widget($args, $instance) { // outputs the content of the widget } } register_widget('My_Widget');

Shrnutí Rozšiřitelnost je jedna z důležitých vlastností dobrého CMS systému. Poskytovat podporu ze strany CMS se zdá být klíčové. Velmi dobře řeší rozšiřitelnost systém WordPress, který jednoduchým systémem drag & drop inicializuje widget na stránku. Poskytuje také administrační prostředky pro widget i modul. Prostor pro zlepšení je pak v jednoduchosti, a to inicializovat widget přímo na stránce bez nutnosti administračního rozhraní, které převádí dokument do nepřehledné podoby.

Kapitola 3

Použité technologie V následující kapitole si popíšeme použité technologie a důvod použití těchto technologií v aplikaci. Aplikace je napsána v jazyce PHP 5.3. Rozhodnutí pro jazyk PHP vychází z mé znalosti tohoto jazyka a mému záměru se tomuto jazyku věnovat i do budoucna.

3.1 HTML 5 HTML5 je rozšiřující specifikace jazyka HTML, v současnosti ve stádiu návrhu organizací W3C. Tato specifikace přináší mimo jiné nové HTML značky a atributy. Aplikace využívá především nových atributů jako jsou data atributy nebo contenteditable atribut [9].

3.2 WYSIWYG WYSIWYG je akronym anglické věty „What you see is what you get“, česky „co vidíš, to dostaneš“. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce, vzhledově totožná s výslednou verzí dokumentu. WYSIWYG editory webových stránek umožňují jejich rychlejší tvorbu, aniž by vyžadovaly hlubší znalost jazyka HTML [12]. Pokud bychom si pomůcky pro zadávání textů na webové stránky rozdělili do „generací“, můžeme se dostat zhruba na takové dělení [3]: • Nultá generace – prostá TEXTAREA • První generace – nástrojová lišta k TEXTAREA, která do textu vkládala speciální značky 11

KAPITOLA 3. POUŽITÉ TECHNOLOGIE

12

• Druhá generace – plné náhrady TEXTAREA editačním oknem s WYSIWYG schopnostmi (FCKEditor, TinyMCE, …) • Třetí generace – ?

3.2.1 Mercury editor Projekt staví na WYSIWYG editoru 3.2, veškerá aplikační logika se vykonává prostřednictvím tohoto editoru. Editace v tomto prostředí poskytuje přímou zpětnou vazbu produktu, který vyvíjíme. Tuto skutečnost je možné přirovnat k současným kancelářským programům, kterým většina uživatelů rozumí a dokáže s nimi pracovat. Proto i projekt se snažil přiblížit se práci a pohybu (posloupnosti úkonů) uživatele tak, jak je tomu u běžně používaných kancelářských programů. Na trhu existuje již spousta vytvořených WYSIWYG editorů, které mají několikaletý vývoj, jsou dobře otestované a dobře dokumentované. Většina současných editorů se zaměřuje na formátování jednoho textového pole, nad kterým nabídne uživateli nástroje pro editaci. Jako na obrázku 3.1.

Obrázek 3.1: Ukázka WYSIWYG editoru tinyMCE Pro naše účely je toto řešení nepostačující z několika důvodů. Za prvé stránku nechceme nepřehledně zahltit těmito nástroji nad každým polem. Aplikace staví na jednoduchosti použití a nepřehlednost znesnadňuje práci. Za druhé editace WYSIWYG 3.2 se nevztahuje na netextová pole. Těmto


13

kritériím vyhovuje jen pár editorů. Jeden z nich je i námi použitý Mercury editor. Mercury pracuje s HTML5 3.1. Stránku rozděluje na oblasti, které lze a na oblasti, které nelze editovat. Nad celým dokumentem pak zobrazí panel nástrojů, který dovoluje formátování a editaci těchto editabilních kontejnerů. Mercury je psán částečně v Coffee scriptu, částečně JavaScriptem, který využívá služeb frameworku jQuery 3.5 (zejména pro manipulaci s DOM modelem) [1]. Prioritně byl Mercury psán s ruby on rails server side podporou, později přibyla (zatím neúplně zdokumentovaná) nezávislost na použitém backendu. Mercury editor se do stránky vloží jedním mercury_loader.js souborem, který po načtení stránky vezme tento načtený obsah, vytvoří iframe, vloží obsah do iframu a inicializuje se. Mercury využívá HTML5 atributu contenteditable, který nabývá hodnot true a false. Ten se stará o editabilnost v prohlížeči – ukazatel myši se promnění v kurzor a text lze editovat. Mercury editor má jedno omezení a tím je nekompatibilnost mezi prohlížeči. (přijde až se standartem HTML5). Tím je administrace obsahu prostřednictvím WYSIWYG editoru omezena pouze na prohlížeč Mozilla.

3.2.2 Aloha editor Další editor, který splňuje kritéria je aloha editor. Aloha pracuje jako většina WYSIWYG editorů. Zobrazí panel nástrojů jen nad editovanou oblastí. Rozdíl je v tom, že tento panel nástrojů se objeví jen jednou na stránce a nad oblastmi se přesouvá. Je tak přehlednější než např. tinyMCE na obrázku 3.1.

3.2.3 Konečné rozhodnutí V době vývoje se uživatelsky přívětivější editor stal Mercury editor. Ovšem inicializace obsahu do iframu a přegenerovaný Coffee script do JavaScriptu, značně ztíží vývoj a úpravy editoru. Možný vývoj aplikace do budoucna bude směřovat k změně, právě k aloha editoru.

3.3 Nette Jako backend aplikace je použit PHP framework nette ve verzi 2.0. Framework ulehčuje práci programátora a zavádí dobré zvyklosti pro psaní kódu pravě v PHP. Backend řeší logiku serverových částí. Od zpracování AJAXových požadavků od Mercury editoru až po logiku generování HTML kódu.


14

3.3.1 MVC Model-view-controller (MVC) je softwarová architektura, která rozděluje datový model aplikace 3.3.1.1, uživatelské rozhraní 3.3.1.2 a řídicí logiku 3.3.1.3 do tří nezávislých komponent. Tím jednak aplikaci zpřehledňuje, usnadňuje budoucí vývoj a umožňuje testování jednotlivých části zvlášť.[6] 3.3.1.1 Model Model je datový a zejména funkční základ celé aplikace. Je v něm obsažena aplikační logika. Jakákoliv akce uživatele (přihlášení, změna hodnoty v databázi) představuje akci modelu. Model si spravuje svůj vnitřní stav a ven nabízí pevně dané rozhraní. Voláním funkcí tohoto rozhraní můžeme zjišťovat či měnit jeho stav. Model o existenci view nebo kontroleru neví. Pojem Model představuje celou vrstvu, nikoliv samostatnou třídu.[6] 3.3.1.2 View View, tedy pohled, je vrstva aplikace, která má na starost zobrazení výsledku požadavku. Obvykle používá šablonovací systém a ví, jak se má zobrazit ta která komponenta nebo výsledek získaný z modelu.[6] 3.3.1.3 Controller Řadič, který zpracovává požadavky uživatele a na jejich základě pak volá patřičnou aplikační logiku (tj. model). Poté požádá view o vykreslení dat. Obdobou kontrolerů v Nette frameworku jsou presentery.[6]

3.3.2 Zpracování požadavku Každý požadavek na aplikaci se dostane přes soubory index.php a bootstap.php do objektu application. Soubor bootstrap.php představuje ”zavaděč” aplikace. Stará se o správné načtení Nette, načtení konfigurace z config.neon, nastavení routování 3.3.5 a nakonec samotné spuštění aplikace. Application ale HTTP požadavkům nerozumí, proto požádá router, aby mu ho přeložil. Tedy aby mu řekl, pro který presenter je požadavek určen a kterou akci s ním chce vykonat. Postupně prochází masky routy (na pořadí masek záleží) a hledá shodu, která mu řekne, který presenter a akce požadavek obslouží. Pak už jen vytvoří objekt presenteru (o to se postará PresenterFactory) a zavolá příslušnou metodu akce render. Následně přistoupí presenter k vykreslení příslušné šablony. Třída presenteru musí být potomkem třídy Nette\Application\UI\Presenter, pokud je presenter widget pak musí být potomkem třídy BaseWidgetPresenter. [6]


15

3.3.3 Adresářová struktura aplikace Nette nám nepřikazuje konkrétní adresářovou strukturu aplikace, je možné ji kdykoliv změnit. Aplikace má tuto strukturu: • app • libs • log • temp • www app Složka app obsahuje samotné zdrojové kódy a šablony aplikace. Aplikace je rozdělena na tzv. moduly. Modul rozděluje logiku aplikace do menších srozumitelných částí. Hlavním modulem aplikace je modul FrontModule, který obsahuje mimo jiné také modul WidgetModule, kde se nacházejí všechny widgety 4.2 aplikace. libs Složka libs slouží k umístění knihoven třetích stran, které aplikace využívá. V tomto adresáři se nachází právě nette a databázová vrstva dibi, kterou si popíšeme v kapitole 3.4. log Do adresáře log, se ukládají informace o vyjímkách při běhu aplikace, jako jsou například chybová hlášení. Nette toto ukládání chybových hlášení používá pouze v produkčním prostředí. Ve vývojovém prostředí odchytává vyjímky laděnka frameworku nette. Laděnka slouží k vizualizaci chyb a vyjímek. temp Adresář temp slouží pro dočasné soubory, převážně cache a data sezení. www Složka www je jedinou složkou, která je veřejně přístupná z webu. Obsahuje složky pro JavaScript, css, obrázky a jiné veřejně dostupné dokumenty.

3.3.4 Latte Ačkoliv je PHP původem šablonovací jazyk, k jejich kódování se příliš nehodí. Zápis je poměrně nepřehledný a nesmí se zapomínat na volání htmlSpecialChars. Proto vznikají v PHP nejrůznější šablonovací systémy. Jeden z šablonovacích systémů je i součástí nette a nese název Latte.


16

Latte umožňuje používat tzv. makra, neboli značky latte, které se po zpracování latte procesorem nahradí PHP kódem. Nette obsahuje několik značek výchozích, které jsou k dispozici zde [7], ale nabízí možnost napsat si i makra vlastní.

3.3.5 Routování Routování je překládání mezi URL a akcí presenteru. Routy jsou definované v app/boostrap.php. Aplikace používá tzv. hezká URL, pro tyto URL musí být na servru povoleno mod_rewrite. Aplikace v tomto směru nesvazuje programátorovi ruce a dovoluje i přesto nastavovat a získávat GET data z requestu (hodí se zejména při psaní widgetů 4.2). Více na [8]

3.4 Dibi Dibi je databázová vrstva od stejného tvůrce Davida Grudla jako je nette framework. Obsahuje několik driverů pro různá databázová jádra. Aplikace využívá MySQL databázi. Dibi představuje velké usnadnění práce se získáním a zpracováním dat z databáze. Není třeba se zde rozepisovat a popisovat práci s dibi, podrobný popis je k dispozici zde [4].

3.5 jQuery Dalším použitým frameworkem je JavaScriptový framework jQuery 1.7. JQuery je lehká, malá JavaScriptová knihovna, která klade důraz na interakci mezi JavaScriptem a HTML. [10] jQuery nabízí následující funkce: • Výběr DOM elementů pomocí otevřeného cross-browser selektorového enginu Sizzle, odnože projektu [2] • Funkce pro procházení a změnu DOM (včetně podpory pro 1–3 a základní XPath) • Události • Manipulace s CSS • Efekty a animace • AJAX • Rozšiřitelnost • Utility – např. informace o prohlížeči nebo funkce each


17

• Javascriptové pluginy JQuery je knihovnou také pro Mercury editor. V aplikaci se využívá například pro manipulaci s DOM modelem, zpracování formulářů nebo AJAX.

Kapitola 4

Popis API Aplikace mimo přímou editaci statických stránek umožňuje psát tzv. rozšíření — widgety. Pro takové widgety poskytuje API a usnadňuje tak jejich vývoj a nasazení do projektu. Widget může (a nemusí) nést aplikační logiku, zároveň není ošizen o možnosti poskytované frameworkem nette, proto je jejich vývoj velmi snadný. Nyní si popíšeme možnosti widgetu a API poskytované aplikací.

4.1 AvailibleWidgets.xml Aplikace je modulární, proto veškerý kód programátora se soustředí do jednoho adresáře. V tomto adresáři se také vyskytuje XML dokument availibleWidgets, který obsahuje a popisuje seznam widgetů v aplikaci. Na základě tohoto dokumentu se později widgety nabízejí uživateli ve WYSIWYG editoru. Příklad takového dokumentu je níže:

18

KAPITOLA 4. POPIS API

19

<widgets> <widget presenter="Article" action="detail"> Článek detail článek, detail <description>Widget zobrazí detail článku /img/default.png

Zdrojový kód 1: ukázka availibleWidgets.xml

4.2 Widget Widget aplikace je odlišný od konkurenčních CMS, nejedná se o klasické rozšíření systému, ale webová aplikace je složena z widgetů samých. Widgety tvoří veškerou logiku vyvíjené aplikace. To znamená zjednodušení práce a do budoucna znovupoužitelnost kódu. Widget je v aplikaci třída, přesněji presenter. K tomu aby aplikace správně přistupovala k widgetu a rozumněla mu je nutné, aby widget dědil třídu BaseWidgetPresenter. To zajistí možnost využívat všech možností nette a otevře programátorovi ruce při psaní zdrojového kódu. Požadavek na stránku se pak rozčlení na požadavky, na jednotlivé widegety. To jak se widget obslouží, tedy jaký presenter a akce, popisuje xml dokument availibleWidgets 4.1. Presenter a akce vychází ze struktury nette. Presenter se musí nacházet v adresáři presenter a k tomu příslušná šablona k akci v adresáři templates s názvem .latte. V presenteru widgetu se zavolá metoda render, které se předají parametry widgetu – ty lze i explicitně volat metodou $this->getParam(). Po zpracování presenteru se předají parametry šabloně a ta se vykreslí. Tento průběh zpracování požadavku vychází z frameworku nette 3.3.2.

4.3 Akce widgetu Kromě výše zmíněných postupů vycházejících z nette, je k dispozici přidaná funkcionalita nad widgetem, a to jsou akce nad widgetem. To umožňuje


20

administrovat widget přímo ve WYSIWYG editoru bez nutnosti přepínání se do administrace stránek, tedy hlavní funkcionalita systému. Akci reprezentuje třída ActionControl, ta může nabývat dvou základních stavů z pohledu uživatelského prostředí. Jedním z nich je, že akce vyvolá javascriptové okno např. s formulářem či námi definovanou zprávou. Druhou možností je akce, která nevyvolá vizuálně žádnou změnu, žádne okno, ale pošle jen AJAXový požadavek na server s daty předané metodě. Akcí může být na widget více, z toho důvodu akci předáváme třídě ActionList, která reprezentuje kolekci akcí. Tuto kolekci už pak předáme šabloně. V šabloně pak máme k dispozici latte makro ActionList 4.5, kterému předáme instanci třídy ActionList. Příklad s použitím viz kapitola 6.

4.4 Akce widgetu nad položkou Akce widgetu jdou ještě dál a je možné definovat jakousi položku widgetu a nad ní pak definovat akce. Jako příklad pro pochopení může sloužit testovací aplikace blog, která je popsána v kapitole 6. V této kapitole je zmínka o widgetu pro výpis článků v podobě nadpis a perex pod sebou. Nadpisem je položka widgetu a perex může být druhá položka widgetu. Celý nadpis + perex článku může tvořit další položku widgetu. Nad touto položkou pak definujeme akce např. odebrat, změnit kategorii a podobně. Použití je stejné jako při definici akce nad celým widgetem. Rozdíl je jen v tom, jaká data si při požadavku na akci posíláme. Typicky tato data obohatíme o identifikátor objektu. V našem případě je to ID článku. Použití je k vidění zde 6.1.2. O vykreslení se stará stejné makro ActionList 4.5 a opět záleží na nás, kde ovládací prvky akcí vykreslíme.

4.5 Makro ActionList Nette umožňuje využít síly latte filtrů a dopsat makra vlastní, systém definuje makro ActionList, které zjednodušuje výpis kolekce akcí na widget či položku widgetu. Jeho použití nepotřebuje dlouhé vysvětlení. Stačí předat šabloně instanci třídy ActionList a v šabloně použít latte značku {ActionList $pom}. Makro neudělá nic víc, než nad promněnou $pom vypíše.

4.6 Parametry widgetu Instance widgetu může dostávat také nějaké parametry, které uživatel zadává při vkládání widgetu (nebo za běhu při změně nastavení widgetu). Při vkládání nebo změně nastavení widgetu, Mercury editor posílá AJAXový


21

požadavek na server, který obslouží presenter příslušného widgetu pod akci Options. Zavolá se tedy metoda renderOptions a ta typicky vrací formulář s nastavením widgetu. Pokud widget parametry nemá a nevyžaduje je, stačí aby metoda vracela prázdný formulář, na který widget nebude nijak reagovat. Následná práce s parametry v kódu widgetu je jednoduchá. Aplikace zachovává standarty frameworku nette 3.3 a parametry se předávají metodě render pod jmény formulářových polí. Parametry si lze vyžádat i externě, a to metodou $this->getParam().

4.7 Parametr urlParam Widget může dostávát také jeden speciální parametr $urlParam, a to na stránkách kde je povoleno zanoření –– zanoření na stránce říká, že / předá řízení stránce s a v parametru $urlParam se předá . Tím nejsme vázáni jen na get parametry, ale můžeme tvořit komplexněji aplikace pomocí widgetů a zachovávat tak hezké seo (optimalizace internetových stránek pro internetové vyhledávače [11]) optimální url. Jeho využití je znázorněno v kapitole 6.

4.8 Makro easy-edit Další možností je reagovat na uložení widgetu (tlačítko vlevo nahoře v panelu widgetu 5.5). Nad elementem můžeme definovat HTML5 atribut contenteditable. Tento element pak prohlížeč zobrazí volně k editaci (textové editaci). To velmi zrychlí administraci widgetu uživatelem a prográmatorovi aplikace poskytuje příjemné prostředky pro realizaci a zpracování. Pro realizaci zde máme přímo v šabloně latte makro n:easy-edit="$value", který řekne, že příslušný element je editabilní. Zároveň hodnotou $value definujeme jméno elementu, pod kterým se data posílají AJAXem na server. Hodnotou $value může být i pole, kde prvním prvkem je jméno elementu při uložení a druhým je hodnota atributu contenteditable. Ten může nabývat dvou hodnot false a true. Při hodnotě false není obsah editabilní. Systém tedy atribut použije jako klíč pole při posílání požadavku k uložení na server. Elementy tvoří stromovou strukturu a posílají se jako pole. Pole je k dispozici ve widgetu v POST parametrech jako $_POST["<presenter>:"]. Příklad takového zápisu v šabloně může vypadat např. takto:


22

{foreach $articles as $article}

id}"> {$article->title}

{$article->shortText}

{/foreach}

Zdrojový kód 2: ukázka makra n:easy-edit Tento zdrojový kód vypíše pro každý článek z $articles nadpis a perex. A jak bude kód přeložen po zpracování latte filtry na výstupu je vidět níže.

Nový článek

Perex

Zdrojový kód 3: makro easy-edit — výstup A jak vypadá pole, které se pošle na server při uložení vidíme zde:


23

$_POST['<presenter>:'][$article->id]['title'] = $article->title $_POST['<presenter>:'][$article->id]['shortText'] = $article->shortText Zdrojový kód 4: struktura dat při uložení widgetu

4.9 Web container Web container je další nette makro. Toto makro má své uplatnění v layoutu stránky. Layout je rozložení stránky společné pro všechny podstránky, vycházející ze struktury nette [5]. Systém nechce zavádět další uživatelsky obtížně srozumitelný atribut stránky jako rozložení – layout. Proto systém atribut layout uživateli ani nenabízí, umožňuje však programátorovi s layoutem pracovat a zachovává tak zažité procesy s nette 3.3. Web Conteiner definuje webový kontejner, který bude editabilní z WYSIWYG editoru. Bude možné inicializovat widgety do kontejneru, přidávat statický text a vše, co jen Mercury editor poskytuje. Makro má jediný parametr a to je unikátní identifikátor kontejneru.

Kapitola 5

Uživatelské rozhraní V této kapitole si popíšeme rozhraní poskytnuté uživateli editorem a práci v tomto rozhraní. Rozhraní se zobrazuje pouze přihlášeným uživatelům v roli ADMIN. Role ADMIN a nepřihlášený uživatel jsou jediné uživatelské role aplikace. Začneme s editorem jako takovým. Mimo základní funkce, které poskytuje většina WYSIWYG editorů jako je např. formátování textu, Mercury editor nabízí řadu dalších přidaných funkčních prvků, které si postupně projdeme.

5.1 Šablona Šablona v aplikaci představuje obdobu šablony kancelářských nástrojů pro vytváření a editaci dokumentů. Stránku, respektive její webové kontejnery 4.9 se při uložení jako šablona, zkopírují do tabulky s obsahem šablony, kde nezávisle existují. Následně při použití šablony se do stránky zkopíruje tento obsah a nahradí obsah stránky šablonou. Následná editace stránky obsah šablony nijak neovlivní, což zrychlí a zpříjemní editaci webových stránek.

5.2 Stránka Aplikace umožňuje spravovat webové stránky. Stránky zachovávají standardně stromovou strukturu. Všechny požadavky na stránku zpracuje jediný presenter PagePresenter, který se stará o načtení obsahu. Obsah je latte šablona 3.3.4, která se načte z databáze.

24

KAPITOLA 5. UŽIVATELSKÉ ROZHRANÍ

25

5.3 Náhled uživatelského rozhraní

Obrázek 5.1: Náhled uživatelského rozhraní Na obrázku 5.1 je zobrazeno uživatelské rozhraní aplikace, kterou si později vytvoříme v kapitole 6. Zobrazená stránka je detail článku. Obsahuje 3 widgety. Widgety jsou vizuelně odděleny podbarvením. Podbarvení se stejně jako nástrojová lišta 5.2 zobrazují pouze přihlášeným uživatelům.

5.4 Nástrojová lišta

Obrázek 5.2: Nástrojová lišta 1. Uložit stránku – Uloží obsah stránky. U widgetu uloží jeho nastavení ne však widget samotný (akce save). 4.8 2. Uloží stránku jako šablonu – Známé z kancelářských programů, lze vytvořit novou šablonu, či přepsat stávající. 3. Krok vzad – Vrátí původní akci vzad.


26

4. Krok vpřed. 5. Odkaz – Vyznačenou oblast obohatí o odkaz. 6. Media – Vloží multimediální komponentu, např. youtube video. 7. Tabulka – Poskytuje nástroje pro tvorbu a editaci tabulek. 8. Speciální znak – Vloží speciální znak. 9. Widget – Nabídne dostupné widgety. 10. Poznámky – Zobrazí poznámky ke stránce, které si mohou uživatelé napříč aplikací sdílet. Poznámka se váže na URL. 11. Editovat stránku – Zobrazí editační formulář pro danou stránku. 12. Vytvořit novou stránku – Zobrazí editační formulář pro novou stránku. Pod popsanými nástroji se nacházejí běžné nástroje na formátování textu. Nyní se zaměříme na ty nástroje a jejich ovládání, které nejsou v základním balíčku Mercury editoru. Jsou to „Save as template“, „Widget“, „Edit page“ a „New page“.

5.4.1 Save as template Uloží stávající obsah tj. všechny editabilní kontejnery a jejich statický obsah se všemi instancemi widgetů jako šablonu 5.1. Tato šablona se dá později načíst do stránky. Stránka nemusí být nová, aby mohla být načtena z šablony. Pokud ovšem nahraji šablonu do stávající stránky s již existujícím obsahem, systém původní obsah zahodí a nahradí jej novým z šablony. Následnou editací stránky, která má obsah z šablony, obsah šablony nijak neovlivní.

Obrázek 5.3: Uložit jako šablonu Šablonu můžeme vytvořit novou ze stávajícího obsahu na stránce, kde zadáme jen jméno nové šablony. Nebo přepsat již existující – rozhraní nám dá na výběr z existujících šablon.


27

5.4.2 Widget Po kliknutí na ikonu widgetu, editor nabídne seznam dostupných widgetů, které získá z dokumentu availibleWidgets.xml 4.1. Widgety jsou řazeny podle pořadí v xml dokumentu. Mezi widgety lze vyhledávat. Vyhledávání porovnává vyhledávaný řetězec s klíčovými slovy zadanými v xml dokumentu. Tlačítko widget je dvoustavové. Po kliknutí zobrazí panel dostupných widgetů, po opětovném kliknutí panel schová.

Obrázek 5.4: Widget panel Drag&Drop tahem myší za ikonu lze widget inicializovat do kontejneru na stránce 4.9. Po vložení do stránky se pozadí widgetu vizuálně podbarví pro rozlišení typu obsahu na stránce. Samotný widget má také svůj panel nástrojů, který je zobrazený níže.


28

Obrázek 5.5: Widget akce Editované části widgetu jsou ohraničeny červenou barvou. V tomto případě je povolen nadpis článku a perex k editaci. V levé části výseče widgetu se zobrazují nástroje společné pro všechny widgety. Je to zleva: nastavení widgetu, smazat widget a uložit widget – nebo spíše uložit editabilní pole widgetu 4.8. Naopak v pravé části výseče widgetu se zobrazují nástroje pro programátorem definované akce 4.3. V tomto případě zleva: odebrat článek, změnit kategorii článku a přidat článek.

5.4.3 Edit, new page Umožňuje spravovat existující stránku 5.2, na které se právě nacházíme, či vytvořit stránku novou. Při volbě ”nová stránka” jsme požádání o vyplnění formuláře, poté budeme přesměrováni na nově vytvořenou stránku.

Obrázek 5.6: Edit, new page • Jméno – Jméno stránky, podle jména stránky se také generuje URL stránky. • Nadřazená položka – URL nadřazené stránky. Nadřazená stránka také ovlivňuje URL stránky. Stránky tak zachovávají stromovou strukturu. • Zanořovat – Zanořovat je parametr stránky, který určuje chování stránky po zadání URL. Více zde 4.7.


29

• URL – adresa stránky. • Hlavní stránka – Příznak určující zda je stránka úvodní/hlavní stránkou, po zadání adresy serveru se přesměruje na URL stránky s tímto příznakem. • Výchozí stránka (404) – Příznak určující stránku, které se má předat řízení při odpovědi s kódem 404 stránka nenalezena. • Nahrát šablonu – Obsahuje výběr s dostupnými šablonami, které lze nahrát jako šablonu 5.1.

Kapitola 6

Tutorial V této kapitole si podrobně ukážeme, jak vytvořit widget, jak ho oživit a jak z jednotlivých widgetů aplikaci sestavit. Naší ukázkovou aplikací bude jednoduchý blog, kde jsou články rozděleny do kategorií. Základem jsou dvě stránky. První obsahuje pod sebou nadpis článku a perex v kategorii a druhá je s detailem článku, který obsahuje postupně pod sebou následující: nadpis článku, text článku, tagy k článku (klíčová slova), komentáře k článku a formulář pro přidání komentáře k článku. Obě stránky mají menu obsahující kategorie článků. To nám rozdělí aplikaci do následujících modulů. • Článek náhledy • Článek detail • Článek komentáře • Kategorie článků • Tagy k článkům • Náhledy článků k tagu Všechny widgety tvoří logiku aplikace s článkem. Vytvoříme si tedy presenter ArticlePresenter ve složce WidgetModule/presenters – kde jsou všechny presentery všech widgetů. Podědíme třídu BaseWidgetPresenter, která je potomkem Nette presenteru. To nám zachová všechny výhody nette frameworku 3.3.

6.1 Článek náhledy Zobrazuje všechny články v kategorii jako náhled. Náhled tvoří nadpis a perex článku. Sekce obsahuje dvě podsekce. V první 6.1.1 si vyrobíme jednoduchý widget pro výpis zmíněného titulu článku a perexu. A v druhé 6.1.2 tento widget rošíříme a ožívíme o vlastnosti, které nám aplikace umožňuje. 30

KAPITOLA 6. TUTORIAL

31

6.1.1 Základní funkcionalita Nejprve si rozmyslíme, jaké parametry pro tento widget potřebujeme. Nám postačí parametr „počet“ – udávající počet zobrazených článků na stránce (pro test bez stránkování, i když nám nette dává příjemné nástroje pro jeho realizaci, např. třída Paginator). Dalším parametrem je kategorie, kterou chceme zobrazit a posledním pak stránka nebo spíše URL stránky kam bude odkazovat detail článku. Začneme tím, že widget přidáme do *.xml dokumentu „availableWidgets“. Více o tomto dokumentu zde 4.1 <widget presenter="Article" action="articles"> Článek náhledy článek, náhled <description> Widget zobrazí pod sebou náhledy článků s krátkým popisem článku /img/default.png

Zdrojový kód 5: availableWidgets.xml Tím řekneme, že náš widget s názvem „Článek náhledy“ obslouží presenter ArticlePresenter s akcí articles. Znamená to taky, že po dotazu na nastavení (parametry) widgetu 4.7 dotaz obslouží presenter ArticlePresenter a akce articleOptions 3.3.2. Nyní přejdeme do zdrojového kódu samotného widgetu, kde je cílem získat data z databáze a předat data šabloně k vykreslení. To provedeme jednoduše následujícím způsobem.


32

namespace FrontModule\WidgetModule; use \dibi; class ArticlePresenter extends \FrontModule\BaseWidgetPresenter { public function renderArticles($pocet, $categoryId, $detailId) { $articles = $this->articleManager ->getArticlesDataSource() ->where("categoryId=%i", $categoryId); if($pocet > 0) $articles->applyLimit($pocet); $this->template->articles = $articles->fetchAll(); /* * ... další rozšiřující vlastnosti kódu 6.1.2. */ } } Zdrojový kód 6: renderArticles Metodě se předávají nějaké parametry, ty představují námi zmíněné parametry widgetu, které jsme si rozmysleli na začátku sekce. Jak se parametry do metody dostaly a pod jakými jmény jsou k dispozici si popíšeme později. Důležité je, že máme k dispozici v členské proměnné $this->template, objekt šablony, které předáváme proměnné. Ve složce templates, pak tuto šablonu articles.latte vytvoříme. A v ní pak články vypíšeme.


33

{extends none} {ActionList $actionList} {foreach $articles as $article} {ActionList $actionItems[$article->id]}

getUrl()}/{$article->id}"> {$article->tittle}

{$article->shortText}

{/foreach}

Zdrojový kód 7: šablona article.latte Pro každý článek $articles cyklus vypíše nadpis a perex. V šabloně jsou použity latte 3.3.4 makra, vycházející z nette a kromě toho také námi definovaná značka n:easy-edit, popisující datovou strukturu, která se pošle při uložení widgetu na server. Jejím parametrem je buď hodnota, nebo pole o dvou prvcích definujicích hodnotu a editabilnost html tagu, nad kterým je volána. Toto makro je detailněji popsáno zde 4.8. Dalším neobvyklým makrem je ActionList, kde je parametrem instance třídy ActionList. Toto makro má svůj podrobný popis zde 4.3. A jsme téměř v cíli, data jsme z databáze získali, předali šabloně a ta je vykreslila. Zbývá nám jen napsat obsluhu na akci articleOptions, která zpracovává požadavek na nastavení (parametry) widgetu. Typicky při vložení widgetu, či úpravě nastavení již existujícího widgetu na stránce. My budeme chtít vypsat formulář: Vytvoříme tedy příslušný latte soubor s šablonou pro akci articleOtptions.latte. Nyní do metody renderArticleOptions v ArticlePresenteru napíšeme kód, který se má vykonat po vyžádání tohoto nastavení.


34

public function renderArticlesOptions() { $form = new \Nette\Forms\Form(); $form->addText("pocet", "počet"); $categoryList = $this->categoryManager->getCategorySource() ->fetchPairs('id', 'name'); $form->addSelect('categoryId', 'Kategorie', $categoryList); $pageArray = dibi::query("SELECT * FROM page WHERE zanorovat = '1' ORDER BY name") ->fetchPairs('id', 'url'); $form->addSelect('detailId', 'Detail článku', $pageArray); $form->addSubmit("ok", "vlozit"); $this->template->form = $form; } Zdrojový kód 8: widget nastavení - renderArticleOptions Úmyslně je v presenteru dotaz na databázi, a to na stránky, které mají povolené zanořovaní. To souvisí s tím, jak jsme se rozhodli generovat URL článku. Stránka, na kterou chceme odkazovat, musí umět přijímat parametry, tj. stránka s URL se objeví po dotazu na url /cokoliv, kde cokoliv bude náš parametr článku. Více o tomto parametru zanořování zde 4.7 A jak se o datech z formuláře dozvíme při zpracování widgetu? Budou přístupné jako parametry funkce pod jmény formulářových polích. V našem případě se tedy metodě renderArticles předá $pocet, $categoryId a $detailId 6. Parametry jsou také přístupné prostřednictvím poděděné metody $this->getParam().

6.1.2 Rozšiřující vlastnosti V této sekci si popíšeme nepovinné funkční požadavky na widget. V našem případě widget „Článek náhledy“. V šabloně se pracuje s URL stránky, kde se nachází detail článku. Stránku ID, jsme definovali v parametrech widgetu. Předá se tedy jednoduše jako parametr metodě. Stránku nám stačí podle ID nalézt a předat šabloně. Kód samozřejmě patří do obsluhy akce articles.


35

$pageManager = new \FrontModule\PageManager(); $this->template->pageDetail = $pageManager->getPageById($detailId);

Zdrojový kód 9: Stránka s detail článku Nyní si napíšeme obsluhu widgetu na save tlačítko. Obsluha widgetu při uložení se nachází ve stejné akci a presenteru jako widget samotný. Pokud i přesto z nějakého důvodu potřebujeme poslat data jinam, můžeme použít akce easy-edit třídy ActionList. Jak se data editabilních prvků posílají na server se dozvíme zde 4.8. $saveData = \Nette\Environment::getHttpRequest() ->getPost("Article:articles"); if ($saveData) foreach ($saveData as $idAtricle => $article) dibi::query("UPDATE article SET ", $article, "WHERE id=%i", $articleId); Zdrojový kód 10: Obsluha uložení widgetu Nyní se podíváme detailněji na definovatelné akce nad widgetem 4.3. Náš výpis článku bude umožňovat 3 takové akce. První je přidat článek, druhá je odebrat článek a třetí je změnit kategorii článku. (akce upravit článek není zapotřebí, článek lze editovat přímo a na uložení reagujeme obsluhou viz výše). Akce přidat článek je pouze jedna na celý widget kdežto akce odebrat a změnit kategorii musí být specifikována na každý článek widgetu. Takto vytvoříme akci přidat článek a předáme ActionList šabloně:


36

// vytvořím kolekci akcí $actionList = new \FrontModule\ActionList(); // vytvořím konkrétní akci $list = new \FrontModule\ActionControl('Přidat článek'); // nastavim(volitelně) ikonu $list->setIcon('icon-plus'); // řeknu co se pošle na server při akci (ajax) $list->setActionBind(array('akce' => 'pridat')); // přidám akci do kolekce $actionList->addAction($list); // předám akci šabloně $this->template->actionList = $actionList;

Zdrojový kód 11: Akce widgetu Metoda setActionBind 4.3 předpokládá v prvním parametru data, která se posílají spolu s požadavkem na akci. Druhým parametrem je volitelně URL, na kterou se data pošlou a třetí volitelný parametr je metoda jakou se data posílají POST nebo GET. V tomto případě se pošle pole 'akce' => 'pridat' na tento widget ve výchozích POST parametrech. Ostatní akce se váží na položku widgetu – na článek. To znamená, že kolekci akcí musíme definovat pro každou položku zvlášť. To provedeme následovně.


37

$actionItems = array(); // pro každý článek foreach ($articles AS $article) { // vytvořím kolekci akcí $actionList = new \FrontModule\ActionList(); // konkretní akci odebrat $list = new \FrontModule\ActionControl('Odebrat'); // nastavim si (volitelně) ikonu $list->setIcon('icon-minus'); // řeknu co se pošle s akcí na server $list->setActionBind( array( 'id' => $article->id, 'akce' => 'odeber' ) ); // přidám akci do kolekce $actionList->addAction($list); // akce upravit kategorii $list = new \FrontModule\ActionControl('Upravit kategorii'); // nastavím si (volitelně) ikonu $list->setIcon('icon-list-alt'); // nastavím callback, který obslouží požadavek na ajaxove okno $list->setPopUpWindowService( 'Article:articles', 'changeArticleCategory'); // nastavím data, která se pošlou na server // nyní však je nastavené JS vyskakovací okno, // data se tedy pošlou při požadavku na toto okno $list->setActionBind(array('articleId' => $article->id)); // přidám akci do kolekce $actionList->addAction($list); // kolekce předam do pole, které následně dám šabloně k vykreslení $actionItems[$article->id] = $actionList; } // AkcionLists předám šabloně k vykreslení $this->template->actionItems = $actionItems;

Zdrojový kód 12: Akce widgetu nad položkou Nejzajímavějším na tomto kusu kódu je doposud nepoužité volání metody setPopUpWindowService, které způsobí, že akce vyvolá JavaScriptové


38

okno, které zašle požadavek na Widget v prvním parametru a s akcí udanou v druhém parametru. V našem případě tedy jak zpacování, tak i následnou obsluhu provede presenter ActionPresenter a akce changeArticleCategory. Výsledkem této akce může být opět formulář jako v nastavení (parametrech) widgetu. Metoda setActionBind říká, co se pošle jako parametr požadavku na tuto akci. V tomto případě je to id článku. $form = new \Nette\Forms\Form(); // obsluha if (isset($_POST['ulozit'])) { $val = $form->getHttpData(); $this->articleManager ->updateArticle( array( 'categoryId' => $val['categoryId'] ) ,$val['id'] ); } $defaultArt = $this->articleManager ->getArticlesDataSource() ->where('id=%i', $_POST['articleId']) ->fetch(); $categoryList = $this->categoryManager ->getCategorySource() ->fetchPairs('id', 'name'); $form->addSelect('categoryId', 'Kategorie', $categoryList) ->setDefaultValue($defaultArt->categoryId); $form->addHidden('id') ->setValue(isset($_POST['articleId'])?$_POST['articleId']:''); $form->addSubmit("ulozit", "Uložit"); $this->template->form = $form;

Zdrojový kód 13: Obsluha akce widgetu Pokud jsme nedefinovali jinak, tak obsluhu akcí odebrat a přidat provádíme ve stejném presenteru a akci.


39

if(isset($_POST['akce'])) { if ($_POST['akce'] == 'odeber') $this->articleManager->deleteArtice($_POST['id']); if ($_POST['akce'] == 'pridat') $this->articleManager ->insertArticle( array ('tittle' => '', 'shortText' => '', 'categoryId' => $categoryId) ); } Zdrojový kód 14: Obsluha akce položky widgetu O nic víc se starat nemusíme. Aplikace sama přegeneruje příslušný widget. Ostatní widgety analogicky naprogramujeme. Přiložené CD obsahuje blog dokončený.

Kapitola 7

Pohyb Uživatele Když už máme všechny widgety hotové, přejdeme do aplikace a stránku z widgetů sestavíme. V této kapitole si projdeme postup vložení widgetů na stránku a pohyb uživatele.

7.1 Login V aplikaci je nutné se pro zobrazení WYSIWYG administrace přihlásit. Přihlášený uživatel musí mít práva Administrátora. Příhlášení je dostupné na URL adrese /login. Pro testovací účely je uživatelské jméno admin a heslo admin.

7.2 Nová stránka Nejprve vytvoříme novou stránku kliknutím na tlačítko ”New page”, volba 12. obrázku 5.2. Aplikace nám nabídne formulář 5.6, kde vyplníme pár základních údajů o stránce a klikneme na uložit. Novou stránku můžeme klidně nastavit jako hlavní stránku. Parametr zanořovat je zbytečný, proto jej uvedeme do volby ”Ne”, protože stránka nemusí přijímat žádné parametry v URL. Název stránky zvolíme tak, jako například název první kategorie.

7.3 Inicializace widgetu Potom co jsme stránku uložili, nás aplikace automaticky na stránku přesměruje a můžeme začít editovat. Klikneme na 9. volbu obrázku 5.2 ”Widget”. To nám rozbalí nabídku dostupných widgetu jako na obrázku 5.4. Tahem myší za ikonu, inicializujeme widget do oblasti. Před vložením na stránku, widget zavolá formulář s nastavením widgetu (parametry widgetu). Po odeslání formuláře se widget AJAXem inicializuje na stránku. Tímto způsobem vložíme widgety ”Kategorie článku” a ”Článek náhledy”. 40

KAPITOLA 7. POHYB UŽIVATELE

41

7.4 Práce se šablonou Takto vytvořenou stránku si můžeme ”uložit jako šablonu”, volba 2. obrázku 5.2. Tento krok způsobí zkopírování obsahu včetně inicializovaných widgetů (i s nastavením) do databáze šablon. Nyní při tvorbě další stránky s další kategorií článků, můžeme vycházet z této šablony a na stránce jen upravit parametry widgetu. V našem případě kategorii článku.

7.5 Zbytek aplikace Další typ stránky je detail článku. Ten vytvoříme velice obdobně. V podstatě jen přesouváme myší widgety na místo do oblasti, kde widget chceme mít a následujeme formuláře, které widget nabídne. Předpokládá se prvotní zásah programátora, který napíše widgety na míru zákazníka a sestaví aplikaci. Uživatel je pak sám schopen administrace stránek.

Kapitola 8

Závěr Podařilo se dosáhnout cílů bakalářské práce a přenést co možná největší rozsah administrace do WYSIWYG editoru. S výsledkem jsem spokojený a doufám, že vnutí myšlenku vývoje správy webových aplikací tímto směrem. Obsah této kapitoly obsahuje jedinou sekci a to budoucí vývoj aplikace.

8.1 Budoucí vývoj aplikace Jak jsem již naznačil budoucí vývoj aplikace bude směřovat k možné změně Mercury editoru na Aloha editor. Hlavní nevýhodou Mercury je nekompaktibilita mezi prohlížeči. Aloha editor by tento problém částečně řešil. Další směr vývoje bude snaha ještě více zefektivnit vývoj widgetů, ještě více zjednodušit a zpříjemnit uživatelské prostředí. Dalším směrem je rozšíření knihoven o funkcionalitu běžných CMS jako je lokalizace a internacionalizace nebo například souborový systém.

42

Literatura [1] Jeremy Jackson. Mercury Editor [online]. 2011. Dostupné z: http: //jejacks0n.github.com/mercury/. [2] jQuery Foundation. jQuery - dokumentace [online]. 2012. [cit. 3. 4. 2012]. Dostupné z: http://cs.wikipedia.org/wiki/JQuery. [3] Martin Malý. Konečně opravdové WYSIWYG editory! [online]. 2011. [cit. 14. 9. 2011]. Dostupné z: http://cs.wikipedia.org/wiki/ WYSIWYG. [4] Nette Foundation. Databázová vrstva dibi - dokumentace [online]. 2012. Dostupné z: http://dibiphp.com/cs/dokumentace. [5] Nette Foundation. Nette dokumentace - layout [online]. 2012. Dostupné z: http://doc.nette.org/cs/presenters#toc-sablony. [6] Nette Foundation. Nette dokumentace - MVC [online]. 2012. Dostupné z: http://doc.nette.org/cs/presenters. [7] Nette Foundation. Nette dokumentace - Výchozí Latte makra [online]. 2012. Dostupné z: http://doc.nette.org/cs/default-macros. [8] Nette Foundation. Nette dokumentace - Routování [online]. 2012. Dostupné z: http://doc.nette.org/cs/routing. [9] Wikipedia. HTML5 [online]. 2012. [cit. 11. 5. 2012]. Dostupné z: http: //cs.wikipedia.org/wiki/WYSIWYG. [10] Wikipedia. jQuery [online]. 2012. Dostupné z: http://docs.jquery. com. [11] Wikipedia. Search Engine Optimization [online]. 2012. [cit. 7. 4. 2012]. Dostupné z: http://cs.wikipedia.org/wiki/Search_Engine_ Optimization. [12] Wikipedia. WYSIWYG [online]. 2012. [cit. 14. 4. 2012]. Dostupné z: http://cs.wikipedia.org/wiki/WYSIWYG. 43

WYSIWYG administrace webových aplikací

Recommend Documents

id}"> {$article->title}

Nový článek

getUrl()}/{$article->id}"> {$article->tittle}