Buna seara.
Voi fi foarte recunoscator daca ma ajuta cineva cu o nelamurire pe care o am.
Nelamurirea mea este urmatorea: care este elementul din mijloc in crearea unui site?
Sa fiu mai explicit, daca privim un site prin prizma paradigmei MVC, atunci View va fi HTML,CSS,JS, etc., Model va fi PHP,SQL, etc., iar despre Controller si este intrebarea mea.
Ce va fi acest Controller?
De exemplu, in prima etapa folosind HTML5, CSS3 si JavaScript (AJAX prin JQuery, plus XML sau JSON la nevoie) va fi creata partea vizuala. In a doua etapa, folosind PHP, SQL (de exemplu MySQL) si acelasi JS va fi creata “memoria”, stocarea informatiei.
Bun, si acum in a treia etapa, cum se uneste FrontEnd cu BackEnd? Imi scapa acest segment.
Am auzit despre “engine” pentru PHP (de tip MVC sau MVVC, etc.), sau despre Angular/React prin Node.js, dar asa si nu m-am lamurit.
Ca sa fie mai simplu pentru toti, sa luam un exemplu: www.hltv.org
O interfata vizuala comunica cu un server/DB si ne arata informatia.
Asadar, cum o face? Care sunt toate “instrumentele” folosite pentru a crea un astfel de site?
Daca o face hobby urmeaza niste carti de … html, css,php, mysql asta asa in regim procedural, dupa iei frumos Oop-ul, dupa mvc-ul ca si arhitectura si abia dupa te poti uita peste un framework de preferat micro gen slim sau … sillex parca ii zice.
Eu iti recomand o carte pentru fiecare de preferat sau o serie de tutoriale.
Ideea e ca is multe cunostiinte pe care eu nu le-as recomanda sa le asimilez pentru prima oara pe toata intr-o saptamana, eu as recomanda o luna.
Ceea ce vrei tu sa nu se poate explica in cateva cuvinte si cateva cuvinte decat teoretic, insa ai avea nevoie si de niste… schema si exercitii.
Era pe undeva o schema pe github dar nu o gasesc in momentul asta, doar ca si road nu asa doar… ca si tehnologii.
Simplificat la maximum, controller-ul este cel care aduce datele din baza de date cu ajutorul modelelor şi le tranteşte pe ecran prin intermediul view-ului (eventual dupa ce combina datele provenite de la model(e) si le mai proceseaza un pic).
Greseala mea, am uitat sa mentionez urmatoarele. Poate parea bizar, dar toate “instrumentele” care sunt enumerate in primul mesaj imi sunt deja cunoscute. Cei drept, la un nivel incepator.
Cu alte cuvinte, sunt in stare sa fac o interfata si separat sa accesez o baza de date prin PHP, insa zona din mijloc care ar permite sa pot genera pagini fara a crea pentru fiecare un fisier aparte imi ramane necunoscuta.
Priviti pe www.hltv.org, cand accesezi un link iti este afisata o pagina generata din informatia stocata in DB.
Acest “miracol” doresc sa-l inteleg.
Nu e niciun miracol, fiecare link are probabil cate un controller si cate un view. Eventual se pot imbrica mai multe view-uri unul intr-altul (de exemplu ar putea exista un view comun denumit “layout” care sa contină elementele comune din pagini + unul sau mai multe view-uri personalizate).
Cel mai simplu ai un fisier .html in care ai un element de care se leaga un script in JS si il inlocuieste cu site-ul in sine.
Face un apel spre server, ia un fisier JSON care contine toate datele de care are nevoie (cu rest/graphql,websockets…), template-ul site-ului e scris in script-ul JS in componente care iti pun datele in interfata si o randeaza, respectiv re-randeaza daca se schimba ceva. Cand apesi pe link-uri de fapt in JS ai un router care spune ce componente sa se randeze pe ce pagina si ce informatii sa ceara de la server. (e un fel de model) Cand completezi un formular tu trimiti o cerere spre server, care verifica daca sunt corecte datele si le introduce in baza de date, respectiv raspunde cu un json cu o eroare sau cu succes. (aici e si controller-ul si view-ul)
Pe server ai o baza de date, un sistem pentru validarea datelor la introducere, un sistem pentru permisiuni si un mod de a genera si trimite json din baza de date, de obicei rest, graphql sau un protocol de mesagerie cu websockets daca e nevoie de ceva in timp real. (aici e modelul si controller-ul)
In trecut generam .html-ul direct de pe server, view-ul era un sistem care genera html-ul pe baza unui template in php. (nu ne mai trebuia un api cu json, dar nici nu puteam avea site-uri interactive asa usor)
Ca si tehnologii arata asa :
Interfata site(react/angular/vue/…) -> API server (un server cu node.js/php/.net) -> baza de date (mysql/postgresql/mongodb…)
Exista si cateva baze de date mai exotice (nosql), care pot inlocui total API serverul. Respectiv putem avea mai multe api servere si mai multe api-uri pe un singur site.
Paginile se pot randa din start pe server la prima trimitere, adica inainte sa inlocuieasca JS-ul elementul care urmeaza sa fie inlocuit deja este randat intregul site de server. (dar cand js-ul se incarca inlocuieste acest site cu ultima varianta)
Ok, dar iti dai seama ca adaugi un layer de complexitate… O data ca trebuie sa randezi pagina pe server, si inca o data trebuie s-o poti randa si pe client, cand e cazul. Si cred ca este evident ca nu poti “pre-randa” doar pentru homepage, trebuie s-o faci pentru toate paginile.
In cazul ultimilor versiuni de angular/react/vue/markojs… trebuie doar sa adaugi o linie in configuratia de webpack si sa servesti pagina cu node. (la care ii faci cache)
Exista si solutii precum razzle (https://github.com/jaredpalmer/razzle) care promite zero configuration si next.js (https://github.com/zeit/next.js/) care fac si mai simpla configuratia in cazul site-urilor foarte complexe, respectiv optimizeaza putin lucrurile daca unele rutari sunt statice (nici nu mai incarca JS).
Un avantaj foarte mare care poate nu e evident e hot module reloading si diferitele utilitare pentru dezvoltare, daca folosesti pur si simplu php nu mai poti scrie cod on the fly fara sa mai trebuieasca sa dai refresh total la pagina la ctrl+s cu livereload. Asa, daca modifici ceva ori din baza de date, ori din js se vede instant schimbarea si se schimba doar ce ai schimbat.
Daca separi JS-ul si HTML-ul static pe un CDN atunci e mult mai simpla protejarea api serverului si bazei de date (care pot avea proxy-uri).
O interfata server-side rendered cu librariile JS se poate crea si cu PHP fara sa faci un API, dar atunci datele trebuie sa ti le incluzi intr-un template php in js si se cam pierde rostul.
Uite cel mai bun motiv pentru randare clientside :
Pe telefonul mobil nu ai internet mereu, daca randezi un site clientside poti sa iei datele din localstorage daca nu ai internet si sa iti fie disponibil site-ul cu ultimele date stocate.
Dupa mai e performanta daca ai date care se actualizeaza de o suta de ori pe secunda. Daca incerci sa schimbi continutul unui element html de 100 de ori pe secunda cu jquery o sa vezi imediat ca iti sare procesorul la 100%. React de exemplu calculeaza diferentele si schimba doar ce s-a schimbat. MarkoJS de exemplu e atat de efectiv incat poti muta/recolora 200 de div-uri de peste 60 de ori pe secunda.
Un alt atu foarte important e ca dupa prima incarcare, site-ul tau va fi instant. Check this out :
Cum sa fie asta cel mai simplu?
Unui incepator care nu intelege bine nici ce e MVC nu poti sa ii recomanzi api-uri si React & co.
Cel mai simplu mod ramane cel cu html randat server-side aka metoda clasica, care inca functioneaza foarte bine.
Specific ptr. intrebarea adresata de tine si in contextul unui webapp “clasic”, M si V si C sunt toate legate de backend, mai degraba decat de frontend. Modelul e partea codului care se ocupa de business rules, interactiunea cu baza de date etc, View-ul e partea codului care se ocupa de generatul documentelor HTML[1] care vor fi consumate de browser intr-un mod foarte pasiv[2], iar Controller-ul este partea codului care leaga totul impreuna. Controleaza ce se intampla daca vrei.
Mai precis, un controller clasic pentru o ipotetica aplicatie de management a unei librarii o sa arate cam asa:
- pentru calea /books/:bookId
- asigura-te ca request-ul HTTP este "in regula"
- apeleaza la componentele de model pentru a obtine detalii despre cartea $bookId
- executa un call la Amazon cu datele modelului, ca sa obtii nota cartii si niste comentarii
- ia toate datele astea si cu ajutorul unui view genereaza un document html pentru utilizator
Pentru fiecare limbaj si framework treaba asta o sa arate diferit, dar cam cu asta s-ar ocupa la modul cel mai general controller-ul. Un controller contine de regula definitii pentru mai multe cai, asa ca poti avea BooksController pentru tot ce tine de interactiunea cu carti si ClientController pentru tot ce tine de interactiunea cu clientii librariei etc.
[1] Sau XML, text, imagini etc.
[2] Strategia e simpla. Controllerul genereaza un document complet, bazat pe datele aplicatiei. Acesta continue link-uri spre alte “pagini”, care vor determina alte controllere sa se execute cand utilizatorul acceseaza link-ul respectiv etc. E un model OK, dar majoritatea aplicatiilor moderne nu-l mai folosesc exact asa, ci muta mai tot ce inseamna de View si Controller ca o aplicatie javascript.
Serverul web “trimite” URL-ul către controller (de regulă fișierul index.php) unde imaginează-ți un mare if() cu foarte multe ramuri:
if(URI-ul începe cu 'news' și conține un număr) {
extrage o știre din baza de date (ex: where id_stire=21731), include fișierul php care conține template-ul de știre și afișeaz-o
} elseif(URI-ul conține 'results') {
afisează pagina de categorie
} else {
afisează homepage.php
}
Uneori “între” server și controller mai stă și fișierul .htaccess care “traduce” intern un URI de genul news/21731/guardian-its-more-fun-for-me-to-play-cs-again în ceva asemănător cu “index.php?module=news&news_id=21731&slug=guardian-its-more-fun-for-me-to-play-cs-again”
Va multumesc tuturor pentru raspunsuri.
Insa, se pare ca sunt eu mai ‘slow’ fiindca, nu am gasit raspunsul care sa ma satisfaca.
Adica, nu am inteles ce imi lipseste ca sa pot face un site identic cu hltv.org (din punct de vedere tehnic).
Fac un template folosind HTML si CSS, apoi pe un VPS imi instalez LAMP, dar ulterior ce fac?
Cum unesc UI cu Server?
Ma scuzati daca sunt stresant, sau daca am ratat raspunsul si trebuie sa-mi repetati.
Nu prea e clar care-ţi e nivelul de cunoştinţe. Mai devreme ziceai că instrumentele enumerate îţi sunt familiare, iar acum dai impresia că nu ştii ce face de exemplu <?= "hello world" ?>…
nu am inteles ce imi lipseste ca sa pot face un site identic cu hltv.org
Îți lipsesc câțiva ani de experință. Înainte să te apuci de scris cod ia un pix și schițează structura bazei de date: echipe, campionate, etape, jucători, meciuri, scoruri etc… Dacă-ți iese, încet, încet te-apuci și scrii fișiere php in care interacționezi cu datele respective
Punctual as dori sa specific faptul ca eu consider ca e o idee nu prea buna sa se inceapa cu baza de date. Va crea un obicei greu de corectat mai tarziu, pe motiv de “dintotdeauna am facut asa si a fost bine”. Nu, dupa 1-2-3 siteuri nu mai e bine asa.
Trebuie inceput cu “ce se cere”. Adica o lista de functionalitati. Cat de lunga, dar pusa pe foaie si gandita. Exclus copieri de functionalitate de la x. Si eu am auzit “vreau motorul de cautare de pe okazii sa fie si la noi in site” si nu lucram la firma de apartament. La final vei avea ceva de genul:
Listă cu cele mai recente stiri de azi
Lista cu cele mai citite stiri de ieri
Lista meciurilor in desfasurare din sportul X
…
In etapa asta se clarifica tipuri de date are siteul, dar din nou nu recomand sa se schiteze baza de date si relatii si tot felul. Pur si simplu vei lua cate un element din lista si vei lucra la el pana il termini, prima data scrii codul care aduce datele, apoi populezi si tabelele, etc
La final vei avea toate elementele de functionalitate
