Een door WordPress aangedreven frontend bouwen een aangepaste richtlijn voor het plaatsen van vacatures

In het vorige deel van de serie bootden we onze AngularJS-applicatie, geconfigureerde routering voor verschillende weergaven en gebouwde services rond routes voor berichten, gebruikers en categorieën. Met behulp van deze services zijn we nu eindelijk in staat om gegevens van de server op te halen om de voorkant aan te sturen.

In dit deel van de serie zullen we werken aan het bouwen van een aangepaste AngularJS-richtlijn voor de functie voor het aanbieden van posts. In het huidige deel van de serie zullen we:

  • onszelf voorstellen aan AngularJS-richtlijnen en waarom we er een moeten maken
  • plan de richtlijn voor de functie voor het plaatsen van een bericht en de argumenten die daarvoor nodig zijn
  • maak een aangepaste AngularJS-richtlijn voor berichtvermelding samen met zijn sjabloon

Laten we beginnen met onszelf voor te stellen aan de AngularJS-richtlijnen en waarom we ze nodig hebben.

Introductie van AngularJS-richtlijnen

Richtlijnen in AngularJS zijn een manier om het gedrag van HTML-elementen te wijzigen en een herhaalbaar stuk code te hergebruiken. Ze kunnen worden gebruikt om de structuur van een HTML-element en de onderliggende elementen aan te passen, en dus zijn ze een perfecte manier om aangepaste UI-widgets te introduceren.

Tijdens het analyseren van wireframes in het eerste deel van de serie, hebben we opgemerkt dat de functie voor het plaatsen van een bericht in drie weergaven wordt gebruikt, namelijk:

  1. Plaats advertentie
  2. Auteursprofiel
  3. Categorie berichten lijst

Dus in plaats van afzonderlijke functies te schrijven om berichten op al deze drie pagina's weer te geven, kunnen we een aangepaste AngularJS-richtlijn maken die bedrijfslogica bevat om berichten op te halen met behulp van de services die we in het vorige deel van deze serie hebben gemaakt. Afgezien van bedrijfslogica, zal deze richtlijn ook de weergavelogica bevatten om berichten over bepaalde weergaven te vermelden. Het is ook in deze richtlijn dat de functionaliteit voor het pagineren van posts en het ophalen van berichten op bepaalde criteria worden gedefinieerd.

Het creëren van een aangepaste AngularJS-richtlijn voor de functie voor het plaatsen van een post stelt ons in staat om de functionaliteit op slechts één plaats te definiëren, en dit zal het voor ons in de toekomst gemakkelijker maken om deze functionaliteit uit te breiden of aan te passen zonder de code in alle drie gevallen te hoeven wijzigen waar het wordt gebruikt.

Dat gezegd hebbende, laten we beginnen met het coderen van onze aangepaste richtlijn voor de functie voor het aanbieden van berichten.

Planning van de aangepaste AngularJS-richtlijn voor plaatsing na de boeking

Voordat we beginnen met het schrijven van een code voor het bouwen van de richtlijn voor de functie voor het plaatsen van een post, kunnen we de functionaliteit analyseren die nodig is in de richtlijn.

Op het allerbelangrijkste niveau hebben we een richtlijn nodig die we zouden kunnen gebruiken in onze opvattingen voor postlijsten, auteursprofielen en de categoriepagina. Dit betekent dat we een aangepaste UI-widget (of een DOM-marker) zullen maken die we in onze HTML plaatsen, en AngularJS zal voor de rest zorgen, afhankelijk van de opties die we bieden voor die specifieke instantie van de richtlijn.

Daarom zullen we een aangepaste UI-widget maken die wordt geïdentificeerd door de volgende tag:

Maar we hebben deze richtlijn ook nodig om flexibel te zijn, d.w.z. argumenten als input te gebruiken en dienovereenkomstig te handelen. Overweeg de pagina met het gebruikersprofiel waar we alleen berichten van die specifieke gebruiker willen laten weergeven of de categoriepagina waar berichten van die categorie worden weergegeven. Deze argumenten kunnen op de volgende twee manieren worden verstrekt:

  1. In de URL als parameters
  2. Rechtstreeks naar de richtlijn als een attribuutwaarde

Het verstrekken van argumenten in de URL lijkt native voor de API, omdat we al bekend zijn met het doen. Daarom kan een gebruiker een set berichten van een specifieke gebruiker ophalen op de volgende manier:

http://127.0.0.1:8080/#/posts?author=1

De bovenstaande functionaliteit kan worden bereikt door de $ routeParams service aangeboden door AngularJS. Hier kunnen we toegang krijgen tot de parameters die de gebruiker in de URL heeft opgegeven. We hebben er al naar gekeken tijdens het registreren van routes in het vorige deel van de serie.

Wat betreft het direct als argumentatiewaarde aan de richtlijn geven van argumenten, zouden we iets als het volgende kunnen gebruiken:

De post-args attribuut in het bovenstaande fragment neemt argumenten voor het ophalen van een specifieke reeks berichten, en momenteel neemt het de auteurs-ID. Dit kenmerk kan elk aantal argumenten gebruiken voor het ophalen van berichten, zoals ondersteund door de / Wp / v2 / berichten route. Als we dus een reeks berichten ophalen die zijn geschreven door een gebruiker met een ID van 1 en die tot een categorie ID 10 behoort, kunnen we iets als het volgende doen:

De filter [cat] parameter in de bovenstaande code wordt gebruikt om een ​​reeks berichten op te halen die tot een bepaalde categorie behoren.

Paginering is ook een essentieel kenmerk bij het werken met pagina's met postlijsten. De richtlijn behandelt de paginering van de post en deze functie wordt bepaald door de waarden van de X-WP-Total en X-WP-TotalPages headers zoals geretourneerd door de server samen met het antwoordorgaan. Daarom kan de gebruiker heen en weer navigeren tussen de vorige en volgende reeks berichten.

Nadat we besloten hebben wat de standaardrichtlijn voor plaatsing op de lijst is, hebben we nu een tamelijk solide basis om de code te gaan schrijven.

Bouwen aan een aangepaste richtlijn voor plaatsing op een post

Het bouwen van een richtlijn voor de functie voor het plaatsen van een post omvat twee stappen:

  1. Maak de bedrijfslogica om berichten op te halen en andere dingen te verwerken.
  2. Maak een weergave voor weergave van deze berichten die op de pagina wordt weergegeven.

De bedrijfslogica voor onze aangepaste richtlijn zal worden behandeld in de richtlijnverklaring. En voor het weergeven van gegevens op de DOM, maken we een aangepaste sjabloon voor het posten van berichten. Laten we beginnen met de richtlijnverklaring.

Richtlijn Verklaring

Richtlijnen in AngularJS kunnen worden gedeclareerd voor een module met de volgende syntaxis:

/ ** * Een aangepaste instructie maken voor berichten in de lijst * / quiescentApp.directive ('postListing', [function () return ;]);

Hier verklaren we een richtlijn op onze module met behulp van de .richtlijn() methode die beschikbaar is in de module. De methode neemt de naam van de richtlijn als het eerste argument, en deze naam is nauw verbonden met de naam van de tag van het element. Omdat we willen dat ons HTML-element dat is , we bieden een camel-case-weergave van de tagnaam. U kunt meer leren over dit normalisatieproces dat door AngularJS wordt uitgevoerd om richtlijnnamen in de officiële documentatie te matchen.

De notatie die we in de bovenstaande code gebruiken voor het declareren van onze richtlijn veilige injectie van afhankelijkheid. En in deze notatie bieden we een scala aan afhankelijkheden als het tweede argument dat de richtlijn nodig heeft. Momenteel hebben we geen afhankelijkheden gedefinieerd voor onze aangepaste richtlijn. Maar omdat we de berichten service voor het ophalen van berichten (die we in het vorige deel van de serie hebben gemaakt) en de eigen AngularJS's $ routeParams en $ locatie services voor toegang tot URL-parameters en het huidige pad, definiëren we ze als volgt:

/ ** * Een aangepaste instructie maken voor berichten in de lijst * / quiescentApp.directive ('postListing', ['$ routeParams', '$ location', 'Posts', function ($ routeParams, $ location, Posts) return beperken : 'E', scope: postArgs: '=', link: function ($ scope, $ elem, $ attr) ;]);

Deze afhankelijkheden worden dan beschikbaar gemaakt voor de functie die is gedefinieerd als het laatste element van de array. Deze functie retourneert een object met een richtlijndefinitie. Momenteel hebben we twee eigenschappen in het richtlijndefinitieobject, d.w.z.. beperken en link.

De beperken optie definieert de manier waarop we de richtlijn gebruiken in onze code, en er kunnen vier mogelijke waarden aan deze optie zijn:

  1. EEN: Voor gebruik van de richtlijn als attribuut op een bestaand HTML-element.
  2. E: Voor het gebruik van de richtlijn als elementnaam.
  3. C: Voor het gebruik van de richtlijn als klassennaam.
  4. M: Voor gebruik van de richtlijn als een HTML-opmerking.

De beperken optie kan ook elke combinatie van de bovenstaande vier waarden accepteren.

Omdat we willen dat onze richtlijn een nieuw element is , we hebben de beperkingsoptie ingesteld op E. Als we de richtlijn zouden definiëren met behulp van de attributen op een reeds bestaand HTML-element, dan hadden we deze optie kunnen instellen EEN. In dat geval zouden we kunnen gebruiken

om de richtlijn in onze HTML-code te definiëren.

De seconde strekking eigendom wordt gebruikt om de reikwijdte van de richtlijn te wijzigen. Standaard is de waarde van de strekking eigendom is vals, wat betekent dat de reikwijdte van de richtlijn dezelfde is als die van de ouder. Wanneer we een object doorgeven, wordt er een afzonderlijk bereik gemaakt voor de richtlijn en worden alle gegevens die door de bovenliggende organisatie aan de richtlijn moeten worden doorgegeven, door HTML-kenmerken geleid. Dit is wat we doen in onze code, en het kenmerk dat we gebruiken is post-args, waarin wordt genormaliseerd postArgs.

De postArgs eigendom in de strekking object kan een van de volgende drie waarden accepteren:

  1. =: Dit betekent dat de waarde die wordt doorgegeven aan het kenmerk, als een object wordt behandeld.
  2. @: Dit betekent dat de waarde die aan het kenmerk wordt doorgegeven, als een gewone tekenreeks wordt behandeld.
  3. &: Dit betekent dat de waarde die wordt doorgegeven aan het kenmerk, als een functie wordt behandeld.

Omdat we ervoor hebben gekozen om de = waarde, elke waarde die wordt doorgegeven aan de post-args attribuut zou worden behandeld als een JSON-object en we zouden dat object kunnen gebruiken als argument voor het ophalen van berichten.

De derde eigenschap, link, wordt gebruikt om een ​​functie te definiëren die wordt gebruikt om de DOM te manipuleren en om API's en functies te definiëren die nodig zijn voor de richtlijn. Met deze functie wordt alle logica van de richtlijn behandeld.

De link functie accepteert argumenten voor het bereikobject, het HTML-element van de richtlijn en een object voor kenmerken die zijn gedefinieerd op het HTML-element van de richtlijn. Momenteel geven we twee argumenten door $ scope en $ elem voor respectievelijk het scope-object en het HTML-element.

Laten we een variabele definiëren op de $ scope property die we zullen gebruiken om de functie voor het plaatsen van een post op de DOM weer te geven.

/ ** * Een aangepaste instructie maken voor berichten in de lijst * / quiescentApp.directive ('postListing', ['$ routeParams', '$ location', 'Posts', function ($ routeParams, $ location, Posts) return beperken : 'E', scope: postArgs: '=', link: function ($ scope, $ elem, $ attr) // variabelen definiëren voor het $ scope-object $ scope.posts = []; $ scope.postHeaders = ; $ scope.currentPage = $ routeParams.page? Math.abs ($ routeParams.page): 1; $ scope.nextPage = null; $ scope.previousPage = null; $ scope.routeContext = $ location.path ( );;]);

Daarom hebben we zes eigenschappen gedefinieerd op de $ scope object dat we konden openen in de DOM. Deze eigenschappen zijn:

  1. $ posts: Een array voor postobjecten die door de server worden geretourneerd.
  2. $ postHeaders: Een object voor het bevatten van de headers die door de server worden geretourneerd, samen met de responsbody. We zullen deze gebruiken voor het afhandelen van navigatie.
  3. $ HuidigePagina: Een geheel getal variabele met het huidige paginanummer.
  4. $ vorigePagina: Een variabele met het vorige paginanummer.
  5. $ NEXTPAGE: Een variabele met het volgende paginanummer.
  6. $ routeContext: Voor toegang tot het huidige pad met behulp van de $ locatie service.

De postArgs eigenschappen die we eerder hebben gedefinieerd voor HTML-kenmerken, zijn al beschikbaar op de $ scope object binnen de richtlijn.

Nu zijn we klaar om een ​​verzoek in te dienen bij de server met behulp van de berichten dienst voor het ophalen van berichten. Maar daarvoor moeten we rekening houden met de argumenten van de gebruiker als URL-parameters en met de parameters in de post-args attribuut. En voor dat doel zullen we een functie creëren die de $ routeParams service om URL-parameters te extraheren en samen te voegen met de argumenten die worden verstrekt via de post-args attribuut:

/ ** * Een aangepaste instructie maken voor berichten in de lijst * / quiescentApp.directive ('postListing', ['$ routeParams', '$ location', 'Posts', function ($ routeParams, $ location, Posts) return beperken : 'E', scope: postArgs: '=', link: function ($ scope, $ elem, $ attr) // variabelen definiëren voor het $ scope-object $ scope.posts = []; $ scope.postHeaders = ; $ scope.currentPage = $ routeParams.page? Math.abs ($ routeParams.page): 1; $ scope.nextPage = null; $ scope.previousPage = null; $ scope.routeContext = $ location.path ( ); // voorbereiden van queryargumenten var prepareQueryArgs = function () var tempParams = $ routeParams; delete tempParams.id; return angular.merge (, $ scope.postArgs, tempParams);;;]);

De prepareQueryArgs () methode in de bovenstaande code gebruikt de angular.merge () methode, die het $ scope.postArgs object met de $ routeParams voorwerp. Maar voordat deze twee objecten worden samengevoegd, worden eerst de ID kaart eigendom van de $ routeParams object met behulp van de verwijderen operator. Dit is nodig omdat we deze richtlijn zullen gebruiken voor categorieën en gebruikersweergaven en we willen niet dat de categorie en gebruikers-ID's verkeerd worden geïnterpreteerd als de post-ID.

Nadat we queryargumenten hebben voorbereid, zijn we eindelijk klaar om een ​​oproep te doen naar de server en berichten op te halen, en we doen dit met de Posts.query () methode, die twee argumenten vereist:

  1. Een object met argumenten voor het maken van de query.
  2. Een callback-functie die wordt uitgevoerd nadat de query is voltooid.

Dus we zullen de prepareQueryArgs () functie voor het voorbereiden van een object voor queryargumenten, en in de callback-functie stellen we de waarden van bepaalde variabelen in op de $ scope eigendom:

// maak de aanvraag en vraag posten Posts.query (prepareQueryArgs (), functie (data, headers) $ scope.posts = data; $ scope.postHeaders = headers (); $ scope.previousPage = (($ scope.currentPage + 1)> $ scope.postHeaders ['x-wp-totalpages'])? Null: ($ scope.currentPage + 1); $ scope.nextPage = (($ scope.currentPage - 1)> 0)? ($ scope.currentPage - 1): null;);

De callback-functie krijgt twee argumenten doorgegeven voor de antwoordtekst en de antwoordheaders. Deze worden vertegenwoordigd door de gegevens en headers argumenten respectievelijk.

De headers argument is een functie die een object retourneert met antwoordheaders door de server.

De resterende code spreekt voor zich omdat we de waarde van de $ scope.posts matrix. Voor het instellen van de waarden van de $ scope.previousPage en $ scope.nextPage variabelen, we gebruiken de x-wp-totalpages eigendom in de postHeaders voorwerp.

En nu zijn we klaar om deze gegevens aan de voorkant te tonen met behulp van een aangepaste sjabloon voor onze richtlijn.

Een aangepast sjabloon maken voor de richtlijn

Het laatste wat we moeten doen om onze richtlijn te laten werken, is door een afzonderlijke sjabloon voor de plaatsing op de lijst te maken en deze aan de richtlijn te koppelen. Daartoe moeten we de richtlijnverklaring aanpassen en een templateUrl eigendom zoals de volgende:

/ ** * Een aangepaste instructie maken voor berichten in de lijst * / quiescentApp.directive ('postListing', ['$ routeParams', '$ location', 'Posts', function ($ routeParams, $ location, Posts) return beperken : 'E', scope: postArgs: '=', templateUrl: 'views / directive-post-listing.html', link: function ($ scope, $ elem, $ attr) ;]);

Deze templateUrl eigenschap in de bovenstaande code verwijst naar een bestand met de naam richtlijn-post-listing.html in de keer bekeken directory. Dus maak dit bestand in de keer bekeken map en plak in de volgende HTML-code:

 

Een goed ontwerp lijkt veel op helder denken dat visueel is gemaakt.

Uitgelichte afbeelding

Door Bilal Shahid in Quotes

Dagen gemaakt. Heerschappij. Onderwerping zeer hath geest ons zesde vis kruipt ook. Eerst een vlees erboven uit. Je zult vullen voor. Kan 's avonds niet één licht niet. Geweldig om firmament te maken. Leven zijn begin gezegende mindere vleesgeest gezegende zeeën gecreëerd groen groot begin kan niet nietig maken beweging. Onderwerping avond maak geest minder groter alle levende groene uitspansel gevleugelde zaag boom één kloof waarin verdeeld zal drogen mindere zaag, aarde de. Verlicht hun de.

Oudere berichten Nieuwere berichten

Dit is een eenvoudige HTML-code die een enkel bericht en post-paginering vertegenwoordigt. Ik heb het gekopieerd van de views / listing.html het dossier. We zullen enkele AngularJS-richtlijnen gebruiken, inclusief ng-repeat, ng-href, ng-src, en ng-bind-html, om de gegevens weer te geven die zich momenteel in de $ scope eigendom van de richtlijn.

Pas de HTML-code aan het volgende aan:

 

Post.title.rendered

Uitgelichte afbeelding

Door post.quiescent_author_name in category.name $ last? ": ','

De bovenstaande code gebruikt de ng-repeat richtlijn om via de $ scope.posts matrix. Elke eigenschap die is gedefinieerd op de $ scope object in de richtlijnverklaring is direct in de sjabloon beschikbaar. Daarom verwijzen we naar de $ scope.posts array direct als posts in de sjabloon.

Door de ng-repeat richtlijn, wij zorgen ervoor dat de article.post-entry container wordt herhaald voor elke post in de posts array en naar elk bericht wordt verwezen als post in de binnenste lus. Deze post object bevat gegevens in de JSON-indeling die door de server worden geretourneerd, en bevat eigenschappen zoals de titel van het bericht, het bericht-ID, de inhoud van het bericht en de koppeling met de afbeelding, een extra veld dat door de begeleidende plug-in is toegevoegd.

In de volgende stap vervangen we waarden zoals de berichttitel, de postlink en de gekenmerkte afbeeldingslink met eigenschappen in de post voorwerp.

Voor de paginering, vervangt u de vorige code door het volgende:

 
Nieuwere berichten Oudere berichten

We hebben eerst toegang tot de routeContext eigendom, dat we in onze richtlijnverklaring hebben gedefinieerd, en achtervoegsel met de ?page = parameter en gebruik de waarden van de volgende pagina en vorige pagina variabelen om heen en weer te navigeren tussen berichten. We controleren ook of de volgende pagina of de koppeling van de vorige pagina dat niet is nul, anders voegen we een toe .invalide klasse op de knop die wordt aangeboden door Zurb Foundation.

Nu we de richtlijn hebben voltooid, is het tijd om het te testen. En we doen het door een tag in onze HTML, idealiter direct boven de

label. Als u dit doet, wordt een berichtvermelding weergegeven boven het voettekstblad. Maak je geen zorgen over de opmaak en stijlen zoals we ze in het volgende deel van de serie zullen behandelen.

Dus dat is eigenlijk het voor het maken van een aangepaste AngularJS-richtlijn voor de functie voor het plaatsen van een post.

What's Up Next?

In het huidige deel van de serie over het maken van een frontend met de WP REST API en AngularJS, hebben we een aangepaste AngularJS-richtlijn voor de functie postvermelding gemaakt. Deze richtlijn gebruikt de berichten service die we in het eerdere deel van de serie hebben gecreëerd. De richtlijn neemt ook gebruikersinvoer in de vorm van een HTML-kenmerk en via URL-parameters.

In het afsluitende deel van de serie gaan we aan het laatste deel van ons project werken, namelijk controllers voor berichten, gebruikers en categorieën en hun respectieve sjablonen.