Verbeterde Ajax-technieken voor WordPress Object-Oriented Programming

In de vorige post in deze serie hebben we het onderwerp 'Werken met Ajax' in WordPress opnieuw bekeken. Uiteindelijk is het doel om een eerdere serie die een paar jaar geleden op de site werd uitgevoerd, te verbeteren.

Om nogmaals te herhalen, het is niet zo dat de technieken die in de originele serie werden geleerd verkeerd waren, maar het is dat de software in de loop van de tijd verandert, dus het is altijd goed om concepten die jaren geleden zijn behandeld opnieuw te bekijken en te updaten naar iets dat wat actueler en veerkrachtiger is voor onze ontwikkelingsinspanningen.

Herinner uit de vorige post, we keken naar de volgende opmerking uit de originele serie:

We gaan een heel kort overzicht geven van wat Ajax is, hoe het werkt, hoe je het op de voorkant instelt en de haken begrijpt die WordPress biedt. We zullen ook daadwerkelijk een klein project bouwen dat de theorie in de praktijk brengt. We lopen de broncode door en we zorgen er ook voor dat deze beschikbaar is op GitHub.

En in die post hebben we enkele geavanceerde manieren besproken om de WordPress Ajax API in onze projecten op te nemen met behulp van procedurele programmering. In dit bericht gaan we de code gebruiken die we in het eerste deel van deze serie hebben geschreven en deze zodanig refactiveren dat deze een objectgerichte benadering gebruikt.

Uiteindelijk is het doel niet om een reden te verzinnen waarom het ene paradigma boven het andere moet worden gebruikt; in plaats daarvan laten we zien hoe we dezelfde functionaliteit kunnen bereiken, ongeacht de aanpak die u kiest bij het bouwen van uw plug-ins.

De plug-in plannen

Voordat we beginnen met het herformuleren van de code, is er iets dat we moeten overwegen hoe we gaan de verschillende bestanden lay-out. Immers, een deel van het proces om een nieuw project te beginnen - of zelfs in een oud project te springen - is van plan hoe het werk zal worden gedaan.

Voor deze specifieke plug-in hebben we het volgende nodig:

een bootstrap-bestand dat verantwoordelijk is voor het initialiseren van de hoofdklasse en het starten van de plug-in
een klasse die verantwoordelijk is voor het laden van de afhankelijkheden, zoals JavaScript
een klasse die als de belangrijkste plugin-klasse fungeert

Zoals je kunt zien, is dat niet het geval te veel dat we moeten doen met de plug-in. We zullen ook enkele bestanden herorganiseren om een consistente directorystructuur te hebben, en we zullen ervoor zorgen dat we alle code correct documenteren zodat deze voldoet aan de WordPress coderingsstandaarden.

Met dat gezegd, laten we aan de slag gaan.

De bestanden ordenen

Voordat we beginnen met het schrijven van een code, laten we doorgaan en het volgende doen:

Creëer een middelen directory.
Maak een js map die zich in de middelen directory.
verhuizing frontend.js naar de js directory.

De reden om dit te doen is dat we een object-georiënteerde programmeerstijl ingaan. Onderdeel hiervan is het organiseren van onze bestanden zodat ze conventies volgen die vaak als pakketten worden beschouwd.

In ons geval is de middelen map bevat alle dingen die nodig zijn om het programma te laten werken. Voor sommige plug-ins kan dit JavaScript, CSS, afbeeldingen, lettertypen, enzovoort zijn. In dit geval hebben we een enkel JavaScript-bestand.

De afhankelijkheidslader

Vervolgens moeten we een klasse introduceren die verantwoordelijk is voor het laden van de afhankelijkheden voor ons project. Voor deze specifieke plug-in is de enige afhankelijkheid die we hebben het JavaScript-bestand dat we zojuist in de hebben geplaatst middelen directory.

Een onderdeel van objectgeoriënteerd programmeren is ervoor te zorgen dat elke klasse een specifiek doel heeft. In dit geval is de klasse die we introduceren verantwoordelijk voor het laden van JavaScript met behulp van de WordPress API.

Laten we beginnen met het creëren van de basisstructuur van de klasse:

Vervolgens voegen we een methode toe die verantwoordelijk is voor het in de wachtrij plaatsen van het JavaScript volgens de WordPress API.
enqueue_scripts ();  / ** * Hiermee haalt u de front-end-scripts op voor het verkrijgen van de informatie van de huidige gebruiker * via Ajax. * * @access private * * @since 1.0.0 * / private function enqueue_scripts () wp_enqueue_script ('ajax-script', plugin_dir_url (dirname (__FILE__)). 'assets / js / frontend.js', array ('jQuery ')); wp_localize_script ('ajax-script', 'sa_demo', array ('ajax_url' => admin_url ('admin-ajax.php')));  
Daarna moeten we de functies nemen die verantwoordelijk zijn voor het afhandelen van de Ajax-verzoeken en antwoorden geven en deze dan aan de klas toevoegen. Omdat ze binnen de context van een klasse vallen, moeten we een nieuwe functie toevoegen die ze bij WordPress registreert.
We zullen een maken setup_ajax_handlers functie. Het ziet er zo uit:
Vervolgens moeten we de functies daadwerkelijk in deze klasse verplaatsen. Merk op dat de functies oorspronkelijk waren voorafgegaan door _sa zijn niet langer als zodanig gemarkeerd. Omdat ze in de context van de klasse zijn, kunnen we het voorvoegsel laten vallen en ook het onderstrepingsteken laten vallen ten gunste van de privaat trefwoord.
user_is_logged_in ($ user_id) && $ this-> user_exists ($ user_id)) wp_send_json_success (wp_json_encode (get_user_by ('id', $ user_id)));  persoonlijke functie user_is_logged_in ($ user_id) $ is_logged_in = true; if (0 === $ user_id) wp_send_json_error (new WP_Error ('-2', 'De bezoeker is momenteel niet ingelogd op de site.')); $ is_logged_in = false;  return $ is_logged_in;  private function user_exists ($ user_id) $ user_exists = true; if (false === get_user_by ('id', $ user_id)) wp_send_json_error (new WP_Error ('-1', 'Er is geen gebruiker gevonden met de opgegeven ID ['. $ user_id. ']')); $ user_exists = false;  return $ user_exists; 
Dan bewaren we dit bestand in een omvat map in de hoofdmap van de plugin-map. De omvat directory is vaak de locatie waar de code die in een project wordt gebruikt, zich bevindt. Er kan meer over deze specifieke directory worden gezegd, maar dat is inhoud voor een langere post.
De definitieve versie van deze klasse zou er als volgt uit moeten zien:
enqueue_scripts ();  / ** * Hiermee haalt u de front-end-scripts op voor het verkrijgen van de informatie van de huidige gebruiker * via Ajax. * * @access private * * @since 1.0.0 * / private function enqueue_scripts () wp_enqueue_script ('ajax-script', plugin_dir_url (dirname (__FILE__)). 'assets / js / frontend.js', array ('jQuery ')); wp_localize_script ('ajax-script', 'sa_demo', array ('ajax_url' => admin_url ('admin-ajax.php')));  / ** * Registreert de callback-functies die verantwoordelijk zijn voor het leveren van een reactie * op Ajax-verzoeken die tijdens de rest van de plug-in zijn ingesteld. * * @since 1.0.0 * / public function setup_ajax_handlers () add_action ('wp_ajax_get_current_user_info', array ($ this, 'get_current_user_info')); add_action ('wp_ajax_nopriv_get_current_user_info', array ($ this, 'get_current_user_info'));  / ** * Haalt informatie op over de gebruiker die op de site is ingelogd. * * Deze functie is bedoeld om te worden aangeroepen via de client-kant van de openbare * kant van de site. * * @since 1.0.0 * / public function get_current_user_info () $ user_id = get_current_user_id (); if ($ this-> user_is_logged_in ($ user_id) && $ this-> user_exists ($ user_id)) wp_send_json_success (wp_json_encode (get_user_by ('id', $ user_id)));  / ** * Bepaalt of een gebruiker met de opgegeven gebruikers-ID op de site is aangemeld. Als dat niet het geval is, * worden de volgende foutcode en bericht teruggestuurd naar de client: * * -2: de bezoeker is momenteel niet aangemeld bij de site. * * @access private * @since 1.0.0 * * @param int $ user_id De ID van de huidige gebruiker. * * @return bool $ is_logged_in Ongeacht of de huidige gebruiker is aangemeld. * / persoonlijke functie user_is_logged_in ($ user_id) $ is_logged_in = true; if (0 === $ user_id) wp_send_json_error (new WP_Error ('-2', 'De bezoeker is momenteel niet ingelogd op de site.')); $ is_logged_in = false;  return $ is_logged_in;  / ** * Bepaalt of een gebruiker met de opgegeven ID bestaat in de WordPress-database. Als dat niet het geval is, worden * de volgende foutcode en bericht teruggestuurd naar de client: * * -1: er is geen gebruiker gevonden met de opgegeven ID [$ user_id]. * * @access private * @since 1.0.0 * * @param int $ user_id De ID van de huidige gebruiker. * * @return bool $ user_exists Of de opgegeven gebruiker al dan niet bestaat. * / private function user_exists ($ user_id) $ user_exists = true; if (false === get_user_by ('id', $ user_id)) wp_send_json_error (new WP_Error ('-1', 'Er is geen gebruiker gevonden met de opgegeven ID ['. $ user_id. ']')); $ user_exists = false;  return $ user_exists;  
De hoofdklasse
Nu zijn we klaar om de hoofdklasse voor de plug-in te schrijven. Deze specifieke klasse bevindt zich in de hoofdmap van de plugin-directory en de basisstructuur van de klasse ziet er als volgt uit:
Vervolgens voegen we een aantal eigenschappen toe die we zullen instellen wanneer de klasse wordt geïnstantieerd:
Daarna maken we een constructor en een initialisatiefunctie die wordt gebruikt om de plug-in in te stellen:
versie = '1.0.0'; $ this-> loader = nieuwe Dependency_Loader ();  / ** * Initialiseert deze plug-in en de afhankelijkheidslader om * het JavaScript te bevatten dat nodig is om de plug-in te laten functioneren. * * @access private * @since 1.0.0 * / public function initialize () $ this-> loader-> initialize (); $ This-> loader-> setup_ajax_handlers ();  
In de bovenstaande code stelt de constructor de eigenschappen in en stelt de afhankelijkheden in die nodig zijn om de plug-in in te stellen.
Wanneer initialiseren wordt aangeroepen, start de plug-in en wordt de initialisatiemethode aangeroepen op de afhankelijkheidsklasse die we eerder in deze zelfstudie hebben gemaakt.
De Bootstrap
Het laatste dat we moeten doen is het belangrijkste bestand dat we hebben gebruiken, PHP's gebruiken omvatten functionaliteit, en zorg ervoor dat het zich bewust is van de noodzakelijke PHP-bestanden die we hebben.
Daarna moeten we een methode definiëren die het hoofdinvoegbestand initialiseert en alles in gang zet.
initialiseren (); 
De definitieve versie van het bootstrap-bestand zou er als volgt uit moeten zien:
initialiseren ();  acme_start_plugin (); 
Eerst controleert het bestand of het rechtstreeks wordt benaderd door te controleren of een WordPress-constante is gedefinieerd. Zo niet, dan stopt de uitvoering. 
Hierna bevat het de verschillende klassen die we via deze tutorial hebben gemaakt. Uiteindelijk definieert het een functie die wordt aangeroepen wanneer WordPress de plug-in laadt die de plug-in start en alles in beweging zet.
Conclusie
En dat brengt ons bij het einde van deze tweedelige serie. Hopelijk heb je niet alleen enkele van de best practices voor het integreren van Ajax in je WordPress-projecten geleerd, maar ook een beetje over het documenteren van zowel procedurele als object-georiënteerde code en ook het verschil in hoeveel van de code is aangelegd..
In een volgend bericht kan ik enkele van de objectgeoriënteerde concepten die hier zijn geïntroduceerd opnieuw bekijken en ze in veel meer detail behandelen. Bekijk voorlopig de plug-in met de GitHub-link in de zijbalk van deze pagina.
Vergeet niet dat je al mijn cursussen en tutorials op mijn profielpagina kunt vinden en je kunt me volgen op mijn blog en / of Twitter op @tommcfarlin, waar ik het heb over softwareontwikkeling in de context van WordPress.
Zoals gebruikelijk, aarzel dan niet om vragen of opmerkingen achter te laten in de feed hieronder, en ik zal ernaar streven om op elk van hen te reageren. 



		
			
	   
	




Code