WordPress-widgetit: Refaktorointi, osa 12

Mitä tulee WordPress Widget Boilerplaten uudelleenmuodostukseen – varsinkin kun otetaan huomioon, kuinka pitkälle olemme päässeet projektin alkamisesta kahdeksan vuotta sitten – olemme tehneet paljon työtä.

Olemme saaneet sen paljon nykyaikaisempaan standardiin ja teemme sen kanssa työskentelystä paljon helpompaa, jotta tulevien widgetien rakentamisen pitäisi olla helpompaa. Ja tämä ei johdu pelkästään kattilalevyn standardista, vaan oliokeskeisestä standardista, joten ylläpidon ja koodin laatu on korkeampi.

Viimeisessä viestissä päätimme suuren osan hallintoalueen työstä ja olemme valmiita aloittamaan työmme käyttöliittymän koodin parissa.

Sanoimme:

Seuraavaksi aiomme tarkastella sisällön renderöimistä käyttöliittymässä. Olemme lähestymässä Boilerplaten uudelleenmuodostuksen loppua, mutta vielä on vähän tehtävää ennen kuin olemme valmiita yhdistämään sen koodikannan päähaaraan.

Joten tässä postauksessa aiomme jatkaa siellä. Nyt jos olet seurannut tähän asti, sinulla pitäisi olla kaikki mitä tarvitset kehityshaaralta.

Jos ei, muista vetää se, sillä aiomme poimia siitä postauksen loppuosassa.

WordPress Widget Boilerplate: Refactoring osa 12

Mitä tulee käyttöliittymään, on helppo ajatella, että käyttöliittymä on mitä tahansa, mitä käyttäjä näkee edessään riippumatta siitä, onko se hallinnollisella alueella vai ei.

Tässä sarjassa on kuitenkin ollut selvää, että jaamme käyttäjän näkemän hallinnollisen alueen ja sivuston julkisen alueen kesken.

Aiomme siis kehittää koodin aluetta, joka tuottaa tietoja käyttäjälle sivuston julkisella alueella. Aloitamme yksinkertaisesti lukemalla tiedot ja näyttämällä ne.

Seuraavassa viestissä tarkastelemme työskentelyä ehdollisen logiikan kanssa joidenkin vaihtoehtojen osalta nähdäksemme, onko meidän tehtävä jotain.

Tämän jälkeen siirrytään koodiin.

Näytämme datasta

Muista, että widgetillä on tässä vaiheessa kolme asiaa, jotka vaikuttavat sen näyttöön:

1. widgetin otsikko,
2. widgetin sisältö,
3. kytkin, joka määrittää, pitäisikö meidän näyttää otsikko vai ei

Kolmas vaihtoehto on ensisijaisesti näyttää, miten erityyppistä elementtiä käytetään. Koska teknisesti, jos emme haluaisi näyttää widgetin otsikkoa, emme vain laittaisi widgetiin mitään.

Mutta mielestäni se auttaa osoittamaan eri elementtityyppien ja niiden arvojen käyttämisen käytännöllisellä (tai puolikäytännöllisellä) tavalla.

Joka tapauksessa tiedämme, että jokaisen widgetin esiintymän tiedot tallennetaan WordPressin tarjoaman otsikon, sisällön ja näyttöotsikon nimen ja tunnuksien kanssa.

Siksi käytämme niitä käyttöliittymäkoodissamme arvojen näyttämiseen.

Näyttötoimintojen valmistelu

Tyypillisesti widget – toiminto vastaa widgetin tulosteen näyttämisestä. Mutta yksi asioista, joita olemme yrittäneet tehdä, on erottaa widgetimme huolenaiheet kohdistetuiksi luokiksi ja toiminnoiksi.

Ensimmäinen asia, jonka haluamme tehdä, on kirjoittaa WidgetDisplay- luokka, joka vastaa, kuten on varmasti ilmeistä, widgetin sisällön näyttämisestä.

Toistaiseksi tämä sisältää ehdoitta otsikon, sisällön ja sen arvon, sisällytetäänkö otsikko vai ei. WordPress tarjoaa myös tietyn sisällön, kuten merkinnät, joiden pitäisi näkyä ennen widgetiä ja widgetin jälkeen, joten varmistamme, että sisällytämme myös sen.

Mutta ensin tyhjennetään luokka :

<?php

namespace WordPressWidgetBoilerplateWordPress;

class WidgetDisplay
{
  private $widgetSlug;

  public function __construct(string $widgetSlug)
  {
      $this->widgetSlug = $widgetSlug;
  }

  public function show($args, $instance)
  {
    // More to come
  }
}

Sen jälkeen meidän on varmistettava, että kirjoitamme sen myös muille luokille. Ensin varmistamme, että sisällytetään se widget-luokkaamme :

<?php
public function widget($args, $instance)
{
    return $this->widgetDisplay->show($args, $instance);
}

Ja sitten lisäämme sen WidgetAdmin-luokkaan (koska tässä ovat Widget-sovellusliittymän ydintoiminnot – se vain siirtää vastuun oikealle luokalle):

<?php

public function __construct($widgetSlug)
{
    parent::__construct($widgetSlug);
    $this->widgetSerializer = new WidgetSerializer($this->getWidgetSlug());
    $this->widgetDisplay = new WidgetDisplay($this->getWidgetSlug());
}

Tässä vaiheessa emme vielä näytä mitään. Olemme lähellä ja keskitymme siihen pian.

Datan näyttäminen

Olettaen, että pystyt lisäämään yllä olevan koodin ilman virheitä, on aika näyttää widgetin sisältö.

Voimme tehdä tämän monella eri tavalla yksinkertaisesta var_dump -tiedostosta sisällön näyttämiseen käyttäjäystävällisemmällä tavalla. Ja olen enemmän jälkimmäisen fani.

Joten tehdään se.

Lisää WidgetDisplay- luokkasi show – toimintoon seuraava koodi :

<?php
public function show($args, $instance)
{
    include_once 'Views/Widget.php';
}

Ja sitten mallin näkymä voi olla näin yksinkertainen :

<div id="<?php echo $args['id']; ?>">
    <h3 class="widget-title"><?php echo $instance['title']; ?></h3>
    <p><?php echo $instance['content']; ?></p>
    <pre><?php echo $instance['display-title']; ?></pre>
</div><!-- #<?php echo $args['id']; ?>-->

Tämä varmistaa, että kaiken widgetiä edeltävän sisällön oikea merkintä, widgetin sisältö ja sisältö renderöidään oikein.

Muista jälleen, että näytämme sisältöä, jota ei ole tämän lopullisessa versiossa, mutta olemme lähestymässä ja käsittelemme sitä seuraavassa viestissä.

Suosittelen leikkimään Näytä otsikko -vaihtoehdon kanssa nähdäksesi, kuinka se hahmonnetaan käyttöliittymässä tarjoamamme merkinnän perusteella.

Tällä hetkellä widgetin tulosteen pitäisi näyttää suunnilleen tältä:

Mutta se on kaikki mitä tässä postauksessa on katettava.

Lopulliseen Refaktoriin

Viimeinen asia, jota tarkastelemme tämän jälkeen, on ehdollisen logiikan tiukentaminen ja sana välimuistiin tallentamisesta (koska teemme sitä jo aiemmissa viesteissä).

Toistaiseksi voit kuitenkin leikitellä, mitä meillä on täällä, sekä koodilla, jota emme ole sisällyttäneet (kuten mitä voidaan näyttää ennen widgetiä tai sen jälkeen.

Ne on jätetty tarkoituksella pois tästä esimerkistä, mutta niitä ei välttämättä aina jätetä pois tekemästäsi työstä riippuen.