WP Framework – Configy – poslední část puzzle


Když už máme model, který nám data načítá, máme presenter, který nám data zobrazuje, chybí nám už pouze nějaký způsob těch dat, které je potřeba definovat napevno v kódu. Ať je to interní nastavení v podobě pole, nebo držení nějakých hodnot v rámci definovaných zakládáních objektů. Jasně, jasně… Máme functions.php – ale to jsme si snad už vysvětlili, ne?

K čemu v naší logice používáme configy my?

  • Definice formulářů, které potřebujeme volat napříč celým projektem.
  • Definice konstant, které jsou v rámci dané části potřeba.
  • Některé funkce, které nám vrátí nastavení, které chceme mít pevné bez možnosti zásahu uživatele.

Dost ale mluvení, pojďme si ukázat, jak u nás takový config vypadá doopravy – to řekne určitě víc, než tisíc slov.

KT_WP_Post_Config



class KT_WP_Post_Config {
        const GPS_FIELDSET = "kt-gps-fieldset";
	const GPS_LNG = "kt-gps-lng";
	const GPS_LAT = "kt-gps-lat";

	public static function getGpsFieldset(){
		$fieldset = new KT_Form_Fieldset(self::GPS_FIELDSET, __("Nastavení GPS", KT_DOMAIN));
		$fieldset->setPostPrefix(self::GPS_FIELDSET);

		$fieldset->addText(self::GPS_LNG, __("LNG", KT_DOMAIN))
			->addRule(KT_Field_Validator::REQUIRED, __("LNG hodnota pro GPS musí být zadána", KT_DOMAIN));

		$fieldset->addText(self::GPS_LAT, __("LAT", KT_DOMAIN))
			->addRule(KT_Field_Validator::REQUIRED, __("LAT hodnota pro GPS musí být zadána", KT_DOMAIN));

		return $fieldset;
	}

	const ADRESS_FIELDSET = "kt-adress-fieldset";
	const ADRESS_STREET = "kt-adress-street";
	const ADRESS_CITY = "kt-adress-city";
	const ADRESS_PSC = "kt-adress-psc";

	public static function getAdressFieldset(){
		$fieldset = new KT_Form_Fieldset(self::ADRESS_FIELDSET, __("Adresa", KT_DOMAIN));
		$fieldset->setPostPrefix(self::ADRESS_FIELDSET);

		$fieldset->addText(self::ADRESS_STREET, __("Ulice", KT_DOMAIN));

		$fieldset->addText(self::ADRESS_CITY, __("Město", KT_DOMAIN));

		$fieldset->addText(self::ADRESS_PSC, __("PSČ"))
			->setInputType(KT_Text_Field::INPUT_NUMBER)
			->addRule(KT_Field_Validator::INTEGER, __("PSČ musí být celé číslo"))
			->addRule(KT_Field_Validator::LENGTH, __("PSČ musí mít přesně 5 číslic", 5));

		return $fieldset;
	}
	
	const GENERIC_FIELDSET = "kt-generic-fieldset";
	const GENERIC_IMAGE = "kt-generic-image";
	const GENERIC_SELECT_CATEGORY_ID = "kt-generic-select-category-id";
	const GENERIC_SELECT_CUSTOM_POST_TYPE_ID = "kt-generic-select-custom-post-type-id";
	const GENERIC_RADIO_USER_ID = "kt-generic-radio-user-id";
	const GENERIC_SWITCH_DISPLAY_STATUS = "kt-generic-switch-display-status";
	
	public static function getGenericFieldset(){
		$fieldset = new KT_Form_Fieldset(self::GENERIC_FIELDSET, __("Další funkce formuláře", KT_DOMAIN));
		$fieldset->setPostPrefix(self::GENERIC_FIELDSET);
		
		$fieldset->addImage(self::GENERIC_IMAGE, __("Výběr obrázku z mediální knihovny", KT_DOMAIN));
		
		$categoryManager = new KT_Taxonomy_Data_Manager();
		$categoryManager->setTaxonomy(KT_WP_CATEGORY_KEY);
		
		$fieldset->addSelect(self::GENERIC_SELECT_CATEGORY_ID, __("Výběr kategori", KT_DOMAIN))
			->setDataManager($categoryManager);
		
		$customPostTypeManager = new KT_Custom_Post_Data_Manager();
		$customPostTypeManager->setQueryArgs(array(
			"post_type" => "movie",
			"posts_per_page" => -1,
			"orderby" => "title",
			"order" => "ASC"
		));
		
		$fieldset->addSelect(self::GENERIC_SELECT_CUSTOM_POST_TYPE_ID, __("Výběr příspěvku", KT_DOMAIN))
			->setDataManager($customPostTypeManager);
		
		$userManager = new KT_WP_User_Data_Manager();
		$userManager->setUserRole("administrator");
		
		$fieldset->addRadio(self::GENERIC_RADIO_USER_ID, __("Volba WP Usera s rolí administrátor", KT_DOMAIN))
			->setDataManager($userManager);
		
		$fieldset->addSwitch(self::GENERIC_SWITCH_DISPLAY_STATUS, __("Field pro stav ANO / NE", KT_DOMAIN));
		
		return $fieldset;
	}
}

Na první pohled šílený co? Ty konstaty, funkce, objekty kterým nikdo nerozumí. Ale začetli jste se do kódu trochu víc? Ne? Zkuste to ještě jednou a pak se zepteje, zda je něco, co Vám není jasné. Že tomu nerozumíte? To je jasné, kód našeho FW nebyl nikdy publikovaný, ale je Vám z toho jasné, co to asi bude dělat?

Co jsme takovým config souborem získali?

Nyní, když budu někde potřebovat vypsat formulář pro zadání některých z výše popsaných filedsetů, stačí mi zavolat statickou funkci na objektu, která mi vrátí jeho instanci – stačí pak již jen dále pracovat. Jak to funguje u nás? Dejme tomu, že chceme napsat metabox (to jsme Vás už naučili) a potřebujeme tam zobrazit nějaký ten formulář pro uložení dat na základě naší definice fieldsetů.

Založím si metabox, vytvořím mu callback funkci:



function kt_metabox_callback( $post ){

      $fieldset = KT_WP_Post_Config::getGenericFieldset(); // z configu si načtu instanci fieldsetu

      $form = new KT_Form(); // založím si objekt KT_Form pro práci s formulářem
      $form->addFieldSetByObject($fieldset); // do objektu formuláře přidám fieldset, který jsem si načetl z configu
      echo $form->loadDataFromPostMeta($post->ID) // načtu data z postMetas u příslušného ID příspěvku
                ->getInputsToTable();  // načtená data a celý fromulář s popisky vypíšu do přehledné tabulky.

}

A je to! Nyní budu mít u příspěvku (nebo jiného post_typu) metabox, kde budou zobrazeny příslušné vstupy dle mého konfigu.

A jak ty data jako uložím? Prosté!


add_action( "save_post", "kt_save_post_data_callback" );

function kt_save_post_data_callback( $post_id ) {
      $fieldset = KT_WP_Post_Config::getGenericFieldset(); // opět si stáhnu potřebný fieldset z configu
      $form = new KT_form(); // založím objekt pro práci s formulářem
      $form->addFieldsetByObject($fieldset); // předám mu fieldset
      $form->validate()->saveFieldsetToPostMeta( $post_id ); // provedu validaci a uložím data

      // pokud nejsou data validní, funkce neprovede uložení a vrátí uživatele zpět a vypíše chyby.
}

 

Náročné, že? A právě díky tomu, že mám data definované na jednom místě, mohu je volat napříč projektem. Jak při vykreslování dat, při ukládání nebo jiné činnosti. Nic nepíšu dvakrát, nic nemusím duplikovat. Vždy se dotazuji na jeden zdroj.

Závěrem

Configy nám pomáhají držet některé stavy a definice věcí, které by uživatel neměl mít možnost nějak nastavovat nebo měnit. Také jsou jednotným zdroje názvů, dat a parametrů – není tedy třeba některé kódy nebo názvy opakovat. Pokud potřebujeme následně provést některé změny, provádíme je také na jednom místě, což nám rozhodně šetří čas a čas jsou přeci peníze.

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.