In het eerste deel van het artikel werd uitgelegd hoe een webpagina aan de clientzijde werkt.
Laten we nu eens kijken wat er aan de serverkant gebeurt.

Deel II

Serverkant: formulieren en databases

1. Formulieren

Tot nu toe hebben we het alleen gehad over het herstellen van gegevens van de server. Hoe zit het met het verzenden van gegevens? Formulieren zijn de andere kant van HTML: ze stellen ons in staat informatie naar de server te sturen. We kunnen de formulieren gebruiken om bestaande informatie bij te werken of om nieuwe informatie toe te voegen.
De meest gebruikte methoden in HTML-formulieren zijn: Begin et POST.

Kijk eens naar de code hierboven :
We hebben twee invoervelden (invoer) waar de gebruiker gegevens kan invoeren en een verzendknop (voorleggen).
Nadat de gebruiker op deze knop heeft geklikt, stuurt de browser de gegevenswaarden die in de twee velden zijn ingevoerd naar een PHP-script genaamd maakproduct.php.
In ons voorbeeld is het PHP, maar het kan JSP, Python of een andere server-side scripttaal zijn. Het server-side script kan de waarden lezen die door de browser zijn verzonden via de methode POST, verwerk ze of sla ze op in een bestand of database. In een notendop, het is hoe gegevens naar de server worden verzonden voordat ze worden opgeslagen.

Wat is PHP?

PHP voor Hypertext Preprocessor, is een server-side scripttaal voor het maken van dynamische websites en applicaties. Met andere woorden: het is een taal die het mogelijk maakt om toegang te krijgen tot een database, deze te lezen en vervolgens de informatie ervan in een HTML-pagina te transcriberen.
Notitie : Stel dat we validaties willen toevoegen voordat de gegevens worden verzonden. De productnaam moet bijvoorbeeld minimaal 5 tekens bevatten of het veld 'SKU' mag niet leeg zijn. We kunnen JavaScript gebruiken voor deze validaties. We zullen dan moeten reageren op de klikgebeurtenis van de verzendknop en controleren of de webelementen de gewenste gegevens hebben. Als er iets ontbreekt, kunnen we een foutmelding weergeven en stoppen met het verzenden van gegevens naar de server.

2. Databases

Zodra de hoeveelheid informatie begint te groeien, kan het ophalen uit bestanden erg ingewikkeld en ook erg traag worden. Laten we bijvoorbeeld het prijslijstbestand nemen, stel dat het bedrijf duizenden producten heeft en we willen de informatie weten van het laatste product in de lijst - wat betekent dat we alle producten moeten lezen tot wat we vinden dat we zijn zoeken naar. Dit is geen optimale manier om informatie op te halen. Om dit probleem op te lossen zijn de databases gemaakt.
In een database (DB) slaan we gegevens op in tabellen (een gestructureerde set gegevens). We kunnen dus eenvoudig een zoekopdracht uitvoeren, gegevens sorteren of andere bewerkingen uitvoeren.

3. Server-side scripttalen & frameworks

We hebben server-side scripttalen nodig om :

informatie uit een database of bestand opslaan en lezen;
krijgen (Begin) informatie van een server door bepaalde bewerkingen uit te voeren;
lees de informatie die door de klant is verzonden (POST) en deze op te slaan of te verspreiden door bepaalde verwerkingen uit te voeren.

Typische programmeertalen zoals C en Java kunnen databases lezen en schrijven, maar ze kunnen niet rechtstreeks op de webbrowser (client) worden uitgevoerd. Dit gaf aanleiding tot server-side scripttalen.
Server-side scripttalen kunnen alle gebruikelijke gegevensverwerking uitvoeren, communiceren met databases en draaien op een webserver. De meest voorkomende server-side scripttalen zijn PHP, Perl, JSP, Ruby on Rails, etc.
Ontwikkelaars begonnen deze talen te gebruiken en realiseerden zich al snel dat ze voor alle projecten dezelfde standaardcode schreven, wat leidde tot de ontwikkeling van frameworks die de ontwikkeling van webapplicaties vergemakkelijken en versnellen.
Enkele bekende frameworks :

PHP: Zend, YII, Symfony, CakePHP, Laravel;
CMS PHP (ook gebruikt als framework): Drupal, Joomla, SugarCRM, WordPress;
Java : J2EE, Slaapstand, Stutten, Veer;
JavaScript : Node.js.

4. MVC-architectuur & sessies

De MVC-architectuur helpt ons om de code in verschillende bestanden te verdelen en stelt ons in staat om de bedrijfslogica van de presentatie te scheiden, zodat we ze later kunnen aanpassen.
Als we het voorbeeld van een blogplatform nemen, komen we terug op alle eerder uitgelegde onderwerpen om te zien hoe we kunnen coderen met behulp van de MVC-architectuur.
Een blogplatform beheert dynamische inhoud en kan verschillende modules bevatten, zoals: :

gebruikers (gebruikers);
Artikelen (blogberichten);
Trefwoorden / tags (labels);
Categorieën (categorieën).

Laten we, voordat we het over andere functies hebben, eens kijken naar het databaseontwerp voor de tabel van Artikelen (tbl_blog_post). Belangrijke velden zijn: :

Zoals u kunt zien, slaan we dubbele gebruikersinformatie op: voornaam (Vul hier uw voornaam in) en achternaam (Vul hier uw achternaam in) herhaal de inhoud van het veld Gemaakt door. Als we 10 blogberichten hebben, slaan we deze dubbele gebruikersinformatie op in elk van de 000 berichten. En er kan andere informatie over de gebruiker zijn om op te slaan, zoals hun rol, hun laatste inlogdatum, enz.
Het alternatief, zoals je misschien al geraden had, is om deze gebruikersinformatie op te slaan in een andere tabel Gebruiker (tbl_gebruiker) en koppel deze aan die van de artikelen (tbl_blog_post) door een id zoals hieronder :

Deze scheiding van gegevens in meerdere tabellen is een van de vele principes van: gegevens normalisatie.
Het volgende belangrijke onderdeel is om de gebruiker in staat te stellen gegevens in deze tabellen in te voegen via een HTML-formulier. Onthoud dat we deze stappen gedetailleerd beschrijven om de concepten te begrijpen - dit is geenszins een volledige programmeerhandleiding.

Een nieuwe blogpost maken door een geverifieerde gebruiker

Hiervoor hebben we een HTML-formulier nodig met twee invoervelden (Titel, inhoud) waarmee de gebruiker een artikel kan maken.
Zodra de gebruiker de informatie invoert en op de verzendknop klikt, "Artikel maken", worden de formulierwaarden via de methode naar de webserver verzonden POST. De ingestuurde waarden POST kan worden gelezen door elke server-side scripttaal. Het serverscript (PHP, Ruby on Rails, Python, etc.) leest de waarde uit het formulier en geeft deze door aan de database.
Het script kan ook informatie verwerken, dit kan zijn om de datum en tijd van de server op te halen of om bepaalde berekeningen te doen op basis van waarden die zijn geëxtraheerd uit een andere tabel in de database of uit een andere webservice.
Een ander punt om op te merken: het script kan ook validaties uitvoeren, ook wel server-side validaties genoemd, om ervoor te zorgen dat de gegevens geldig zijn. Alleen als de gegevens geldig zijn, worden ze in de tabel opgeslagen tbl_blog_post. Anders wordt er een foutmelding naar de klant gestuurd om de ontbrekende informatie in te voeren.
Visueel het formulier om gegevens uit onze tabel op te halen tbl_blog_post lijkt misschien op de interface voor het maken van WordPress-berichten :

Er is een veld om de titel in te voeren (Onderwerp), dan een invoervak voor de inhoud (Beschrijving).
De aanmaakdatum (Gemaakt op), van zijn kant, wordt dynamisch opgehaald door de scripttaal (hier, PHP) en komt overeen met het exacte moment van creatie van het artikel (jaar, maand, dag, uur, minuut en zelfs seconde).
Overige gegevens die niet ingevuld hoeven te worden: de identifier van het artikel (ID). Het wordt automatisch gegenereerd door de database die ervoor zorgt dat het uniek is binnen dezelfde tabel.
In onze tafel tbl_blog_post, naast titel en inhoud hebben we ook een veld genaamd gemaakt door.
Hoe krijgen we de waarde om dit veld te vullen?

Verbonden / geverifieerde gebruiker

Over het algemeen hebben de meeste webapplicaties inlogfunctionaliteit. Elke keer dat een gebruiker zich met succes authenticeert, wordt de informatie van die gebruiker in sessies opgeslagen, zodat de informatie later opnieuw kan worden gebruikt.

Wat is een sessie?

HTTP is een staatloos protocol, wat betekent dat er geen verzoek is Begin ou POST verzonden door de client naar de webserver wordt niet gevolgd. Als de client (de browser) twee verzoeken doet, weet de webserver niet of ze van dezelfde gebruiker komen. Dit betekent ook dat als u bijvoorbeeld bent verbonden met een e-commercesite en u producten aan uw winkelmandje toevoegt, de server niet weet dat deze voor dezelfde gebruiker zijn.
Om dit gebrek aan status te verhelpen, moeten klanten aanvullende informatie in elk van hun verzoeken verzenden om sessie-informatie te bewaren voor de duur van meerdere verzoeken. Deze aanvullende informatie wordt aan de clientzijde opgeslagen in cookies en aan de serverzijde in sessies.
Een sessie is een array van variabelen waarin informatie wordt opgeslagen om op meerdere pagina's te kunnen worden gebruikt. Sessies worden geïdentificeerd door een unieke ID waarvan de naam afhangt van de taal - in PHP heet het "PHP Sessie-ID”. Deze zelfde sessie-ID moet in een cookie in de browser worden opgeslagen om aan de gebruiker te worden gekoppeld.

Eén item weergeven

De volgende stap is om de blogberichten afzonderlijk weer te geven. We moeten de gegevens uit de database lezen op basis van de post-ID (ID) van het gevraagde artikel en geef vervolgens de waarden van de titelvelden weer (Onderwerp) en Inhoud (Beschrijving).
Hier is de pseudocode om een enkele post weer te geven :

Lees de databasegegevens die zijn gekoppeld aan de item-ID.
Voeg deze gegevens in een HTML-pagina in die CSS en JS bevat.

Alle bovenstaande code kan in één bestand worden geschreven. Dit is eigenlijk hoe het in het begin werd gedaan, maar de ontwikkelingsgemeenschap realiseerde zich dat het niet optimaal was. Inderdaad, voor elke nieuwe functie die moest worden toegevoegd, moest de hele code worden aangepast, en het was niet eenvoudig om in een omgeving met meerdere ontwikkelaars te werken.
Dit heeft ertoe geleid dat webontwikkelaars de MVC-architectuur hebben overgenomen, die code in wezen in drie componenten splitst :

Le Modele : Dit is bedrijfslogica, onafhankelijk van de gebruikersinterface. In ons voorbeeld is dit de code die de artikelen uit de database haalt.
Visie : Een visuele weergave van de gegevens. In ons voorbeeld is het de HTML-code die de artikelen weergeeft. Dus de gegevens komen uit het model en de HTML is de weergave.
De controller : Het wordt aangeroepen door op de link “Zie artikel” te klikken. De Verwerkingsverantwoordelijke haalt met behulp van het Model gegevens op uit de database en geeft deze weer in de View.

Laten we eens kijken naar een typische URL voor een toepassing die de MVC-architectuur gebruikt.
http://www.abc.com/blogpost/id/1
hier blogpost lezen is de naam van de controller en de view is een actie (methode) van deze controller. id is de item-ID. Als we deze URL in een browser invoeren, gaat het verzoek naar de actie "Bekijken" van de "BlogPost" -controller en roept het model daar op om de inhoud van het artikel met ID "1" te krijgen, in de vorm van 'een object. Dit object wordt vervolgens doorgegeven aan de "View" die moet worden weergegeven.
Meer concreet: de volgende URL https://www.ux-republic.com/blog/page/2 geeft de tweede pagina weer van de lijst met alle UX-Republic-blogposts.
Als we de URL opsplitsen, hebben we: :

blog, de controller
pagina, de identifier die het paginanummer aangeeft
2, het paginanummer

Elke keer dat op de paging wordt geklikt, is het dezelfde methode van de controller blog die wordt uitgevoerd en die verantwoordelijk is voor het ophalen van de inhoud die overeenkomt met de pagina geselecteerd.

Ajax & Single Page-apps (SPA)

Als je in het afgelopen millennium bent geboren, herinner je je de webmailproviders Hotmail en Yahoo!, die erg populair waren in de jaren 1990 en 2000. Als je op de inbox of op een e-mail klikte, werd de hele pagina bijgewerkt. Rond 2004 kwam Gmail met een belangrijke feature: Ajax. Met Ajax wordt niet de hele pagina vernieuwd - alleen de delen die het nodig hebben. Dus als u een nieuwe e-mail ontvangt, ziet u deze gewoon bovenaan de pagina verschijnen, zonder deze opnieuw te hoeven laden. Hierdoor kregen gebruikers een betere browse-ervaring en werd Ajax een zeer populaire manier om apps te bouwen.

Wat is Ajax?

de term Ajax vertegenwoordigt een grote groep webtechnologieën die kunnen worden geïmplementeerd in een applicatie die communiceert met een server op de achtergrond, zonder de huidige status van de pagina te verstoren.
Bij Ajax verstuurt u een verzoek per Begin naar de server, en de server stuurt zijn antwoord zonder de webpagina te blokkeren, wat betekent dat de gebruiker zonder onderbreking kan blijven browsen. Het antwoord van de server wordt ingevoegd of toegevoegd aan de huidige webpagina.
Op sites die geen Ajax gebruiken, vereist elke gebruikersactie een volledig herladen van de pagina van de server. Dit proces is inefficiënt en zorgt voor een slechte gebruikerservaring omdat alle inhoud op de pagina verdwijnt voordat deze weer verschijnt.
Ajax is een van de technieken die worden gebruikt om applicaties met één pagina te bouwen (Enkele pagina-apps ou SPA's). Zoals de naam al doet vermoeden, past de hele app op één pagina en wordt alle inhoud dynamisch geladen. JavaScript-frameworks zoals Angular, React en Backbone.js kunnen worden gebruikt om te doen SPA's.

Servers en webbrowsers

Browsers zijn de tolken van het web. Ze vragen gegevens op bij webservers, die de aanvraag verwerken en een reactie in HTML naar de browser sturen (met CSS, JS, afbeeldingen, enz.), en deze reactie wordt vervolgens weergegeven.
Een verzoek aan de webserver kan worden gedaan met behulp van een van de drie belangrijke methoden: :

Begin : ontvang de gevraagde bron als antwoord;
HEAD : hetzelfde als Begin, maar de bron wordt opgehaald in de kop van het antwoord;
POST : stuur de gegevens naar de server.

Wanneer u bijvoorbeeld "google.com" typt in de browser, stuurt deze deze opdracht op de achtergrond naar de google.com-server:
KRIJG: http://google.com
De Google-webserver kijkt dan naar het hoofdbestand (index) en stuurt zijn antwoord terug naar de client. Het verzendt meestal HTML-inhoud en CSS-bestanden samen met andere mediabestanden.

# Vertaling van het artikel Begrijp webontwikkeling in minder dan 1 uurDoor Sjeik Ismail

Begrijp webontwikkeling in minder dan een uur [deel 2]