Mesaje de ieșire pentru utilizator în aplicațiile web

Mesaje de ieșire pentru utilizator - o acțiune destul de comună pentru a efectua aplicații web. Aceasta poate să apară în procesarea formelor, poate fi mesaje de eroare și mesajele care spun că este necesar să se creeze un cont atunci când un utilizator încearcă să acceseze o parte restrânsă a site-ului, precum și în multe alte cazuri.

Foarte des, crearea și producția de mesaje sunt efectuate pe diferite HTTP-cereri. De regulă, este convenabil să se utilizeze o redirecționare după procesarea formularelor (pentru a evita problemele cu ajutorul butoanelor Back și reîmprospăta), dar, în același timp, un timp natural pentru a crea mesajul - acesta este momentul formelor de prelucrare și luarea de măsuri legate de acesta. De ce? Imaginează-ți ce mesajul tău ar trebui să arate ceva de genul: „Numărul de unități comandate«Mouse Pad»a fost cu succes schimbat 7-12“. După redirecționării, eventual pe un complet diferit în ceea ce privește funcționalitatea paginii, acesta va fi o durere de cap in plus - pentru a determina ce a fost făcut înainte.

Cel mai adesea, mesajele sunt afișate exact în POST-cerere, care este angajată în prelucrarea formelor - nu este corect, inscripția „această pagină este depășită,“ strica viața (atunci când utilizatorul place încerca butonul Înapoi).

Cineva folosește un redirect, fluturând mâna la mesaj prietenos.

În același timp, există un mod simplu și evident pentru a face viața mai bună. In ciuda dovezilor, pentru un motiv oarecare nu am avut pentru a vedea că cineva a folosit - cel puțin atunci când am fost uitam sursa greșită.

Deci, avem o problemă - mesajul ar trebui să fie „viu“ în diferite interogări. Avem nevoie de un mesaj de tip text mecanism care trece la pagina pe care trebuie să-l afișeze. Deja ați gândit, probabil, a sesiunii.

Da, în general, atunci ai dreptate. Alte metode, cum ar fi printr-o variabilă globală, nu permit să păstreze datele în cazul în care un redirect (Observația Maxim Naumenko). În plus, de asemenea, de obicei, eu fac, astfel încât fiecare ecran în cerere au avut posibilitatea, împreună cu alte informații, pentru a afișa mesajele care au fost formate în ecranele anterioare. Acest lucru este convenabil, deoarece nu are nevoie să se pregătească ecrane separate pentru a afișa mesaje, iar utilizatorul nu trebuie să faceți clic pe mouse-ul din nou. Dar, adevărul, aici este necesar să se ia în considerare designer - pentru a selecta zona în care au apărut mesaje.

Ideea este foarte simplu, și poate fi realizată cu ajutorul unei perechi de clase.

Primul lucru care vine în minte - pentru a crea un mesaj de clasă. care ar fi, de fapt, a fost un mesaj pe diagrama noastră de clasă simplă. Mesajul ar trebui să fie capabil să se păstreze în sesiune, precum și de afișare.

Pentru a accesa variabila de sesiune este utilizat $ _SESSION.

Rețineți că $ _SESSION - este o matrice, folosim doar un element al matrice cu indicele „session_message“.

În acest caz, avem de a face cu „matrice de matrice“ - faptul că stocăm în „session_message“ elementului. este o matrice, aceasta este lista de mesaje care trebuie transmise (ei, desigur, pot exista mai multe).

Dacă nu puteți găsi firul, e timpul să perie pe secțiunile manuale dedicate sesiuni și matrice.

Rețineți că, în acest moment, în cadrul sesiunii a pus nu obiectul în sine, ci numai textul mesajului. OOP ne permite să se schimbe în continuare comportamentul metodei send (). klienskij fără a schimba codul, care se referă la această metodă (de exemplu, în viitor, în cadrul sesiunii pot fi înregistrate complet obiecta mesaj. În cazul în care va exista o mulțime de domenii).

Imaginați-vă ce ne-ar fi făcut cu ajutorul funcțiilor. Poate ne-ar funcționa message_send ($ txt). încă ar message_to_page funcția ($ txt). Acum trebuie să adăugăm posibilitatea de comportament diferit pentru diferite tipuri de mesaje. apeluri de funcții se schimbă: message_send ($ txt, $ fel). message_to_page ($ txt, $ fel). Va trebui să pieptene prin întregul cod de aplicare în căutarea pentru astfel de funcții, ceea ce face corecturi.

Acest lucru poate fi evitat în avans, în anticiparea situației prin prezentarea unui mesaj ca fiind o matrice asociativă: $ msg [ „txt“]. $ Msg [ 'fel']. întrucât, într-un apel de funcție este doar o singură opțiune. Te simți ca și caută să devină o clasă?

Deci, OOP vă permite permite să nu se gândească la totul dinainte.

Dă-i drumul. Pe fiecare pagină, trebuie să aducem toate mesajele primite și a le elimina din sesiunea de după aceea. Acest lucru este foarte similar cu citirea scrisorilor din cutia poștală.

Următoarea clasă - Inbox - doar pentru acest scop și este destinat.

Hai să testăm sistemul nostru de mesagerie.

Să creeze un exemplu foarte simplu, care este ca răspuns la trimiterea formularului va raporta numărul de secunde în minutul curent.

Lucrul cu tablouri și sesiuni care le-am ascuns în cadrul claselor și codul de final sa arate frumos și simplu.

Creați un director de pe serverul web, și apoi creați-l, aceste trei fișiere și încercați script-ul pentru a lucra. Probleme Notă cu butoanele de la Refresh nu sunt acolo.

Acum, imaginați-vă că creați un portal complex, în cazul în care, de regulă, în paginile există câteva blocuri, iar fiecare poate conține în sine o aplicație separată.

Aici întâlnim două dificultăți:

Aș dori să văd o listă de mesaje apar într-o anumită parte a paginii, și ai ales deja un loc bun pentru ea.
Problema este că este necesar pentru a rula comanda $ inbox-> toPage () chiar în acest moment, ceea ce ar corespunde poziției unei liste de mesaje pe pagină. Dacă vrem să schimbăm poziția listei, va trebui să meargă în codul, dar nu este bun pentru această schimbare constantă a cadrului portalului. Cea mai bună soluție ar fi să încheie mesaje într-un modul separat, care este cunoscut doar numai că trebuie să fie conectat la cadru.
Acesta este liber de altercatiile ordine strictă. Într-adevăr, o dată rezultatul retragerii Inbox nu depinde de funcționarea sistemului (în această etapă - toate datele pe care le avem deja într-o sesiune), de ce complexitatea suplimentară?
Pentru a menține aspectul (proiectare) a listei de mesaje trebuie să vă faceți griji despre HTML-cod pe care le-am cusut în metodele toPage () căsuța de mesaje primite și clase. De regulă, este necesar să se schimbe PHP-cod pentru a schimba design.

Pentru a încerca să rezolve prima problemă, puteți crea un tampon în care pentru a stoca rezultatele Inbox de ieșire de lucru.

Poate vom avea unele similare (în Inbox) lucrurile, și este necesar să se creeze un sistem tampon. Pentru a se evita confuzia în cazul în care a cărei concluzie trebuie să vină la denumirea tampoane. Vom fi stocate undeva secvență, în conformitate cu care ar trebui să fie tampon de ieșire - de preferință într-un fișier extern, face mai ușor de a face modificări.

Deja în această încercare de soluții ne oferă ideea de a folosi XML ca un mijloc de stocare a datelor intermediare. Și utilizarea de stil XSLT se va ocupa cu a doua problemă.

Nu voi insista pe faptul că XML-ul este, și ceea ce este XSLT. Dacă nu sunteți familiarizați cu aceste lucruri, zvon.org este o bază bună pentru a explora.

Ideea este de a genera HTML-cod nu este în modul toPage (), și structura XML. pagina de document va fi creat sub forma unei benzi, cu XML-cod (acesta va servi ca un „tampon“) și vom folosi XSL-transformarea în ultima etapă a scenariului.

Pentru început, să ne imaginăm că trebuie să fie un rezultat al părții principale a codului.

Ce este - pur și simplu ghici - două posturi și forma. Notă, PHP-script ar trebui să se pregătească doar un G-string - este foarte simplu. Mai mult decât atât, ordinea tag-ul principal nu este important - pot fi puse la început, de exemplu, va fi convenabil pentru programator. Cum să-l pună în aplicare. Este posibil, aproape fără a schimba nimic, utilizarea de ieșire tampon, în loc de HTML-cod pentru a afișa XML, și în cele din urmă doar pentru a captura de ieșire la un șir de caractere. Dar apoi pierdem flexibilitatea - de exemplu, doresc uneori la informații de depanare direct pe pagină (folosind ecou). În același timp, dezvoltatorii PHP lucrează la DOM-modul, care oferă un mod mai avansat pentru a crea și trimite un document de copac. Dacă vrem să pună în aplicare DOM, va trebui să redesenare toate app, schimbarea siruri de caractere de ieșire în crearea DOM-elemente. Așa că prefer să stocheze reprezentare bazate pe XML de obiecte în obiecte ele însele, în mod succesiv colectarea de un XML document comun. Nu este atât de dificil, ai nevoie doar de o ușoară modificare. Veți găsi că un astfel de dispozitiv nu este atașat strâns la o metodă specifică de stocare XML-date, și se va face trecerea la DOM folosind „un pic de sânge.“ În primul rând, observăm că fiecare dintre noastre facilitatea utilizează metoda toPage (). Această asemănare ar trebui să ne facă să se gândească la modul în care să se introducă o nouă clasă părinte comun. Să fiecare clasă, care este capabil de a crea bucăți de pagini XML document va fi moștenită de la o clasă care va avea grijă de XML-reprezentare a obiectului. Sună-l Outputable.

toPage () metoda este făcută goală - în acest caz, este necesar ca un indicator al modului ar trebui să externe „Matryoshka“ de clasă pentru a comunica cu clasa interioară. Cu toate acestea, ar putea fi invitat la punerea în aplicare implicit, dacă observăm că există multe obiecte care aceleași concluzii chiar eu pe aceasta pagina.

Inbox mesaje și unele clase schimbat - acum ambele au moștenit de la Outputable. precum și schimbarea și metodele toPage ()

Am schimbat modul de a ieșire - acum, în loc de ieșire direct la o reprezentare externă pagină pentru moment fiind păstrate în Outputable. care „stă“ în fiecare dintre obiecte. appendOutput (), metoda este o structură ecou înlocuitor (). Pentru a alege obiectul de ieșire, este utilizat getOutput () metoda.

Acum, să vedem ce codul de partea de client, care va rezolva aceeași problemă ca și înainte.

Principala noutate - în obiectul $ global_content. al cărui nume vorbește de la sine. În acest caz, aparține clasei de Outputable. în aplicații reale vă va crea, probabil, o clasă separată pentru conținutul paginii.

Dacă te uiți atent, partea substanțială a script-ul nu sa schimbat prea mult - același inbox. aceeași toPage (). Declarație a adăugat că conținutul listei de mesaje se afișează în conținutul paginii. Pentru o schimbare acum a generat două mesaje.

Pentru a vedea rezultatul, rămâne doar să pregătească XSL-șablon.

Ce avem?

În primul rând, este sigur să-și asume proiecte complexe - asigurarea independenței reale a modulelor. Ordinea de stivuire a paginii cu rezultate este acum controlat de un XSL-șablon extern, și nu depinde de ordinea run-in-uri.

Orice modul care genereaza XML-date, ca rezultat al muncii lor, pot fi utilizate în cadrul proiectului. De altfel, acesta este unul dintre avantaje față de șablon motoare, în care crearea unei secvențe de date este de a invoca metode (atribuiți etc.) unui anumit motor, în care nu există un standard comun.

Un alt avantaj - ușurința de depanare. Dacă executați script-ul, veți observa că pe fiecare pagină există depanare-concluzie - XML-prototip care simplifică mari de depanare aplicații.

Ce trebuie să ne gândim, de asemenea, despre - modul de a crea obiecte mesaje. Nu este întotdeauna convenabil să utilizeze noul cod direct în client. Dar poate că acest lucru este un subiect pentru un alt articol.

În cele din urmă, în galop despre perspectivele: