Kokemukseni mukaan tapa, jolla olemme ensimmäistä kertaa vuorovaikutuksessa arkiston suunnittelumallin kanssa, vaikuttaa usein siihen, miten ajattelemme kuviota. (Koko ensivaikutelma on pysyviä vaikutelmia, eikö niin?)
Tämän postauksen tarkoituksena on näyttää, kuinka se voidaan toteuttaa WordPressissä erityisesti kirjoitettaessa olio-laajennuksia tietojen lukemiseen (tietojen kirjoittamista voidaan käsitellä toisessa postauksessa), mutta ennen sen tekemistä yritin miettiä muutamia johdonmukaisuuksia näkemäni mallin muunnelmia.
Yleisesti ottaen arkistomallin pitäisi mielestäni tehdä näin:
- tarjota yksi paikka tietojen lukemiseen,
- tiivistää tiedot siitä, kuinka tietoja käytetään,
- ja niillä on yhtenäinen käyttöliittymä tätä varten.
Tämä tarkoittaa, että kaikki, mitä sinun täytyy hakea sovelluksesta, voidaan hakea tietokannasta. Mutta kuinka se haettiin, voidaan pitää mustana laatikona. Se on mallin toteuttavan kehittäjän tehtävä.
Ja niille, jotka lukevat tämän viestin, se on todennäköisesti me.
Arkistomalli WordPressissä
Pari vuotta sitten kirjoitin arkiston mallista antamalla konkreettisen esimerkin. Se on edelleen ajankohtainen, mutta tarkoitus, jonka haluan käsitellä tässä viestissä, on hieman erilainen.
Sen sijaan, että esittäisin tietyn toteutuksen, joka on juurtunut todelliseen esimerkkiin, haluan mieluummin ottaa kantaa siihen, kuinka voimme käyttää tätä mallia päivittäisessä työssämme.
Kaksi asiaa, jotka tulee pitää mielessä tätä lukiessa:
- käyttäjän näkökulmasta taustalla olevalla tietovarastolla ei ole väliä,
- Kehittäjän näkökulmasta malli antaa meille mahdollisuuden työskennellä useiden tietolähteiden kanssa ja myös mallintaa näytetietovaraston, jotta voimme yksikkötestata tietoja.
Mallia toteutettaessa sillä, mistä tiedot tulevat, ei ole väliä. Ainakin niin kauan kuin olet kehittäjä tai asiakasobjekti, joka kutsuu siihen. Tietovarasto voi olla tietokanta, joukko API-toimintoja tai molempien yhdistelmä.
Oletetaan siis, että työskentelet tapahtumien mukautetun postaustyypin kanssa ja käytät myös viestien metatietoja ja vaihtoehtoja, jotka liittyvät esimerkiksi tapahtumiin.
Voit tehdä jotain kuten:
- saada tapahtuman nimi,
- löytää tietoa tapahtuman paikasta,
- noutaa ensimmäisen viestityypin ja tilan sen tunnuksen mukaan
Kaikki nämä tiedot voivat olla hajallaan eri paikoissa ja tapa, jolla se haetaan, voi vaihdella.
1 Tapahtuman nimen saaminen
Jos työskentelemme mukautetun viestityypin kanssa ja meidän on saatava tapahtuman nimi, voimme käyttää viestin tunnusta ja yhtä WordPressin API-toiminnoista tehdäksesi sen.
<?php
/**
* Retrieves the title of the Event, a custom post type.
*
* @param int $eventId the ID of the event post type
* @return string the title of the post.
*/
public function getName(int $eventId): string
{
return get_the_title($eventId);
}
Tämä on yksi tapaus, jossa tietovarasto on edelleen erotettu meistä ja sen sijaan hyödynnetään olemassa olevaa WordPress-sovellusliittymää.
2 Tapahtuman paikan saaminen
Tässä tapauksessa voimme olettaa, että tapahtuman sijainti on syötetty manuaalisesti tai kenties kolmannen osapuolen sovellusliittymä on hakenut sen. Ja koska sijainti liittyy tiettyyn tapahtumaan, se voi olla postin metatietotaulukossa.
Jälleen voimme noutaa sen käyttämällä olemassa olevia API-toimintoja; kuitenkin tällaisissa tilanteissa on järkevää käyttää aputoimintoa, koska tulemme todennäköisesti käyttämään myös muita metatietoja.
Joten ensin apulainen :
<?php
/**
* A helper function for easily retrieving post meta data for a given Event.
*
* @param int $id the ID of the event
* @param string $key the key for the post meta data for which we're retrieveing the data
*
* @return string the result of retrieiving the meta data
*/
private function get(int $id, string $key): string
{
return get_post_meta($id, $key, true);
}
Ja sitten toiminto, joka käyttää auttajaa sijainnin hakemiseen :
<?php
/**
* @param int $eventID the ID of the event
* @return string the name of the event of an empty string
*/
public function getLocationName($eventId): string
{
return $this->get($eventId, 'ymc-event-location-name');
}
Mutta näissä kahdessa esimerkissä käytämme edelleen olemassa olevia API-toimintoja. Entä tapaus, jossa meidän on keskusteltava tietokannan kanssa?
3 Yhden viestin URL-osoitteen hakeminen
Tässä tapauksessa kommunikoimme suoraan WordPress-tietokannan kanssa. Jos tunnet $wpdb- objektin ja SQL:n, tämä ei ole iso juttu.
Jos et ole, suosittelen lukemaan valmistelu- ja get_results – funktiosta.
Tämän perusteella voimme kirjoittaa kyselyn, joka tekee seuraavan:
- nappaa kaikki viestit, joissa tunnus vastaa tiettyä arvoa, postauksen tyyppi ja postauksen tila ovat tietty arvo, ja järjestämme tulokset tunnuksen nousevan arvon mukaan,
- Seuraavaksi käytämme kyseisen kyselyn tuloksia saadaksemme yhden arvon.
Ja voimme tehdä tämän sekä käyttämällä tietokantaa että kirjoittamalla sisäkkäisen kyselyn:
<?php
/**
* @return string the URL to the event next to the current event.
*/
public function getNextEventUrl()
{
global $wpdb;
$results = $wpdb->get_results(
$wpdb->prepare(
"
SELECT *
FROM $wpdb->posts
WHERE ID > (SELECT ID
FROM $wpdb->posts
WHERE ID = %d
AND post_type = '%s'
AND post_status = '%s'
ORDER BY ID ASC) AND post_type = '%s'
AND post_status = '%s'
ORDER BY ID ASC
LIMIT 1
",
get_the_ID(),
'ymc-events',
'publish',
'ymc-events',
'publish') );
$result = (isset($result[0]))? $result[0]: '';
return $result;
}
Ja sitten kaikki tämä voidaan kapseloida yhteen luokkaan, joka olisi esimerkiksi Tapahtumavarasto (tai EventRepository ).
Kerron tästä kuitenkin lisää seuraavassa postauksessa. Nimittäin miten määritellään, mitkä funktiot kuuluvat minne, nimeämiskäytännöt ja kuinka käsitellä pysyvyyttä, jos haluat sisällyttää sen myös arkistoon.
Arkisto määritetty
Ennen kaikkea muista tämä:
Arkistomalli peittää tietojen haun, mutta tarjoaa johdonmukaisen tavan siihen, miten siihen liittyvät tiedot voidaan noutaa.
Jotkut saattavat myös lisätä, kuinka se voidaan hakea ja miten se voidaan kirjoittaa, mutta ehkä keskustelen siitä toisessa viestissä.

