Poznámky k návrhu CMS Kdyby

Máš to vymyšlený hezky. U CMSek se mi líbí, že je opravdu spousta způsobů, jak systém pojmout a žádný není ten jediný správný. :) Jedno CMS na Nette mám napsané a při prohlížení Tvého konceptu si říkám: „Vida, tohle taky není až tak špatný nápad“ :). Osobně jsem šel trochu jinou cestou – možná cestou trochu menší modulárnosti. Jde o to, že můj výtvor je spíše takovým CMF (Content Management Framework), který mi sice umožňuje „sekat jako cvičky“ běžné webové prezentace s požadavky na kompletní správu (prostě produkt, který je ode mě v praxi nejčastěji vyžadován), ale nefunguje ale typem: do téhle složky nahraj moduly a ty pak zaktivuj. Což je možná nedostatek, kdo ví, jak to je ;).

Líbí se mi ten koncept on-fly vkládání modulů do stránky a držím palce – udělat to dobře nebude triviální. Tohle jsem pojal jednodušeji (hlavně z časových důvodů, měl jsem na vývoj toho systému omezený čas). Já mám v systému určitě typy stránek, které uživatel může vytvořit. Typem je například „Základní obsahová stránka“ či „Základní obsahová stránka s kontextovou fotogalerií“ a podobně. Ty typy jsou i s popisy, takže uživatel dobře ví, co ten či který typ znamená. Tvorba nové stránky se děje pomocí průvodce, kde prvním krokem je právě výběr typu stránky. V dalším kroku průvodce obsahuje většinou nějaké základní vlastnosti (umístění ve stromu webu, název stránky, SEO kraviny a podobně), v dalším pak definici hlavních obsahů, pak checkboxy s tím, které sdílené obsahy má stránka sdílet (jsou to různé postranní boxy a tak, každý typ stránky má přesně dáno, které obsahy může sdílet) a u speciálních typů je těch kroků více (například ta fotogalerie). Modifikace vypadá potom tak, že jsou ty jednotlivé kroky v tabech (záložkách).

Zní to hodně jednoduše, ale v praxi se to velmi osvědčilo. Je to velmi BFU friendl a běžné menší weby si vystačí s několika málo typy stránek. Pokud by počet typů stránek měl narůstat, dá se řada věcí přesunout do základních vlastností stránek (například zda na stránce zobrazovat kontaktní formulář a tak, nemusí být stránka typu „Stránka s kontaktním formulářem“).

Ale to on-fly umisťování komponent je samozřejmě hezčí a velmi se těším, jak se s tím popereš.

Mám jedno jediné doporučení – stanov si priority a milníky, při jejichž dosažení bude vždy nějaká plně funkční verze. Ono totiž to, co jsi napsal, je velký balík a budeš-li se snažit vše implementovat ve verzi „0.1“, riskuješ, že se to zase dostane do fáze mrtvého projektu… Třeba například vývoj Nelly IMHO tak nějak zamrzl (i když si netroufám říct, zda to je či není vyloženě mrtvý projekt) a je to škoda. Ale stává se to velmi snadno.

Hodně zdaru :).

No není zač :). Pro zajímavost poodkreji některé další vlastnosti mého systému, třeba by Tě ještě něco mohlo inspirovat. Zároveň si říkám, že bych taky mohl připravit alespoň nějaké demo. Pod volnou licencí ten projekt se ale prozatím uvolňovat nechystám – dalo by to spoustu práce (zdokumentování) a celkově vzato, podobné CMF beru už jako určitý kapitál :).

Routování

Takovým srdcem je router, který tahá stránky z databáze. Ty jsou uloženy jako traversal strom, kdy router je hledá podle URL. Ten můj má takovou vychytávku, že když stránku nenajde, snaží se ještě zjistit, zda adresa například „sluzby/ubytovani/galerie“ nevede náhodou na presenter stránky „sluzby/ubytovani“ a na view „galerie“ (prostě zkouší najít „sluzby/ubytovani“ a když tuhle stránku nalezne, vezme její presenter a view „galerie“). Umí to takhle zjišťovat až pro kombinaci <action>/<id>. Jaký to má smysl? Jde o to, že některé typy stránek mohou mít více view a odkazy na ně si samy generují. Dejme tomu, že uživatel založí stránku typu fotogalerie a nastaví jí URL „o-nas/fotogalerie“. Ten typ stránky má v databázi nastavený jako presenter „Fotogalerie“ a jako defaultní view například „default“. Na tenhle presenter a view povede URL „o-nas/fotogalerie“ (router samozřejmě předá presenteru i nějaké page ID). Ten typ stránky si ale automaticky umí vygenerovat i odkazy na například view „detail“ a podobně, dokonce umí vygenerovat i odkazy typu „o-nas/fotogalerie/detail/nejaka-fotogalerie“, což router zachytí a jako presenter nastaví zmíněný „Fotogalerie“, jako view „detail“ a předá ID „nejaka-fotogalerie“. Má to výhodu ve velké nadvládě na URL adresami, kamkoliv do stromu webu se dá umístit prakticky cokoliv.

Samozřejmě to přináší možnosti mnoha kolizí, ty jsou ale řešeny v adminu – při úpravě URL stránky se kontroluje, zda všechny její view náhodou nekolidují s nějakou jinou URL adresou (zkouší se normální match na databázovém routeru). Ta kontrola byla úděsná piplačka. :) Jinak každý typ stránky má v databázi nejen svůj presenter a defaulntí view, ale i informaci o tom, zda view může být „přetíženo“. Pokud ne (většina typů stránek), předchozí detekce view se vůbec neděje. Je to zbytečné /i když to vlastně jenom urychlí generování 404 :)/.

Presentery

Dlouho jsem přemýšlel, jak vhodně objektově reprezentovat stránku, až jsem nakonec skončil u toho, že nejlepší bude co nejvíc využít Nette a stránky jsou prostě reprezentovány presentery. Frontend je vcelku jednoduchý (jde jen o správné namapování routerem), v backendu to mám následovně: určitý typ stránky (reprezentovaný například presenterem Front_Fotogalerie) má svou analogii i v backendu (Admin_Pages_Fotogalerie). V adminu používám upravenou třídu Route tak, aby pobírala i submoduly (ta v Nette to bohužel neumí), takže v adminu mám presentery například pro různá nastavení (Admin_Settings), správu záhlaví a zápatí (Admin_GlobalContentsPresenter) atd. a velký submodul Pages s presentery pro všechny typy stránek. Pro každý typ lze pak nezávisle definovat, jakou přesně bude mít formu průvodce pro vytvoření stránky toho typu a jaké záložky budou pak dostupné pro editaci. Samozřejmě tam platí to, že základní kroky lze dědit z nějakého abstraktního předka, takže to není, že by se pro každý typ znovu definovaly všechny kroky i s formuláři. Je to docela DRY. :)

Výkon

Velmi doporučuji kešovat všemožné rekurze nad stromem webu a podobně. Věci jako generování globální navigace, kontextové navigace, drobků a podobně… Přestože se s použitím traversal stromu tahají z databáze poměrně efektivně, rekurzi se stejně člověk nevyhne (například pro převod stromu webu do multidimenzionálního pole) a ty rekurze jsou performance killer.

No, šlo by psát asi ještě dlouho :). Ale tak třeba z toho načerpáš nějakou inspiraci. Hodně zdaru přeju :).

díky díky :)

ad routování: trochu jsem se v tom ztratil, ale v zásadě moje routování by mělo fungovat tak že základem bude ta <node>, popř další proměnná, která když bude splněna tak se to odkáže ve stromě výše při neshodě ostatních parametrů v ->extend() což by mělo být něco jako píšeš ty :)

ad presentery: stránka jako taková bude mít obsah v databázi, podle url se vybere <node> a přiřadí se presenter s pohledem a ten obsah zformátuje, url nebude ovládána jménem presenteru, ale uživatelem a vzorem jaký bude dovolovat Modification

ad výkon: s kešováním se počítá :)

Tak já mám taky něco podbného ve výrobě (už asi rok :)), beží na tom i nějaké weby. Je to teda primárně zaměřené na malé živnostníky (bfu), takže to nemá, až tak pokročilé funkce.

Nicméně to mám řešené tak, že jednotlivé moduly (File, Page, Comment…), mají backend řešený jako presentry a Frontend přes komponenty. Kdy je pak jeden modul Frontend a v něm si pak tahám obsah přes ty komponenty z jednolivých backend modulů, takže třeba {widget menu:main} {widget page $id} atd. Jediné o co se stará frontPresenter je načíst slug z url a podle něj poslat id do šablony, případně prohodit šablonu.
Výhodný mi to přijde v tom že se pak dobře skládá jednotlivá stránka, když ma mít komentáře, tak zavolám widget stránky a widget komentářů… Ten Frontend se nemusí pak routovat do jednolivých modulů.

Co mi dělalo největší problém a pořád mi to nepřijde dobré je propojení modulů. Třeba když přidám modul na komentáře, tak chci do formu pro stránku přidat možnost povolení těch komentářů. Tak teď to řešim že se každý formulář odesílá do metody, kde se na něj podle jeho názvu navěsí další prvky (ty se načítají z jednolivých inicializačních tříd modulů (asi něco jako tvůj loader)) a callbacky na zpracování. Ale to mi přijde strašně kostrbaté, sice to funguje skutečně modulárně, ale nelíbí se mi to. Docela by mě zajímalo jak tohle plánuješ? Nebo prostě pro komentáře bude extra tamplate při vyběru?

Vzhledem k tomu, že ty uživatelé obsah moc často nemění se všechno co jde na frontend kešuje, pak se to nemusí připojovat k db a to je docela zrychlení, zvláště u některých hostingů to připojení do db vázne.

Edit:
Koukám že mám frontend řešený podobně jako na1k, to sem rád, možná to bude dobrá cesta :D

Editoval Ani (28. 6. 2010 14:25)

No taky je to napsané pěkně pomateně, ale ono to takové ‚wtf‘ je, takže to jinak popsat nejde :D

Vlastně je to způsob řešení těch tvých adonů, kdy se jejich obsah vykresluje přes widget, který se automaticky vytvoří (v presentru i v šabloně). Z db se načte jejich seznam a v šabloně se vykreslí přes následujicí kód, díky tomu stačí univerzální šablona.

{if isset($hooks[$presenter->getName()])}
    <div class="content hook" n:foreach="$hooks[$presenter->getName()] as $hook">
        {var $c $hook['control']}
        {var $m $hook['metod']}
        {widget $c:$m $presenter->module, $id}
    </div>
{/if}

Zároveň se automaticky vytvoří ona komponenta v presentru pomocí podobné funkce.

napíšu to ještě jednou sem pro případ že fórum necpe editace do RSS …

github: https://github.com/Kdyby
vyvíjet budu veřejně, licence bude nějaká open-source ve stylu „dělej si s tím co chceš“ takže můžete vesele kuchat :)

Editoval HosipLan (11. 3. 2011 19:31)

Od zkušenějšího určitě radu nedostaneš, ale já ti k tomu svůj názor klidně řeknu. :)

V první řadě, tohle je otázka, která mě vůbec nenapadla. Napadlo mě, že může být více verzí stejného typu rozšíření/modulu (galerie, blog) a napadlo mě, že některá rozšíření by mohla vyžadovat instalaci specifické verze jiného rozšíření.

První co mě napadá, tak zasahovat do existující entity, to se mi vůbec nelíbí. Spíše bych uvažoval o využití Inheritance, nebo nějakého podobného nástroje, ale to je taky tfuj tfuj, protože bych mohl nainstalovat novější verzi některé závislosti a rozbít tim jiné věci. Je to velice komplikovaná otázka :)

Z hlediska editace a zásahů bych spíše volil možnost provazovat modely, nějak. Neměl by být problém napsat modelům konkrétního rozšíření interface a testy kompatibility.

rozšíření = service / modul / komponenta

Líbilo by se mi, kdyby každé rozšíření mělo nějaký instalátor, který by přijal instanci služby, která by se o rozšíření starala. Pomocí instalátoru by se nainstalovala/nakopírovala a tím bych měl i přehled nad tím, co se kam kopíruje a mohl tak rozšíření snadno hlídat.

rozšíření může požadovat manuální nastavení (třeba spuštění „migrace“ databáze)

Jo, proč ne

rozšíření si můžou říct o registraci vlastní „globální“ routy, tyto routy jsou spravovány managerem, který hlídá případné kolize a odmítá registraci (pak zbyde „sdílená“ routa)

Měl jsem myšlenku, která je už nějakej ten pátek rozpracovaná a ztratila prioritu, že v CMS bude instance pouze ExtendableRouteru a tento router by měl základní asi 2 nebo 3 vzory, které by jednoznačně odlišovaly url (section/node/url, node/url, url) a o vytvářené adresy by se starala administrace a hlídala by kolize.

rozšíření si musí svoje data spravovat sama, jediné, co můžou chtít, je připojení jejich entit ke společnému správci

Jsem pro možnost invalidace cache entit, který si ukládá doctrine a doplnění vyžadovaných struktur do databáze, ale raději bych viděl tabulky pro každé rozšíření vlastní, teoreticky by to tak mělo jít napsat vždy. Není přece problém napsat rozšíření, které bude kompletní fórum, eshop, …

základní entity a komponenty budou vydávat spoustu událostí, které mohou rozšíření zpracovávat (přemýšlím nad tím, jestli dovolit rozšířením po registraci i upravovat data (pak by rozšíření byly vlastně i filtry))

Doporučuji si přečíst o Symfonním Event dispatcheru který by mohl být šikovným pomocníkem :)

všechny metody a properties, které by rozšíření chtělo přidat entitě se musí popsat ručně ve stylu C# extension methods (budou jen syntaktický cukr)

Tohle se mi nelíbí, ale zavrhuji to z patra, protože není nikdo kdo by mlátil bastliče po prstech, že takhle a takhle to znásilňovat nemají. Zkrátka se mi nelíbí, že by dvě rozšíření, od různých autorů mohli jedno druhé rozšiřovat na takovéhle úrovni. Nějaký interface a testy kompatibility, ok. Ale přidávat data do existujících tabulek, „zpomalovat“ a zatěžovat tak existující rozšíření… Nevím, nevím, budu o tom ale přemýšlet.

Moje výhoda je v tom, že výsledek je určen pro programátory/vývojáře/skoro-programátory, takže si můžu dovolit víc než autor aplikací pro BFU.

Už tím, že používám Doctrine2, nepočítám, že by můj systém rozšiřoval nějaký BFU. Takže moje cílovka bude trochu jinde, ale skoro věřím tomu, že než zvládnu vydat něco použitelného, tak Patrik už mě dožene i s čísly verzí :))

Pěkný, ale jak moc je to výkonný? Aby jenom dekódování routy vyžadovalo několik dotazů do db, to je docela peklo, ne? Nebo na to máš nějaký trik? Model\Node jsem v repu nenašel

Myslel jsem si, že to tam mám rozepsané (to Node tam není, protože je to jen rozpracované :)). Router pomocí základního vzoru najde v databázi Node, která bude jedním leaf/branch (stránkou/větví) struktury webu a zjistí, které další rozšíření má následovat (proto extendable).

$router['default'] = new ExtendableRoute('/<node>', array(
  'language' => 'cz',
  'node' => Null
));


// vytvořím novou routu která bude obsahovat půvoní vzor, ale přiřadím si vlastní proměnnou
$router['default']->extend('/<category>/<articlename>'); # články
$router['default']->extend('/<date>/<gallery>'); # galerie

// v podstatě zjednodušené
$router[] = new Route('/<language>/<node>/<category>/<articlename>', array(
  'language' => 'cz',
  'node' => 'clanky'
));

->extend by měly být nadefinované v jednotlivých rozšířeních. Mělo by tak jít zjistit jaké rozšíření použít a který extend má následovat a pak se zpracuje zbytek url. Teoreticky by to mělo být ještě rychlejší než současné routy, ale to bych spíš kecal, protože se musí provést do databáze, jehož výsledek rozhodne kudy pokačovat. Ale nemusí se porovnávat všechny routy, stačí identifikovat základní vzor a pak následovat rozšíření :) Část toho je hotová, ale chybí ještě constructUrl

$article->extension('ViewCounter')->getViewCount();

Tohle vypadá podstatně lépe :) ale pořád se mi na tom něco nelíbí, smrdí to magií a určitě to porušuje i nějaké OOP principy nebo návrhové vzory.

A máš pravdu, že příklad s počtem přečtení je opravdu nevhodný, protože mě napadá v tomhle případě lepší řešení :) Něco jako:

Počet přečtení: {control viewCounter:views $article}

Což by se přeložilo jako

echo $control->getWidget('viewCounter')->renderViews($article);

Když máš 50 rout, které musíš vyhodnotit a platí až ta poslední a 3 routy, které se matchnou provedou superrychlý dotaz do databáze a máš okamžitě výsledek, myslím že to bude víc než srovnatelné :) Samozřejmě, výhoda tohohle přístupu se objeví až s narůstajícím počtem stránek a typů rout.

Návrhový vzor sem, návrhový vzor tam, mně je všechno rovno…

To není žádná hra, ale princip, který se nevyplácí porušovat :) Já nevím, prostě se mi na tom něco nelíbí, ale ještě jsem nepřišel na to, co.