WP Framework – myšlenka modelů


Když jsme jednou s Martinem seděli u piva po předání jednoho z projektů, chvástám se, jak se mi ty naše presentery líbí, jak je to skvělá a přehledná věc. Jako obvykle se Martin nad technickou myšlenkou ušklíbne a prohodí myšlenku ve smyslu – „Ok, tak proč teda nemáme i nějaké modely, kde by byly data připravený pro ty presentery? Hm?“. A myšlenka byla na světě – jdeme teda na to!

Co by mělo být obsahem modelů?

Model je objekt, kde se data připravují. Nepotkáte zde žádné HTML, žádné výpisy, ani jiné části související s front-endem. Model nám slouží pro přípravu dat z DB do presenteru. Jak jsme model uchopili například my?

Zde jsem pro Vás připravil jeden z našich základních modelů pro práci s Postem – tedy obecně, následně pak tento model dědíme v případě, že zakládáme nějaké vlastní post_types. Protože je kódu poměrně hodně, připravil jsem kód na gitu – KT_WP_Post_Base_Model

Zde bych chtěl poukázat na několik důležitých částí:

  • Data jsou načtena a uložena do modelu až ve chvíli, kdy si je opravdu vyžádáte. Nedochází tak tedy ke stahování dat v případech, kdy data modelu nepotřebujete v plném rozsahu.
  • Model má připravené základní informace – autor, obrázky, kategorie, tagy a metadata. Zatím nemá komentáře – prakticky je nepoužíváme – nicméně se na ně také chystáme.
  • Našeptávač Vám bude vždy radit (pokud používáte IDE) jaké data jsou v rámci modelu dostupné.
  • Načítání případných dat lze díky getterům a setterům kontrolovat a validovat na jednom místě.
  • Model jako takový je objekt, může být tedy děděn. V případě, že budete potřebovat jiný post_type, můžete ho snadno rozšířit pouze o to co potřebujete.

Nyní Vám ukážu, jak vypadá náš presenter pro práci s postem:

Ukázku presenteru KT_WP_Post_Base_Presenter jsem opět pro jeho velikost připravil na gitu.

Zde můžete nyní vidět, jak model propojujeme s presenterem. V modelu jsou data připravena, načtena a uložena. Presenter si je následně pomocí modelu vyčítá a již připravuje HTML podobu, která se poté posílá do samotného layoutu.

Jak by mohl nyní takový layout příspěvku vypadat?

 

$postPresenter = new KT_WP_Post_Base_Presenter($post);

get_header();

if(have_posts()){
	while(have_posts()){
		// ZDE BUDOU DATA POSTU

		the_title();  // titulek

		the_content(); // obsah příspěvku

		echo $postPresenter->getListOfLinksToTerms("category"); // výpis kategorií, kde se příspěvek nachází s prolinkem na jejich výpis

		echo $postPresenter->getListOfLinksToTerms("post_tags"); // výpis tagů, kde se příspěvek nachází s prolinkem na jejich výpis

		echo $postPresenter->getThumbnailImage("thumbnail", array("alt" => $post->post_title)); // náhledový obrázek o velikosti thumbnail a altem jako titulek postu.

		echo $postPresneter->getModel()->getGallery()->getImageGallery(); // vytvoří gallerie ze všech obrázků, které jsou u příspěvku nahrané

		echo $postPresenter->getModel()->getMetaValue("kt-banner-src"); // z wp_postmeta vrátí hodnotu na klíči kt-banner-src u příspěvku

		echo $postPresenter->getAuthor()->getFullName(); // Náš základní model autora má funkci FullName, která vrátí Jméno a příjmení v jednom

	}
}


get_footer();


Začíná to dávat už trochu smysl? Zde vidíte, že stačilo zavolat jeden presenter, který má v sobě všechna data připravená. Stačí teď jen vzít HTML a osadit „bloky“ s daty a dodat pouze styl. V případě, že bychom měli pracovat například s postem, který bude prezentovat automobil, udělali bychom si nový model, podědili bychom model základní a dopsali jen pár funkcí, které by se starali o ty věci, které má vůz proti příspěvku navíc. Například: cena, nějaké parametry, atd. Poté nový presenter, který bude opět dědit ten základní a dopsání pár funkcí, které z dat zhotoví HTML.

Co se nám nejvíc na této logice modelů a presenterů osvědčilo?

Velmi často řešíme větší projekt, kdy máme řadu modelů, řadu presenterů a configů (na ty se dostaneme příště). Musíme nějak organizovat svou práci v teamu (zatím pouze dvou lidí, ale kdo ví). Někdo dělá HTML a CSS, někdo píše zase více logiky aplikace. Celý proces následně vypadá tak, že Martin připraví modely, configy a logiku aplikace. Já si pak založím presenter, kde si načtu jeho model a hned vidím, jaké data mám připravené, v jaké jsou podobě (díky IDE). Mohu je již pouze osadit do presenteru a připravit HTML a CSS – tedy nasadit data na frontend.

Vím, že si asi možná řeknete – ježiš, dyť tohle řeší šablonovací systémy – a ano, máte naprostou pravdu. Všimli jste si ale někdy, kolik výkonu zaberou? A WordPress už tak není žádný rychlík. :-)

Závěrem

Tato logika Vám pomůže více udržet oddělený kód aplikace od samotného front-endu. Můžete snadno dělit práci na to, co je potřeba naprogramovat od toho, co je potřeba jen zobrazit návštěvníkům. Některé funkce a logiky napíšete pouze jednou a již je dále používáte opakovaně prakticky v každém projektu. Šetří to tak čas a peníze Vašich klientů. Stejně jako výkon aplikace, protože se vše děje vždy pouze jednou – model si načtena data uchová pro další použití již sám.

Protože máme dnes již definovaný model, příště si podíváme na config, který bude definovat hlavně část databáze pro model.

Přijeďte na naše školení do Prahy

Významné poděkování mému kolegovi Martinu Hlaváči, který do logiky presenterů, modelů a configů zavedl opravdu skvělý pořádek a smysl.

Tomáš Kocifaj, KTStudio.cz

 

, , , ,

Komentáře jsou uzavřeny.