Cum implementați cnc

  • PHP
  • Fă-o singur
  • Apache
  • referințe
  • Rescrierea URL-ului

Vreau să schimb implementarea ccc în camera mea, dar nu știu cum va fi mai bine. Spoilerul descrie metoda mea. Aș dori să văd cum implementați acest lucru fără a utiliza cadre







Titlu Acesta este scris în fișierul index.php după încărcarea kernel-ului și a tuturor fișierelor necesare

fișierul de reguli arată astfel:

De exemplu, pentru test.ru/user/new fișierul modules / account / new_user.php va fi conectat,

pentru link-ul test.ru/user/settings - modules / account / settings.php și în funcție de setările specificate - acestea vor fi afișate (implicit generale). Cu toate acestea, în acest caz, modulul este conectat diferit:

Cu siguranță puteți încărca modulele de fișiere / account / index.php și deja definiți acțiunile pentru fiecare modul - este incomod, așa că am decis: permiteți-vă totul să fie într-un singur loc (puteți să îl puneți într-un fișier separat).


Fișierul htaccess arată simplu

Această metodă a fost scrisă mult timp și funcționează bine și am folosit-o atât de mult încât nu mă pot gândi la nimic nou.

Singurul avantaj este că puteți specifica orice reguli, de exemplu:


pagina de profil a utilizatorului cu id = 15484 va fi afișată

sau doar datele de conectare ale utilizatorului, fără a specifica codul său de identitate

Există mai multe dezavantaje. În plus față de evident - nu puteți trece parametrii prin matricea $ _GET.


atunci în acest caz trebuie să scriu reguli suplimentare, ținând cont de tipul și sortarea, va arăta cam așa:


PS: Îmi pare rău, dacă ceva este descris în mod murdar - Sunt deja blocat

În general, algoritmul de rutare și expediere poate fi descris după cum urmează
URI-ul arată ca example.com/

unde
Este o regulă care descrie alegerea unei clase / script / funcții care să se ocupe de parametrii
de exemplu, / post / add poate fi convertit în clasa PostController > sau funcția post_add () <>

Este o regulă care descrie parametrii
de exemplu, / x / 1 / y / 2? z = 3 pot fi convertite într-o matrice matrice asociativă 1, y => 2, z => 3> notația și ordinea parametrilor nu sunt importanți în același timp

Cumva schema este prea dureroasă. În general, expedierea se face prin intermediul unor agenți obișnuiți. și asta e tot.
De asemenea, pentru a utiliza cadre de grăsime de dimensiuni mari, este mai bine să căutați microframe sau biblioteci separate pentru implementarea rutei.

VBart. cu tot respectul meu cel mai profund pentru python, observ pentru mulți pythonists trauma ancestrală a urii de php.

URI-ul pe care l-ai adus pentru acei ani de lucru standard și nici o modalitate de a fi legat. Python, care la acea vreme făcea primele timbre pe web, le-a făcut prin același lucru.

Nu am folosit cârje în această privință în ultimii zece ani și n-am avut aproape niciodată probleme cu re-scrierea de servere. Cred că trăiești într-o ceață ideologică prejudiciabilă.

fear86
Este foarte simplu, aveți o aplicație, iar dacă scrieți pentru web, atunci cel mai probabil va implementa interfața wsgi (descrisă în PEP-333 [3]). În forma sa cea mai simplă, aveți o funcție, numită așa. wsgi-handler, care are ca argument un șir cu variabile de mediu, inclusiv URI. Ce urmează cu el pentru a face și cum să-l rezolve pentru tine. Nu există scripturi în sfera de acoperire a serverului web și, prin urmare, nu există nici o legătură cu numele scriptului sau altceva. Ce va arăta URI-ul tău este de până la tine, și cel mai probabil le vei face bine și simplu, pur și simplu pentru că un astfel de parsit URI este, de asemenea, ușor și convenabil.







Dar acesta este doar un caz zero. Am adus-o pentru că acum programatorii PHP îmi vor spune că în cadrul lor există totul la fel. Cu toate acestea, o astfel de întrebare, așa cum sa discutat în acest subiect, ar putea stabili doar PHP-programator, iar termenul CNC în sine, de asemenea, a fost inventat în PHP, pur și simplu, pentru că înainte de a inventa moduri de a face URI frumos și clar, trebuie mai întâi să fi fost ruina lor.

În realitate, cel mai probabil scrieți folosind un cadru care în sine face toată munca pentru dezasamblarea URI și oferă pur și simplu o interfață convenabilă. Dacă acest Django, în cel mai simplu caz, aveți un fișier urls.py (sau mai multe) care pur și simplu înregistrează ca un afișaj pe respectivele funcții handler URI (ceva chiar poate fi comparat cu un set de locație Femeie în Nginx), se pare aproximativ (în stânga o expresie regulată cu capturarea variabilelor, iar în dreapta funcția care va fi apelată cu parametrii corespunzători):

În acest caz, când generați un link în șabloane, puteți face operația inversă - afișați setul de valori în URI finit.

Alte cadre pot avea alte scheme, de exemplu, CherryPy știe cât de asemănător cu Django este modul de a configura o mapare URI. atât automat, cât și automat, în funcție de structura aplicației, constată ce metodă a obiectului de a apela cu care parametri.

gro
Se pare că mulți dintre cei care scriu Pythonists sunt foști programatori php, care îți pare rău pentru atât de mult timp și efort pe tam-tam cu acest șablon.

Despre ceață - ești în zadar, cum crezi câte nginx-config-uri o zi văd? Privind la profilul meu, puteți ghici asta foarte mult. Cum crezi, dacă configul este plin de rahat, constă într-o grămadă de rescrieri și conține, de asemenea, lucruri cum ar fi locația

\ .php. ce limbă este aplicația pe care o servește? A fost corect ghicit. Și 95% dintre aceștia, iar dacă configurația este curată și simplă, atunci este probabil Ruby / Python / erlang / node.js / Java.


este foarte diferită de configurația python (luată din docul nginx)

Am citit-o.
Nu am văzut nimic rău în cuvintele mele.
Cu excepția cazului în care a fost ușor să formulați ideea pentru că este un hubr:
1 - chiar conceptul de CNC a apărut după ce aceleași căi au fost făcute curbe. Inițial, atunci când statica căii a fost dosare CNC, fișiere ... dar apoi nu a existat un astfel de lucru. Apoi, căile "s-au rupt" deoarece era mai ușor să lucrezi prin parametrii primiți și era mai ușor să transferi indicii numerici parametrilor ... Unde era inerția de a gândi, undeva o adevărată simplificare. Apoi, dintr-o dată, sa dovedit că modalitățile normale erau mai bune și au fost reanimate. A început să revină pe baza a ceea ce este - pe baza curbelor parametrilor primiți. De aici complexitatea. Soluția evidentă este de a face un singur punct de intrare și apoi să continuați să lucrați cu o interogare normală, cu nume care pot fi citite de text pentru "dosare" și "fișiere" etc. Dar asta e ghinionul - o facem din nou pe motor, în care totul merge într-o formă digitală ... Trebuie doar să renunțe la tot.
2 - Am mai spus că numele de text nu sunt mai rău decât cele digitale, că acest lucru nu va afecta în nici un fel performanța și că odată ce o faceți, nu mai urcați în ea ...

3 - Ei bine, despre python. Python da, limbaj bun, are mai multe avantaje notabile peste PHP, dar are un „defect fatal“ :))))) Python nu este pe fiecare mașină, este puțin mai complicat pentru a menține, deoarece necesită demon în mod constant de viață, cu toate ... Cereri este mai puțin ... mai multe soluții în front-end nu poate fi - doar ... uite texted codor, care este familiarizat cu Python și PHP ... Python este bun ca o bază pentru undying echipa si termina intotdeauna proiectul. Și când scrieți sub orice și pe toate, atunci nu există altă alternativă. Chiar dacă 80% din proiectul dumneavoastră va permite utilizarea de piton, ce să facă cu restul de 20%? Păstrați-vă abilitățile, mediul de dezvoltare (inclusiv bibliotecile, dezvoltările, echipa de dezvoltare etc.) în două limbi? Ordine de refuz? A impune o soluție mai complexă clientului, pentru că este mai ușor pentru dvs.? Și bine, dacă 20%, este cu atât mai ușor să le abandonezi ... Ei bine, dacă sunt 50/50?

Principalul lucru pe care să-l scrieți bine, dar ce nu contează ...







Articole similare

Trimiteți-le prietenilor: