Nast\u0119pnie przyjrzymy si\u0119 renderowaniu tre\u015bci na interfejsie u\u017cytkownika. Zbli\u017camy si\u0119 do ko\u0144ca refaktoryzacji Boilerplate, ale jest jeszcze troch\u0119 do zrobienia, zanim b\u0119dziemy gotowi do scalenia go z g\u0142\u00f3wn\u0105 ga\u0142\u0119zi\u0105 bazy kodu.<\/p>\n<\/blockquote>\n
Wi\u0119c w tym po\u015bcie zamierzamy tam odebra\u0107. Teraz, je\u015bli pod\u0105\u017ca\u0142e\u015b do tego momentu, powiniene\u015b mie\u0107 wszystko, czego potrzebujesz z ga\u0142\u0119zi deweloperskiej.<\/p>\n
Je\u015bli nie, pami\u0119taj, aby go wyci\u0105gn\u0105\u0107, poniewa\u017c to w\u0142a\u015bnie tam zamierzamy odebra\u0107 w pozosta\u0142ej cz\u0119\u015bci posta.<\/p>\n
WordPress Widget Boilerplate: Refaktoryzacja Cz\u0119\u015b\u0107 12<\/h2>\n
Teraz, je\u015bli chodzi o front-end, \u0142atwo jest my\u015ble\u0107 o nim jako o wszystkim, co u\u017cytkownik widzi przed sob\u0105, niezale\u017cnie od tego, czy znajduje si\u0119 w obszarze administracyjnym, czy nie.<\/p>\n
Jednak z tej serii jasno wynika, \u017ce \u200b\u200bdzielimy to, co widzi u\u017cytkownik, mi\u0119dzy obszar administracyjny i publiczny obszar witryny.<\/p>\n
Zamierzamy wi\u0119c pracowa\u0107 nad obszarem kodu, kt\u00f3ry renderuje informacje dla u\u017cytkownika w publicznym obszarze witryny. Zaczniemy od prostego przeczytania informacji i wy\u015bwietlenia ich.<\/p>\n
Nast\u0119pnie w nast\u0119pnym po\u015bcie przyjrzymy si\u0119 pracy z logik\u0105 warunkow\u0105 w odniesieniu do niekt\u00f3rych opcji, aby sprawdzi\u0107, czy jest co\u015b, co musimy zrobi\u0107.<\/p>\n
Powiedziawszy to, przejd\u017amy do kodu.<\/p>\n
O danych, kt\u00f3re b\u0119dziemy wy\u015bwietla\u0107<\/h3>\n
Pami\u0119taj, \u017ce w tym momencie wid\u017cet ma trzy rzeczy, kt\u00f3re wp\u0142ywaj\u0105 na jego wy\u015bwietlanie:<\/p>\n
- \n
- tytu\u0142 wid\u017cetu,<\/li>\n
- zawarto\u015b\u0107 wid\u017cetu,<\/li>\n
- prze\u0142\u0105cznik okre\u015blaj\u0105cy, czy powinni\u015bmy wy\u015bwietla\u0107 tytu\u0142<\/li>\n<\/ol>\n
Trzecia opcja to przede wszystkim pokazanie, jak u\u017cywa\u0107 innego typu elementu. Poniewa\u017c, technicznie rzecz bior\u0105c, je\u015bli nie chcieliby\u015bmy pokazywa\u0107 tytu\u0142u wid\u017cetu, po prostu nie umie\u015bciliby\u015bmy niczego w wid\u017cecie.<\/p>\n
Ale my\u015bl\u0119, \u017ce pomaga pokaza\u0107, jak u\u017cywa\u0107 r\u00f3\u017cnych typ\u00f3w element\u00f3w i ich warto\u015bci w praktyczny (lub p\u00f3\u0142praktyczny) spos\u00f3b.<\/p>\n
W ka\u017cdym razie, maj\u0105c to na uwadze, wiemy, \u017ce dla ka\u017cdego wyst\u0105pienia wid\u017cetu dane s\u0105 przechowywane wraz z tytu\u0142em<\/strong>, tre\u015bci\u0105<\/strong> oraz\u00a0 nazw\u0105 wy\u015bwietlanego tytu\u0142u<\/strong> i identyfikatorami dostarczonymi przez WordPress.<\/p>\n
W zwi\u0105zku z tym b\u0119dziemy u\u017cywa\u0107 ich w naszym kodzie frontonu do wy\u015bwietlania warto\u015bci.<\/p>\n
Przygotowanie funkcji wy\u015bwietlania<\/h3>\n
Zazwyczaj\u00a0 funkcja wid\u017cetu<\/strong> odpowiada za wy\u015bwietlanie danych wyj\u015bciowych wid\u017cetu. Ale jedn\u0105 z rzeczy, kt\u00f3re starali\u015bmy si\u0119 zrobi\u0107, jest oddzielenie problem\u00f3w naszego wid\u017cetu na bardziej skoncentrowany zestaw klas i funkcji.<\/p>\n
Pierwsz\u0105 rzecz\u0105, kt\u00f3r\u0105 chcemy zrobi\u0107, to napisa\u0107\u00a0 klas\u0119 WidgetDisplay<\/strong>, kt\u00f3ra b\u0119dzie odpowiedzialna za, jak na pewno wida\u0107, wy\u015bwietlanie zawarto\u015bci wid\u017cetu.<\/p>\n
Na razie b\u0119dzie to bezwarunkowo zawiera\u0107 tytu\u0142, tre\u015b\u0107 i warto\u015b\u0107, czy tytu\u0142 ma by\u0107 uwzgl\u0119dniony. WordPress udost\u0119pnia r\u00f3wnie\u017c pewne tre\u015bci, takie jak znaczniki, kt\u00f3re powinny pojawia\u0107 si\u0119 przed wid\u017cetem i po wid\u017cecie, wi\u0119c upewnimy si\u0119, \u017ce r\u00f3wnie\u017c je uwzgl\u0119dnimy.<\/p>\n
Ale najpierw po prostu odetnijmy klas\u0119<\/a> :<\/p>\n
<?php\n\nnamespace WordPressWidgetBoilerplateWordPress;\n\nclass WidgetDisplay\n{\n private $widgetSlug;\n\n public function __construct(string $widgetSlug)\n {\n $this->widgetSlug = $widgetSlug;\n }\n\n public function show($args, $instance)\n {\n \/\/ More to come\n }\n}\n<\/code><\/pre>\nNast\u0119pnie musimy si\u0119 upewni\u0107, \u017ce zapisujemy to r\u00f3wnie\u017c innym klasom. Najpierw upewnimy si\u0119, \u017ce umie\u015bcimy go w naszej klasie Widget<\/a> :<\/p>\n
<?php\npublic function widget($args, $instance)\n{\n return $this->widgetDisplay->show($args, $instance);\n}<\/code><\/pre>\nA potem dodamy go do klasy WidgetAdmin<\/a> (poniewa\u017c tutaj znajduj\u0105 si\u0119 podstawowe funkcje Widget API \u2013 po prostu deleguje odpowiedzialno\u015b\u0107 do odpowiedniej klasy):<\/p>\n
<?php\n\npublic function __construct($widgetSlug)\n{\n parent::__construct($widgetSlug);\n $this->widgetSerializer = new WidgetSerializer($this->getWidgetSlug());\n $this->widgetDisplay = new WidgetDisplay($this->getWidgetSlug());\n}<\/code><\/pre>\nW tej chwili nie wy\u015bwietlamy jeszcze niczego. Jeste\u015bmy blisko i wkr\u00f3tce si\u0119 na tym skupimy.<\/p>\n
Wy\u015bwietlanie danych<\/h3>\n
Zak\u0142adaj\u0105c, \u017ce jeste\u015b w stanie doda\u0107 powy\u017cszy kod bez b\u0142\u0119d\u00f3w, czas wy\u015bwietli\u0107 zawarto\u015b\u0107 wid\u017cetu.<\/p>\n
Mo\u017cemy to zrobi\u0107 na wiele sposob\u00f3w, od prostego var_dump<\/strong> do rzeczywistej pracy nad wy\u015bwietlaniem tre\u015bci w bardziej przyjazny dla u\u017cytkownika spos\u00f3b. A ja jestem o wiele bardziej fanem tego drugiego.<\/p>\n
Wi\u0119c zr\u00f3bmy to.<\/p>\n
W\u00a0 funkcji show<\/strong> swojej\u00a0 klasy WidgetDisplay<\/strong> dodaj nast\u0119puj\u0105cy kod<\/a> :<\/p>\n
<?php\npublic function show($args, $instance)\n{\n include_once 'Views\/Widget.php';\n}<\/code><\/pre>\n
![\"Wid\u017cety](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-160763-61e7125f80aab.png\")
<\/a><\/p>\n