Pokud se používá tento framework, web se rozděluje do 3 základních částí (vrstev):

Celý eshop budvobraze.cz je založený na frameworku BitGooCz, který ale není veřejný, takže o něm není nikde na internetu možno najít jakékoli informace. Jedná se o můj vlastní framework a základní dokumentaci se pokusím sepsat do tohoto dokumentu. Přitom se budu odkazovat přímo do zdrojových kódů webu budvobraze.cz. Pokusím se ale příklady popisovat obecně, aby tento návod nebyl přímo závislý na konkrétní verzi webu. Kompletní zdrojové kódy nejsou nasazeny přímo na ostrém serveru (chybí tam nějaké zdrojové soubory, ze kterých jsou generovány jiné soubory). Ke kompletním zdrojovým kódům se lez dostat přes Subversion na adrese https://subversion.martinpopelka.savana.cz/budvobraze/devel Subversion je součástí webhostingu savana.cz, takže k přístupovým údajům se lze dostat pokud máte přístup k hostingu (toto je stav k srpnu 2013). Licence: poskytuji tímto licenci používat framework BitGooCz libovolně kýmkoli, ale pouze pro vývoj (libovolných) webů (e-shopů nebo jiných webových systémů) pro Martina Popelku. Radim Urbášek 2013

Základy frameworku Framework BitGooCz spočívá hlavně ve 3 věcech: 1) Poskytuje určité podpůrné knihovny (třídy) pro práci s webem. 2) Definuje postupy a způsob, jak by se měl web psát, aby se pomohlo jeho přehlednosti. 3) Určitou část webu přímo řídí (více o tomto dále), což zjednodušuje tvorbu celé webové aplikace. UPOZORNĚNÍ: framework je (bohužel) navržen tak, že funguje pouze když je kořenový adresář namapován na kořenovou adresu serveru. Osobně mám Apache na lokálním PC nastaven tak, že když zadám http://bvo.localhost/ tak se dostanu přímo do kořenového adresáře celé webové aplikace. Není možné aplikaci spustit např. z této adresy: http://localhost/vyvoj/www/budvobraze/ V celém webu jsou totiž používány odkazy typu takže by se přešlo na adresu http://localhost/zbozi/59, i když by to mělo být http://localhost/vyvoj/www/budvobraze/zbozi/59 Pokud se používá tento framework, web se rozděluje do 3 základních částí (vrstev):

První vrstva První vrstva obsahuje třídy, které se starají o komunikaci s databází, získávání a ukládání dat. Třídy z této vrstvy by neměly zasahovat do jiných částí webu, jen do databáze. Tzn. veškerá komunikace, která je vyvolána těmito třídami (z první vrstvy), probíhá pouze s databází (případně s jiným vnějším zdrojem, např. odesílání mailů, připojení k nějaké webové službě, ale ne s jinou částí/vrstvou webu). Spojení s touto vrstvou je děláno tak, že ji volá vrstva druhá, tzn. že ve druhé vrstvě jsou vytvořeny instance tříd z první vrstvy a ve druhé vrstvě jsou volány veřejné metody tříd z první vrstvy. První vrstvě se často říká „model“. V BitGooCz frameworku má místo hlavně v adresáři /managers. Pokud se do tohoto adresáře podíváme, vidíme tam soubory (kde každý soubor odpovídá jedné třídě), jejichž jména končí vždy Manager.php. Každý tento manager rozšiřuje třídu DefaultManager, která obsahuje proměnnou $em s instancí třídy EntityManager (je nastavena v konstruktoru). EntityManager je první součást frameworku. Je to třída usnadňující práci s databázi. Její popis následuje v dalších částech tohoto návodu. Prozatím nám stačí, že je to určitý přístup k datům z MySQL databáze.

Všechny managery tedy mají k dispozici $em (EntityManager) a jsou složeny převážně jen z metod, které dělají konkrétní operace. Např. metoda getPieceOfGoods($id) v GoodsManager nám vrátí objekt reprezentující jedno určité zboží podle jeho $id. Nebo addCountry(Country $country) v CountryManager vloží do databáze nový stát. Podrobnosti souvisí s EntityManagerem, který je popsán dále v tomto návodu. První vrstva tedy spočívá pouze ve dvou bodech, popsaných v první odstavci: tzn. že jde jen o určitá pravidla, jak zapisovat třídy (Managery) a dále framework poskytuje jednu knihovnu pro usnadnění práce (EntityManager). Takže na první vrstvě se BitGooCz framework ještě ani nechová jako framework, spíš jako kombinace knihovny a „standardu“.

Druhá vrstva Druhá vrstva ale využívá framework v největší míře a kombinuje všechny 3 body uvedené v první odstavci. Druhá vrstva, zvaná také jako controller, zjednodušeně v závislosti na požadavku (např. kliknutí uživatele na webu) vykoná určité metody různých Managerů z první vrstvy a poté předá řízení (vykonávání kódu) na třetí vrstvu (třetí vrstva se postará o vykreslení výsledku, neboli o zobrazení webu samotného). Pokud je ale něco na požadavku špatně (např. je odeslán formulář se špatnými daty), druhá vrstva na to zareaguje a podle toho zobrazí jiný výsledek (případně zavolá jiné metody z první vrstvy atd). Framework podporuje tzv. „pěkné URL“ a to velmi jednoduchým způsobem: v souboru /.htaccess je jednoduché pravidlo, které předá vše na /index.php?url=původní_podoba_url_adresy, ale jen v případě, že URL NEobsahuje tečku. Pokud obsahuje, jedná se pravděpodobně o dotaz na obyčejný soubor (např. obrázek nebo CSS) a ne „pěknou URL“ a tento soubor je zpracován normálně. Pokud tedy uživatel např. klikne na nějaký odkaz (s „pěknou URL“), tak se předá řízení na /index.php, kde se vloží (include) jádro frameworku (soubor /bitgooczfw/BitGooCzFW.php) a vytvoří instance frameworku, která se spustí (metoda run()). Vložené jádro frameworku obsahuje, kromě třídy samotné, i několik definic funkci a vloží (include) další části frameworku včetně konfiguračního souboru. Konfigurační soubor je /config.php (více o něm později). Adresář /bitgooczfw obsahuje 3 věci: 1) knihovny nutné k chodu frameworku (momentálně pouze /bitgooczfw/addendum), 2) soubory frameworku (všechny soubory začínající velkým písmenem), do kterých by se nemělo při vývoji webu vůbec zasahovat, 3) automaticky vygenerované soubory (začínající malým písmenem), kdo kterých by se také nemělo ručně zasahovat, protože jsou generovány automaticky (o tom kdy a jak se tyto soubory generují je napsáno dále). Znamená to tedy, že do adresáře /bitgooczfw se při vývoji webu vůbec nezasahuje a vývojář v podstatě nemusí vědět co v něm je a jak to funguje vevnitř. Abych se ale vrátil k původní myšlence, tak při kliknutí uživatele na nějaký odkaz (nebo odeslání formuláře atd.) se přes /index.php spustí kód frameworku, který poté řídí chod celé webové aplikace (konkrétně druhé vrstvy - controlleru). Podobně jako první vrstva má své místo hlavně v adresáři /managers, druhá vrstva má své místo hlavně v adresáři /actionbeans. Zde vidíme podobnou strukturu jako v případě adresáře managers. Jsou zde soubory končící ActionBean.php. Je tu i soubor DefaultActionBean.php, ze kterého dědí

všechny ostatní ActionBeany. Je tu ale jeden zásadní rozdíl. Zatímco Managery jsou vyvářeny (instanciovány) a jejich metody volány ve druhé vrstvě (právě v těchto ActionBeanech), tak ActionBeany jsou vytvářeny a jejich metody volány automaticky pomocí frameworku. Jednoduše řečeno, pokud chceme zobrazit zboží s ID = 5 pomocí url budvobraze.cz/zbozi/5, pak framework na základě určitých pravidel (jak jsou pravidla definována následuje dále) rozhodne o tom, že má spustit např. metodu showGoods() z GoodsActionBean. Toto je ale jen přibližný popis, ve skutečnosti je vše o něco složitější. Malá odbočka: Anotace v PHP. Anotace je definice určité datové struktury, která se vkládá do komentářů /** anotace... */ těsně před třídu, metodu nebo atribut (proměnnou třídy). Tímto je tedy možné přidat ke konkrétním metodám určité další dodatečné informace, které si framework může přečíst a podle nich pak s danou třídou naložit. Syntaxe anotací je popsána zde: https://code.google.com/p/addendum/ V BitGooCz frameworku se anotace používají hlavně v ActionBeanech. (Používají se i v tzv. Entitách, ale o tom až později.)

Event metody Zpět k ActionBeanům. Obsah ActionBeanů (tříd), tzn. jejich metody a atributy (atributem je v tomto textu myšlena proměnná definované ve třídě (mimo metodu), která má často k sobě getter a setter), jsou děleny na několik částí/skupin. Jedna skupina jsou tzv. „Event metody“. To jsou metody s anotací @HandlesEvent, např.: /** @HandlesEvent("zbozi/komentare/vlozit:post") */ public function commentInsert() { ... } Jednoduše řečeno, Event metoda commentInsert() je spuštěna, pokud uživatel požádá o URL budvobraze.cz/zbozi/komentare/vlozit a použije k tomu POST, tzn. odešle formulář. Více o zápisu @HandlesEvent a mapování URL v příloze urlMapping.txt. Event metoda by měla vždy něco vracet. Může to být např.: return new ForwardResolution("goods/comments.php"); Což způsobí, že je řízení předáno do 3. vrstvy, konkrétně do nějakého souboru goods/comments.php. Kde se ale tento soubor přesně nachází a co se pak přesně děje, o tom až později. Pro nás je teď důležité pouze to, že je tímto způsobem zobrazena určitá HTML stránka. Další možnost je vrátit následující: return new RedirectResolution("zbozi/komentare"); To způsobí, že ne nezobrazí vůbec nic, ale provede se přesměrování prohlížeče na adresu budvobraze.cz/zbozi/komentare. Což se hodí udělat po úspěšném odeslání formulářových dat, protože takhle se zabrání, kdyby někdo omylem stiskl F5, aby se formulář odeslal znovu. Ještě je možné použít JsonResolution($něco), což způsobí vypsání libovolné proměnné ve formátu JSON (hodí se u AJAXu). Jakým způsobem se přesně do formátu JSON převádí je možné najít v této metodě BitGooCzFW::jsonEncode().

Poslední možnost je vrátit cokoli jiného, což je pak zobrazeno pomocí standardního příkazu echo. Uvnitř ActionBeanu by se ale echo samo o sobě nemělo používat, např. z toho důvodu, že některé HTTP hlavičky jsou vypsány až po vykonání Event metody.

Before metody a životní cyklus ActionBeanu Kromě Event metod, je možné použít tzv. „Before metody“. Při každém požadavku je URL přeložena na konkrétní událost (event), např. „commentInsert“ a podle toho je spuštěna určitá Event metoda, např. „ commentInsert()“. Před spuštěním event metody je ale možné spustit jiné metody, které jsou přiřazeny ke stejné události. Pokud máme např. metodu s touto anotací: /** @Before(on = {"goodsDetails", "commentInsert"}, stages = "BindingAndValidation") */ public function loadGoods() { ... } Pak v případě, že má nastat událost „commentInsert“, je nejdřív spuštěna Before metoda loadGoods(), pak až EventMetoda commentInsert(). Událost (event) si tedy můžeme představit jako tok (posloupnost) několika metod, které framework postupně spouští. Celý tento tok je ale o něco složitější a má 4 (*2) fáze: 1. BindingAndValidation - pokud se používají formuláře, v této části framework validuje vstupní data z formulářů a nastaví je do určitých proměnných, kde jsou pak k dispozici nebo se postará o vypsání chyby atp.; více o tomto dále. 2. CustomValidation - v této části je možné definovat metody, které dělají nějakou komplikovanější validaci ať už dat z formulářů, nebo i jiných vstupních dat (přímo z URL). 3. EventHandling - spuštění Event metody. 4. ResolutionExecution - toto je vykonání toho, co Event metoda vrátila, tzn. přesměrování v případě RedirectResolution; vykreslení HTML stránky v případě ForwardResolution (tzn. vykonání 3. vrstvy); zobrazení JSON kódu, v případě JsonResolution; nebo zobrazení toho co Event metoda vrátila v ostatních případech. Před každou z těchto fází může být i fáze výše zmíněných Before metod. Takže parametr „stages“ v anotaci Before metody určuje před jakou z těchto fází má být Before metoda vykonána. Samozřejmě je možné mít více Before metod před stejnou fází. Je možné vykonat i jednu Before metodu před více různými fázemi, např.: stages = {"BindingAndValidation", "CustomValidation"}. Pokud máme více Before metod před stejnou fází a zároveň se všechny mají vykonat při stejné události, pak jejich pořadí určuje pořadí zápisu v kódu. Lze ho ale ovlivnit pomocí „pos“: /** @Before(pos = 3, on = "showUserAddresses", stages = "BindingAndValidation") */ Hodnota pos může být i záporná. Pokud není uvedena, výchozí je 0. Pokud mají dvě metody stejnou hodnotu pos, jejich pořadí zase určuje pořadí v kódu. Podobně jako Event metody, můžou i Before metody vracet Resolution (Forward, Redirect...). Pokud ale Before metoda něco takového vrátí, je okamžitě zastaveno další vykonávání a přejde se přímo do fáze ResolutionExecution. Je třeba upozornit na to, že toto nastane i když něco vrátí Event metoda. Tzn. že fáze Before ResolutionExecution se provede pouze tehdy, pokud všechny Before

metody i Event metoda nevrátí nic (nebo vrátí null).

Validace a chyby Framework na 2. vrstvě obsahuje i mechanizmus validace formulářových dat (data odeslaná metodou POST). Pokud chceme mít v atributu k dispozici hodnotu z formuláře, přidáme mu gettery a settery a anotaci @Validate, např.: /** @Validate(type = "string", on = {"commentInsert"}, max = 20) */ private $commentText; public function getCommentText() { return $this->commentText; } public function setCommentText($commentText) { $this-> commentText = $commentText; } Ve fázi BindingAndValidation je v případě události commentInsert přiřazena hodnota z $_POST["comment-text"] do $this->commentText. Proběhne také validace a pokud by hodnota byla delší než 20 znaků, vznikne tzv. chyba (error). Chyby jsou z ActionBeanu dostupné přes: $this->getCtx()->getErrors(). Tímto způsobem můžeme validovat základní věci, např. délku textu, velikost čísla, jestli je něco povinné nebo ne atd. Více v příloze BindingAndValidation.txt. Bez ohledu na to jestli chyba nastala nebo ne, jsou přiřazeny a validovány všechny hodnoty ve fázi BindingAndValidation. Pokud by ale chyba nastala, pak by v další fázi Before CustomValidation proběhly pouze ty Before metody, které mají ve své anotaci execWithError = true: /** @Before(on = {"editOrder"}, stages = "CustomValidation", execWithError = true) */ Další fáze se jmenuje CustomValidation. Skládá se z několika metod anotovaných @ValidationMethod, které mají hodnotu „on“, určující událost, stejně jako u Before metod. Validační metody vracejí buď prázdné pole nebo pole s chybami, které nastaly. Chyby se přidávají k těm co mohly nastat při validaci během fáze BindingAndValidation. Jaký formát by mělo mít pole chyb je uvedeno v příloze errorFormat.txt. Dále také mohou mít validační metody hodnotu execWithError = true. Tzn, že pokud by někdy předtím nastala chyba (ať už v předcházející validační metodě nebo ve fázi BindingAndValidation), validační metoda se stejně spustí. Tzn. pokud není execWithError uvedeno a nastala v předchozí validační metodě chyba, tato validační metoda se už nespustí. Jakmile jsou proveden všechny validace (po fázi CustomValidation) a zjištěny i všechny chyby, proběhne vyhodnocení chyb. Tzn. že pokud nějaká chyba nastala, další vyhodnocování se zastaví a přejde se do fáze ResolutionExecution s tím, že se vykoná předcházející Forward. Vše vysvětlí příklad: Máme stránku s formulářem. Máme tedy událost showForm. K události se váže jen Event metoda showForm(), která pouze předá řízení na soubor my-form.php, který vykreslí formulář. Tzn. že Event metoda vrátí new ForwardResolution("my-form.php"); Uživatel formulář vyplní, ale chybně. Formulář odešle, přitom se vyvolá jiná událost, např. handleForm, na kterou se ale váže několik validačních pravidel @Validate a několik validačních metod @ValidationMethod. V některých z nich

se zjistí chyby. Hned po fázi CustomValidation se stane to, že se vykoná ResolutionExecution, předcházející Forward, tedy konkrétně new ForwardResolution("my-form.php"); Znovu se tedy vykreslí stránka s formulářem. Pokud ale používáme formuláře, které jsou součástí BitGooCz frameworku (o nich později), vykreslí nám rovnou i znění chyby v závislosti na tom co našly validační pravidla a validační metody. Možná vás napadá, že framework nějak musí zjistit, jakou předchozí stránku (Forward) zobrazit. Tady je drobný háček. Tento způsob validace je možné používat i bez speciálních BitGooCz formulářů, ale pouze tehdy pokud jsme si jisti, že validace nevyhodí žádnou chybu, nejlépe pokud neproběhne vůbec. Tzn. v případě že z BindingAndValidation použijeme jen to „Binding“. Formuláře totiž odesílají i speciální kód, ze kterého framework zjistí kam forwardovat naposled (neposílá se přímo stránka kam forwardovat, takže ji nelez formulářem podstrčit). Pokud chcete používat vlastní formuláře, použijte BPage::getSystemHiddenInput($ab); kde $ab je instance ActionBeanu. Metoda vrátí skrytý , který obsahuje potřebný kód. V případě, že by nastala chyba validace a kód by nebyl zaslán nebo by byl chybný, proběhne Forward na stránku „error-no-post-id.php“. Pokud chyby nenastanou, provede se fáze Before EventHandling. Z toho plyne, že execWithError má smysl používat jen ve fázi Before CustomValidation nebo přímo při CustomValidation. Dále je to spuštění Event metody, dále, pokud Event metoda nic nevrátila je to spuštění Before ResolutionExecution a nakonec samotné ResolutionExecution. Pokud máme Event metodu mapovanou na URL „zbozi/zobrazit“, ale ve skutečnosti je za touto URL ještě něco jiného, např. „zbozi/zobrazit/58/informace“, a této celé URL neodpovídá žádné jiné mapování URL, pak se provede mapování pouze na „zbozi/zobrazit“ a zbytku, tedy „58/informace“, se říká (bohužel) Object (což je trochu zavádějící). Tento řetězec (Object) je možné v ActionBeanu získat takto: $this->getCtx()->getObject(), nebo $this->getCtx()->getObjectPart($i), kde $i je část řetězce oddělená lomítkem. Takže $this->getCtx()->getObjectPart(0) obsahuje „58“ a $this>getCtx()->getObjectPart(1) obsahuje „informace“. Vice o životním cyklu je v diagramu BitGooCzFW.v3.png.

Kontext, autentizace a autorizace DefaultActionBean implementuje rozhraní ActionBean, které mu přikazuje implementovat getter a setter pro ActionBeanContext a metodu init(). ActionBeanContext je objekt, které obsahuje různé užitečné informace a tyto informace nám do něj nastaví převážně framework. V zkratce se kontextu říká ctx (dostaneme se k němu přes $this->getCtx()) a jsou v něm k dispozici např. chyby (error) způsobené během validace, chybové a informační hlášky, které je možné zobrazovat na stránce a zůstanou k dispozici i po přesměrování pomocí RedirectResolution, výše zmíněný Object, jaká událost probíhá a další. Jednou z nejužitečnějších je ale getUser(), setUser($user), setAllowedActions($actions) a isActionAllowed($action). Metoda init() je spuštěna na začátku životního cyklu ActionBeanu a má k dispozici ctx. Není doporučeno používat konstruktory ActionBeanu, protože v nich není ctx ještě k dispozici. V init() metodě je doporučeno provést autentizaci (tzn. kontrolu, jestli je uživatel přihlášen nebo ne). Toto je zcela na vývojáři webu a framework jen požaduje, aby v případě, že uživatel přihlášen je bylo něco nastaveno pomocí $this->getCtx()->setUser(). To „něco“ bývá většinou objekt reprezentující uživatele. Pro potřeby frameworku ale stačí, aby se toto vyhodnotilo na true:

$ab->getCtx()->getUser() == true Dále je v init metodě doporučeno nastavit oprávnění uživatele. To je pole řetězců, které jsou nastaveny do $this->getCtx()->setAllowedActions($actions). Jeden řetězec reprezentuje oprávnění uživatele vykonat nějakou akci. Pojem „akce“ je vysvětlen dále. Po vykonání init metody totiž proběhne autorizace, tzn. rozhodne se, jestli má uživatel právo vykonat aktuální událost (event). K tomu slouží dvě anotace, které se přidávají k Event metodě. První je @Action: /** @Action("Spravovat zboží") @HandlesEvent({"sprava/zbozi:get"}) */ Pokud má Event metoda takovouto anotaci, znamená to, že je k ní přiřazena „akce“, kterou musí mít uživatel dovoleno vykonat. Neboli, musí se nacházet v poli nastaveném pomocí $this->getCtx()>setAllowedActions($actions). Každá událost může mít přiřazenu pouze jednu nebo žádnou akci, ale jedna akce může být součástí více různých událostí. Další anotace je @LoginRequired: /** @LoginRequired @HandlesEvent({"nastaveni/heslo"}) */ Tuto událost lze vykonat jen když je uživatel přihlášen. Tzn. $ab->getCtx()->getUser() == true. Pokud autentizace proběhne neúspěšně, proběhne hned Forward na soubor error-unauthorized.php v případě špatné @Action nebo error-not-logged-in.php v případě chyby při @LoginRequired.

Kompilace Bohužel, zpracování anotací bývá časově náročná operace. Proto je nutné provádět kompilaci. Při změně anotací v ActionBeanech nebo při velkých změnách ActionBeanů (vytvoření nového, přejmenování, smazání) je nutné spustit /bitgooczfw-compilers/BitGooCzFWCompiler.php Kompilátor také vypíše některé případné chyby v anotacích, ale ne všechny. Bohužel nevypíše syntaktické chyby v anotacích, takže na to je nutné si dávat pozor. Složku /bitgooczfw-compilers není nutné kopírovat na ostrý server.

Třetí vrstva Mnohokrát bylo zmíněno, že může být proveden tzv. Forward, pomocí ForwardResolution. Before nebo Event metoda může vrátit např.: return new ForwardResolution("goods/comments.php"); Pak se stane následující věc: ve fázi ResolutionExecution, tedy na konci životního cyklu ActionBeanu proběhne include souboru /pages/index.php nebo jiného souboru, který je nastaven

v $this->getCtx()->getLayout(). Pokud tam máme nastaveno „admin.php“, proběhne include souboru /pages/admin.php. Dále je nutné zmínit že pokud zavoláme $this->getCtx()->getForward(); vrátí se nám "goods/comments.php", neboli řetězec nastavený přes new ForwardResolution(). Poslední důležitá věc je, že v souboru /pages/index.php (nebo podobném) máme k dispozici proměnnou $ab, která obsahuje ActionBean. Když tedy v tomto souboru zavoláme $ab, je to jako bychom zavolali $this v ActionBeanu. Z toho už možná tušíte postup, jakým se pracuje s třetí vrstvou. Soubor /pages/index.php nebo např. /pages/admin.php je tzv. layout, neboli obyčejný PHP soubor, obsahující hlavně HTML kód. Tento soubor obsahuje celou základní HTML kostru, která se všude opakuje - menu, hlavičku patičku. A na místě těla webu je následující: getCtx()->getForward(); ?> Protože jsme v adresáři /pages, v našem výše uvedeném příkladě se includuje /pages/goods/comments.php. Takže všechny soubory v adresáři /pages jsou úplně obyčejné PHP soubory, které by ale měly převážně obsahovat HTML kód. Navíc v nich máme k dispozici ActionBean v $ab. V těchto souborech tak můžeme přistupovat k metodám ActionBeanu a vykreslovat tak formuláře a vlastně celý web. Je ale pravidlem, že by se ze třetí vrstvy nemělo přistupovat k metodám, které jsou spouštěné frameworkem (Before metody, Event metody, validační metody). Ve druhé vrstvě by se měla data načíst z první vrstvy a pro třetí vrstvu nachystat do atributů. Třetí vrstva pak už bude jen číst tyto atributy, např. přes get metody - gettery.

Šablony BPages PHP je samo o sobě šablonovací systém. Často je ale nutné psát velké množství kódu k vykonání jednoduchých často se opakujících věcí. Existuje spousta šablonovacích systémů, které pomáhají uspořit výše uvedené. Ve frameworku BitGooCz je použit šablonovací systém nazvaný „BPage“. Nebylo však cílem vytvořit plnohodnotný šablonovací systém, pouze pomoci v té nejotravnější věci - generování formulářů. BPage jsou tedy normální PHP + XHTML (které je ale validním XML kódem) a navíc obsahuje značky co vykreslují formuláře. Prázdná BPage obsahuje kořenovou značku: ... Je zde použit namespace http://bitgoo.cz/framework/bpages, který je navázán k prefixu „b“, takže všechny značky začínající na „b:“ jsou speciální BPage značky a ty budou přeloženy. Ostatní jsou považovány za XHTML a nechají se, podobně zápis se nechá bez změny. V konfiguračním souboru /config.php je při vývoji následující: include "bitgooczfw-compilers/BPageCompiler.php"; BPageCompiler::scan(dirname(__FILE__) . '/bpages', dirname(__FILE__) . '/pages', array( "totalWidth" => 825, "labelRatio" => 0.25, "infoRatio" => 0.3, "suffixWidth" => 50 ));

Vloží se překladač BPage a spustí se. První parametr určuje zdrojové BPage soubory, což je adresář /bpage a druhý parametr určuje výsledné vygenerované soubory /page - tento adresář už známe. Třetí parametr slouží ke konfiguraci formulářů. Při vývoji se tedy pokaždé všechny BPage přeloží znovu (což je celkem rychlé), ale při ostrém nasazení je možné tento kód z /config.php smazat a vůbec adresář /bpages nenahrávat na ostrý server. Poznámka: v eshopu budvobraze.cz Jsou skoro všechny soubory v /pages vygenerované pomocí BPages. Proto by se do nich nemělo zasahovat, protože by pak stejně byly přepsány při dalším překladu. Je zde ale několik souborů, co generovány nejsou. Proto není dobrý nápad smazat celou složku /pages a nechat si ji vygenerovat. Vygenerované soubory poznáme tak, že mají na začátku následující:

BPage formuláře ... bude doplněno ...

Práce s databází - Entity a EntityManager ... bude doplněno ...

Překlady Překlady nebyly nikdy na webu budvobraze.cz použity, ale je pro ně ve frameworku nachystána podpůrná třída. V BPage máme kromě proměnné $ab k dispozici i proměnnou $txt, přes kterou můžeme k textům přistupovat. Dělá se to pomocí její metody $txt->get(). Texty se vkládají do souboru /bitgooczfw/texts.php. Jazyk se musí nastavit pomocí metody init() a objektu implementujícího rozhraní /bitgooczfw/LocaleManagerInterface.php. Podrobnosti jsou v komentářích v souboru /bitgooczfw/BTxt.php. TODO: konfigurační soubor, utility na generování kódu