Afișarea mesajelor către utilizator în aplicații web. Parametri de interogare PHP-Swagger JQuery Funcții AJAX pentru interogarea bazei de date CRUD

3.3K

Afișarea mesajelor către utilizator este o acțiune destul de comună pe care o aplicație web ar trebui să o efectueze. Poate apărea la procesarea formularelor, pot fi mesaje de eroare, mesaje care vă spun să vă înregistrați atunci când un utilizator încearcă să acceseze o parte restricționată a site-ului și în multe alte cazuri.

Foarte des, crearea și ieșirea mesajelor sunt separate în diferite solicitări HTTP. De regulă, este convenabil să folosiți o redirecționare după procesarea formularelor (pentru a evita problemele cu butoanele Înapoi și Reîmprospătare), dar, în același timp, momentul firesc pentru crearea unui mesaj este tocmai momentul procesării formularelor și al efectuării acțiunilor care însoțesc aceasta. De ce? Imaginați-vă că textul mesajului ar trebui să arate cam așa: „Numărul de unități comandate pentru articolul „Mouse Pad” a fost modificat cu succes de la 7 la 12.” După o redirecționare, poate către o pagină complet diferită din punct de vedere al funcționalității, va fi o bătaie de cap în plus să determinați ce s-a făcut înainte.

Cel mai adesea, mesajele sunt afișate în solicitarea POST care procesează formularul - acest lucru nu este bine, cuvintele „această pagină este depășită” strică viața (când utilizatorul decide să încerce butonul Înapoi).

Cineva folosește o redirecționare, renunțând la mesaje prietenoase.

În același timp, există o modalitate simplă și evidentă de a face viața mai bună. În ciuda faptului că este evident, din anumite motive nu am văzut pe nimeni să-l folosească - cel puțin când m-am uitat la sursele altora.

Deci, avem o problemă - mesajul trebuie să „trăiască” în diferite solicitări. Avem nevoie de un mecanism pentru a transfera textul mesajului pe pagina care ar trebui să-l afișeze. Probabil că ți-ai amintit deja despre sesiuni.

Da, in general ai dreptate. Alte metode, de exemplu printr-o variabilă globală, nu permit salvarea datelor în cazul în care se utilizează o redirecționare (notă de Maxim Naumenko). În plus, de obicei mă asigur că fiecare ecran din aplicație are capacitatea, împreună cu alte informații, de a afișa mesaje care au fost generate pe ecranele anterioare. Acest lucru este convenabil deoarece nu este nevoie să pregătiți ecrane separate pentru afișarea mesajelor, iar utilizatorul nu trebuie să facă clic din nou pe mouse. Dar, într-adevăr, designerul trebuie să se gândească aici - să evidențieze zona în care ar apărea mesajele.

Ideea este foarte simplă și poate fi implementată cu câteva clase.

Primul lucru care ne vine în minte este să creați o clasă Message, care, de fapt, ar reprezenta un mesaj în diagrama noastră simplă de clasă. Mesajul trebuie să se poată salva în sesiune, precum și să se afișeze pe ecran.

clasa Mesaj ( /** * Conținutul mesajului. */ var $conținut; /** * Constructor pentru inițializarea textului mesajului. * * @param conținut conținutul mesajului */ function Message($conținut) ( $this->conținut = $ content ; ) /** * Scrieți un mesaj în sesiune. */ function send() ( $_SESSION["session_messages"] = $this->content; ) /** * Trimiteți un mesaj în pagină. */ function toPage() ( echo " - " . $this->content ."
"; } }

Variabila $_SESSION este folosită pentru a accesa sesiunea.

Rețineți că $_SESSION este o matrice, folosim doar un element din această matrice cu indexul „session_message”.

În acest caz, avem de-a face cu o „matrice de matrice” - ceea ce stocăm în elementul „session_message” este o matrice, aceasta este lista de mesaje transmise (desigur, pot fi mai multe dintre ele).

Dacă nu ai găsit firul, este timpul să revii la secțiunile manualului dedicate sesiunilor și array-urilor.

Este posibil să aveți o întrebare. De ce sunt necesare cursuri aici? Ar fi posibil să te descurci cu două funcții. Dar să privim mai departe. Este posibil să fie nevoie să creăm mesaje cu diferite tipuri (informații, eroare, avertisment) și să stabilim destinatarii mesajelor.

Vă rugăm să rețineți că în acest moment nu obiectul în sine este introdus în sesiune, ci doar textul mesajului. OOP ne permite să schimbăm ulterior comportamentul metodei send() fără a modifica codul client care accesează această metodă (de exemplu, în viitor putem scrie întregul obiect Message în sesiune dacă are multe câmpuri).

Să ne imaginăm că am face asta folosind funcții. Probabil că am avea o funcție message_send($txt) și, de asemenea, o funcție message_to_page($txt). Acum trebuie să adăugăm capacitatea de a avea un comportament diferit pentru diferite tipuri de mesaje. Apelurile de funcție se modifică: message_send($txt, $kind), message_to_page($txt, $kind). Va trebui să parcurgeți întregul cod al aplicației în căutarea unor astfel de funcții, făcând corecții.

Acest lucru poate fi evitat prin anticiparea situației în avans prin prezentarea mesajului ca un tablou asociativ: $msg[‘txt’], $msg[‘kind’], atunci va fi un singur parametru în apelurile de funcție. Poți simți cum încearcă asta să devină o clasă?

Așadar, OOP îți oferă posibilitatea de a avea luxul de a nu te gândi la toate în avans.

Următoarea clasă - Inbox - este concepută doar pentru asta.

class Inbox ( /** * Matrice de mesaje primite. */ var $messages = array(); /** * În constructor, primim toate mesajele primite * și le ștergem din sesiune. */ function Inbox() ( if (este_matrice($ _SESSION[„mesaje_sesiune”])) ( $mesaje = $_SESSION[„mesaje_sesiune”]; $co = dimensiunea($mesaje); pentru ($i = 0; $i< $co; $i++) { $this->mesaje = mesaj nou($mesaje[$i]); ) ) /* șterge tabloul de mesaje */ $_SESSION["session_messages"] = array(); ) /** * Afișează conținutul căsuței primite pe pagină. */ function toPage() ( $co = sizeof($this->messages); if ($co > 0) ( echo "Mesaj din sistem:
"; ) pentru ($i = 0; $i< $co; $i++) { $this->mesaje[$i]->ToPage(); ) ) )

Să încercăm sistemul nostru de mesagerie.

Să creăm un exemplu foarte simplu care va răspunde la trimiterea unui formular prin raportarea numărului de secunde din minutul curent.

Am ascuns toată munca cu matrice și sesiuni în cadrul claselor, iar codul final pare simplu și frumos.

Creați un director pe serverul dvs. web, apoi creați aceste trei fișiere în el și încercați scriptul. Vă rugăm să rețineți că nu există probleme cu butoanele Înapoi și Reîmprospătare.

Acum imaginați-vă că creați un portal complex, unde, de regulă, există mai multe blocuri pe pagini și fiecare poate conține o aplicație separată.

Aici întâmpinăm două dificultăți:

* Aș dori ca lista de mesaje să apară într-o anumită parte a paginii și ați găsit deja un loc bun pentru aceasta.
Problema este că trebuie să rulați comanda $inbox->toPage() exact în momentul în care ar corespunde poziției listei de mesaje de pe pagină. Dacă vrem să schimbăm poziția acestei liste, va trebui să intrăm în cod, dar nu este bine să schimbăm constant cadrul portalului pentru asta. Cea mai bună soluție ar fi să faceți ieșirea mesajelor sub forma unui modul separat, despre care știm doar că trebuie conectat la cadru.
Adică, eliberează-te de secvența strictă de lansare a modulelor. Într-adevăr, din moment ce rezultatul ieșirii Inbox nu depinde de funcționarea sistemului (la acest pas avem deja toate datele din sesiune), atunci de ce mai multă complexitate?
* Pentru a menține aspectul (designul) listei de mesaje, trebuie să aveți grijă de codul HTML, care este codificat în metodele toPage() din clasele Message și Inbox. De obicei, va trebui să schimbați codul PHP pentru a schimba designul.

Pentru a încerca să rezolvați prima problemă, puteți crea un buffer care stochează rezultatul ieșirii Inbox.

Poate că vom avea în continuare câteva lucruri similare (cu Inbox) și trebuie să creăm un sistem tampon. Pentru a nu confunda a cui ieșire este a cui, probabil că vom ajunge la denumirea tampoanelor. Vom stoca undeva secvența în conformitate cu care ar trebui să fie scoase bufferele - de preferință într-un fișier extern pentru a face modificările mai ușoare.

Această încercare de soluție ne dă deja ideea de a folosi XML ca mijloc de stocare a datelor intermediare. Și utilizarea stilurilor XSLT va ajuta la rezolvarea celei de-a doua probleme.

Nu mă voi opri asupra ce este XML și ce este XSLT. Dacă nu sunteți familiarizat cu aceste lucruri, zvon.org este un loc bun pentru a începe să căutați.

Ideea este de a genera nu cod HTML, ci o structură XML în metodele toPage(). Documentul de pagină va fi creat sub formă de șir cu cod XML (va servi drept „buffer”), iar în ultima etapă a scriptului vom folosi o transformare XSL.

În primul rând, să ne imaginăm care ar trebui să fie rezultatul părții principale a codului.

minut 57 secunde: 45

Ce este este destul de ușor de ghicit - două mesaje și un formular. Vă rugăm să rețineți că scriptul PHP trebuie doar să pregătească un astfel de șir - este foarte simplu. Mai mult, ordinea etichetelor principale nu este importantă - le puteți pune la început, de exemplu, așa cum va fi convenabil pentru programator. Cum să o implementezi. Puteți, fără a schimba nimic, să utilizați bufferingul de ieșire, să scoateți XML în loc de cod HTML și, la sfârșit, pur și simplu să capturați rezultatul într-un șir. Dar atunci vom pierde flexibilitatea - de exemplu, uneori doriți să scoateți informații de depanare direct în pagină (folosind echo). În același timp, dezvoltatorii PHP lucrează la un modul DOM care oferă o modalitate mai avansată de a crea și transmite documente arborescente. Dacă dorim să implementăm DOM-ul, va trebui să reproiectăm întreaga aplicație, schimbând ieșirea șirurilor de caractere la crearea elementelor DOM. Prin urmare, prefer să stochez reprezentarea XML a obiectelor în cadrul obiectelor în sine, asamblarea secvenţială a unui document XML comun. Nu este atât de dificil, trebuie doar o mică modificare. Veți vedea că această tehnică nu este strict legată de un mod specific de stocare a datelor XML și acest lucru vă va permite să faceți tranziția la utilizarea DOM cu puțin efort. În primul rând, observați că fiecare dintre obiectele noastre are o metodă toPage(). Această asemănare ar trebui să ne facă să ne gândim la introducerea unei noi clase părinte comune. Lăsați fiecare clasă care poate crea bucăți dintr-un document XML pentru o pagină să moștenească de la o clasă care se va ocupa de reprezentarea XML a obiectului. Să-i spunem Outputable.

class Outputable ( /** * container XML (șir). */ var $output = ""; /** * Dați conținutul containerului și ștergeți containerul. * * @return un șir cu date XML */ function getOutput () ( $ out = $this->output; $this->output = ""; return $out; ) /** * Adăugați o porțiune la conținutul containerului. * * @param șirul șirul de adăugat * / function appendOutput($string) ( $this ->output .= $string . "n"; ) /** * Metoda "Abstract". */ function toPage() ( ) )

Metoda toPage() este goală - în acest caz este necesară ca indicator al modului în care clasele externe „matryoshka” ar trebui să comunice cu clasa interioară. Totuși, am putea oferi o implementare implicită aici dacă am observa că există multe obiecte care se afișează pe pagină în același mod.

Clasele Message și Inbox se vor schimba ușor - acum ar trebui să moștenească ambele de la Outputable, iar metodele toPage() se vor schimba, de asemenea
Mesaj.php

clasa Mesaj extinde Ieșire ( /** * Conținutul mesajului. */ var $conținut; /** * Constructor pentru inițializarea textului mesajului. * * Conținutul mesajului @param */ function Message($conținut) ( $this->conținut = $conținut; ) /** * Scrieți un mesaj în sesiune. */ function send() ( $_SESSION["session_messages"] = $this->content; ) /** * Trimiteți un mesaj către pagină. * / function toPage() ( $this->appendOutput("".$this->content.""); ) )

clasa Inbox se extinde Outputable ( /** * Matrice de mesaje primite. */ var $messages = array(); /** * În constructor, primim toate mesajele primite * și le eliminăm din sesiune. */ function Inbox( ) ( dacă (este_matrice ($_SESSION[„mesaje_sesiune”))) ( $mesaje = $_SESSION[„mesaje_sesiune”]; $co = dimensiunea($mesaje); pentru ($i = 0; $i< $co; $i++) { $this->mesaje = mesaj nou($mesaje[$i]); ) ) /* șterge tabloul de mesaje */ $_SESSION["session_messages"] = array(); ) /** * Afișează conținutul căsuței primite pe pagină. */ function toPage() ( $co = sizeof($this->mesaje); $this->appendOutput(""); pentru ($i = 0; $i< $co; $i++) { $this->mesaje[$i]->toPage(); $this->appendOutput($this->mesaje[$i]->getOutput()); ) $this->appendOutput(""); ) )

Metoda de ieșire s-a schimbat - acum, în loc să iasă direct pe pagină, reprezentarea externă este pentru moment stocată în Outputable, care „se află” în fiecare dintre obiecte. Metoda appendOutput() servește ca înlocuitor pentru construcția echo(). Pentru a obține rezultatul unui obiect, se folosește metoda getOutput().

Acum să vedem care este partea client a codului, care va rezolva aceeași problemă ca înainte.
index.php

Principala inovație este în obiectul $global_content, al cărui nume vorbește de la sine. În acest caz, aparține clasei Outputable; în sarcinile din viața reală, probabil ați crea o clasă separată pentru conținutul paginii.

Dacă te uiți cu atenție, conținutul scriptului practic nu s-a schimbat - aceeași căsuță de e-mail, aceeași toPage(). S-a adăugat o instrucțiune care afișează conținutul listei de mesaje în conținutul paginii. Pentru varietate, acum sunt generate două mesaje.

Pentru a vedea rezultatul, nu mai rămâne decât să pregătiți șablonul XSL.
stil.xsl

Exemplu XSLT

mesaj

Ce am realizat?

În primul rând, puteți prelua cu mai multă încredere proiecte complexe - este asigurată independența reală a modulelor. Ordinea în care rezultatele sunt plasate pe pagină este acum controlată folosind un șablon XSL extern și nu depinde de ordinea în care sunt rulate modulele.

Orice modul care generează date XML ca urmare a activității sale poate fi utilizat într-un proiect. Apropo, acesta este unul dintre avantajele față de motoarele de șablon, în care crearea datelor constă într-o secvență de metode de apelare (atribuire etc.) a unui motor specific, pentru care nu există un standard comun.

Un alt avantaj este ușurința de depanare. Dacă rulați scriptul, veți observa că fiecare pagină conține rezultate de depanare - un prototip XML care simplifică foarte mult aplicațiile de depanare.

Altceva la care trebuie să te gândești este cum să creezi obiecte de mesaj. Nu este întotdeauna convenabil să utilizați nou direct în codul clientului. Dar poate că acesta este un subiect pentru un articol separat.

În sfârșit, un galop despre perspective:

* ferestre pop-up pentru o listă de mesaje importante
* „pagini de expeditor” și „pagini de destinație” în mesaje
* înregistrarea mesajelor în baza de date
* buton „afișează istoricul acțiunilor mele”
* analiza statistică a acțiunilor utilizatorilor în cadrul sesiunilor
* „asistenți inteligenți” în aplicații web

Prezentare generală

Sistemul de notificare încorporat, primul în Joomla, permite aplicației dvs. să țină utilizatorul (sau grupul de utilizatori) informat despre diferite evenimente diferite. Gândiți-vă la notificări ca alerte importante pe care utilizatorul ar fi interesat să le citească și să le țină evidența.
Notificările pot fi generate peste tot. În componenta sau pluginurile dvs. și ulterior afișate în sistemul de notificare JomSocial.
Acest tutorial vă va arăta cum, dar din moment ce nu avem idee despre vreo componentă terță parte am putea folosi:) exemplele vor fi făcute pe un plugin comunitar care va fi declanșat la evenimentul onAfterProfileUpdate
Dacă nu știți cum să creați un plugin care va fi declanșat la acest eveniment, vă sugerăm să verificați acest ghid

Implementând-o oricum în componenta ta

După cum sa menționat în prezentarea generală a acestui tutorial, vom genera notificări folosind pluginul comunității.
Cel mai probabil veți dori să creați notificări în interiorul componentei dvs. sau al pluginului dvs. Următorul tutorial va funcționa în oricare dintre aceste cazuri. Trebuie doar să determinați în ce moment din codul dvs. va fi creată notificarea și să încărcați fișierul JomSocial Core Libraries.

require_once JPATH_ROOT . „/components/com_community/libraries/core.php” ;

Urmând tutorialul explicat mai jos va funcționa foarte bine și pentru extensia dvs

Pregătirea mediului de dezvoltare

1. Vom presupune că ați creat deja un exemplu de plugin de tip comunitate care va fi declanșat atunci când utilizatorul își schimbă profilul
Dacă nu, puteți descărca un exemplu de plugin gol din , îl puteți instala în Joomla și activați pluginul. Este numit Comunitate - Exemplu de notificări
2. Navigați la baza de date și goliți aceste două tabele, astfel încât să nu aibă deloc înregistrări

A) prefix_community_notification
b) prefix_community_mailq

3. Aveți cel puțin doi (2) utilizatori pe site-urile dvs. de testare și cunoașteți-le ID-urile

În versiunile anterioare de Joomla, ID-urile utilizatorului au început întotdeauna de la numărul specificat (62, 42). În Joomla 3, acest număr va fi aleatoriu, deci, imaginea mediului nostru de testare, deoarece va fi cu siguranță diferită la sfârșitul tău.

Prima Notificare

Deschideți fișierul php plugin care va fi localizat în ROOT/plugins/community/example
În cadrul funcției onAfterProfileUpdate() înlocuiți

CNotificationLibrary::add ( $cmd , $actor , $target , $subject , $body , $template , $params ) ;

După cum se arată în exemplu, notificarea add api are 7 parametri

  • $cmd - este tipul de notificare. Puteți vedea toate tipurile de notificări în acest fișier. ROOT/components/com_community/libraries/notificationtypes.php începând de la sau în jurul liniei 53. Vă recomandăm să utilizați tipul de notificare system_messaging.
  • $actor - este persoana care desfășoară acțiunea
  • $target - este persoana sau grupul de persoane care va primi notificarea
  • $subject - este subiectul notificării, atât în ​​fereastra pop-up de notificare, cât și în titlul e-mailului
  • $body - este corpul mesajului de notificare prin e-mail
  • $template - dacă aveți nevoie de un șablon specific de utilizat, îl puteți defini aici. În caz contrar, acest parametru poate fi gol
  • $params - parametri personalizați
  • Știind toate acestea, să definim variabilele pe care le vom folosi
    Schimbați codul pluginului în:

    $user = CFactory::getUser(); $cmd = "mesaj_sistem" ; // primul param, tip de activitate $actor = $user -> id ; //al doilea parametru - obțineți id-ul lui $actor $țintă = "965" ; // al treilea param. Cine primește notificarea? În mediul nostru de dezvoltare, utilizatorul său administrator cu id 965. În mediul dvs., cel mai probabil veți dori să obțineți ID-ul de la obiectul dvs. sau de la o serie de utilizatori. $subject = "Subiect de notificare" ; // Subiectul ambelor, notificări prin e-mail și pop-up $body = ; //Mesajul corporal în e-mailuri. $șablon = "" ; // Dacă trebuie să utilizați un anumit fișier șablon jomsocial, îl puteți defini aici. $params = new CParameter("" ); // Dorim să creăm un obiect params suplimentar și să îi atribuim date, fără a fi nevoie să definim în mod formal o clasă CNotificationLibrary:: add ( $cmd , $actor , $target , $subject , $body , $template , $params ) ;

    Acum conectați-vă cu orice utilizator și modificați informațiile de profil. Să mergem la baza de date să vedem ce s-a întâmplat.
    Navigați la tabelul prefix_community_notifications și observați noua înregistrare

    Navigați la tabelul prefix_community_mailq și vedeți noua înregistrare

    Felicitări! - Ați creat cu succes prima notificare proprie, care a fost trimisă prin e-mail și prin sistemul intern de notificare JomSocial


    Cod potențial Balonare

    Exemplul de mai sus este în regulă și funcționează, dar în general nu este recomandat să îl utilizați așa. În schimb, ar putea fi scris așa

    $actor = CFactory::getUser(); $params = new CParameter("" ); CNotificationLibrary:: add ( "system_messaging" , $actor -> "Acesta este mesajul corpului de notificare" , "" , $params ) ;

    Acest lucru este mult mai curat și mai ușor de urmărit, în timp ce practic face absolut același lucru ca un cod afișat mai sus.

    Parametri de notificare personalizați

    Un API de notificare poate fi extins cu orice parametru pe care doriți să îl adăugați.
    Acești parametri pot fi transferați fie la șablonul de e-mail, la notificare și, desigur, la fișierul de limbă.

    $actor = CFactory::getUser(); $link = "http://www.google.com" ; $params = new CParameter("" ); $params -> set ("actor" , $actor -> getDisplayName () ); // poate fi folosit ca tag (actor) $params -> set ("actor_url" , "index.php?option=com_community&view=profile&userid=" . $actor -> id ) ; // Link pentru eticheta (actor) $params -> set ("url" , $link ) ; //url-ul întregii activități. Folosit atunci când treceți cu mouse-ul peste avatar în fereastra de notificare. Poate fi folosit ca etichetă (url) și în e-mailurile trimise. Asigurați-vă că ați definit variabila $link:) CNotificationLibrary:: add ( "system_messaging" , $actor -> id , "965" , "Subiectul notificării" , "Acesta este mesajul corpului de notificare" , "" , $params ) ;

    • $params = nou CParameter( ); - Vrem să creăm un nou obiect params și să îi atribuim date, fără a fi nevoie să definim în mod formal o clasă.
    • $params->set("actor", $actor->getDisplayName()); - Notificarea dvs. ar trebui să aibă întotdeauna un actor. Acest parametru poate fi transmis șablonului ca etichetă (actor). În fereastra de notificare, definește utilizatorul care efectuează o acțiune.
    • $params->set("actor_url", "index.php?option=com_community&view=profile&userid=" . $actor->id); - Adresa URL a actorului este de obicei adresa URL a unui actor. În fereastra pop-up de notificare, adaugă linkul la elementul (actor).
    • $params->set("url", $link); - Acesta este cel mai important parametru pe care trebuie să îl setați întotdeauna corect. În fereastra de notificare, acest parametru este utilizat peste imaginea avatarului. În notificarea prin e-mail, ecou locația în care a avut loc activitatea.

    Pentru acest exemplu, vom seta variabila $link la aterizează pe www.google.com ca sa vezi cum functioneaza

    Adăugarea șirului de limbă și utilizarea parametrilor

    Având parametrii pe care tocmai i-am setat sunt disponibili pentru a fi utilizați și în fișierele noastre de limbă.
    Să definim cheile de limbă prin modificarea „ CNotificationLibrary::add() API

    CNotificationLibrary::add("system_messaging" , $actor -> id , "965" , JText::sprintf("PLG_COMMUNITY_EXAMPLE_SUBJECT") , JText::sprintf("PLG_COMMUNITY_EXAMPLE_BODY" ) ; $para, ") ;

    Fișierul de limbă ar trebui să arate așa

    PLG_COMMUNITY_EXAMPLE_SUBJECT = "Profil actualizat (actor)" PLG_COMMUNITY_EXAMPLE_BODY = "Bună administrator \n Acesta este e-mailul pentru a vă informa că profilul actualizat (actor) \n\n Dacă doriți să accesați Google, faceți clic aici \n a href=" _QQ_" (url)"_QQ_">(url)"

    În acest exemplu, am folosit eticheta (actor) și (url) pentru a transmite datele ambelor șabloane de notificare și de e-mail. Să vedem cum arată.
    În fereastra de notificare, când treceți cu mouse-ul peste avatar, observați că parametrul (url) este activat și adaugă linkul către Google peste avatar. Este intenționat, pentru că așa am procedat:)


    ]

    În aceeași fereastră, când treci cu mouse-ul peste linkul actorului. Aceasta este partea în care (actor) a făcut ecou utilizatorul care efectuează o acțiune, în timp ce (actor_url)" a avut grijă ca obiectul să fie conectat corect


    Să vedem ce se întâmplă în coada de e-mail


    Și, în sfârșit, e-mailul propriu-zis care este trimis utilizatorului final


    Succes
    Până acum, am creat trei (3) parametri care sunt utilizați cu succes în fereastra de notificare și e-mailuri.

  • (actor) - Returnează numele de utilizator al utilizatorului care efectuează acțiunea
  • (actor_url) - Oferă atribuirea (actorului)
  • (url) - Nu este obligatoriu, dar ar trebui să îl aveți întotdeauna în notificare. Este adresa URL principală în care sa întâmplat acțiunea despre care suntem notificați.
  • În mod similar, puteți defini „

    • (țintă) - dacă aveți nevoie
    • (target_url) dacă aveți nevoie de el în notificare.
    • (titlu) - Folosit în mod obișnuit pentru a se referi la un obiect care a generat notificare. Exemplu: „Utilizatorul X a postat o fotografie nouă în Albumul Y”. Albumul Y este titlul aici
    • (title_url) - Ca și în cazul celor anterioare, adresa URL a unui obiect care a generat notificarea.
    • (mesaj) - Acest parametru poate fi folosit pentru a seta (și a economisi) mesajul în corpul e-mailului JomSocial.

    În cele din urmă, mi-am dat seama: nu poți găsi pe nimeni mai bun decât soția ta. Tot ce mai rămâne este să-ți găsești o soție

    PHP AJAX CRUD: crearea, ștergerea, editarea înregistrărilor în baza de date MySQL

    În acest articol, vom afla cum să adăugați, editați și ștergeți înregistrări într-o bază de date MySQL folosind PHP. Am folosit un handler JQuery care trimite o solicitare AJAX unui script de pe partea serverului. Managerul actualizează lista de înregistrări.

    Formular AJAX pentru trimiterea cererilor de creare, ștergere, editare

    Când adăugați o înregistrare, formularul trimite date către script-ul PHP printr-o solicitare AJAX. Dacă adăugarea are succes, lista de intrări este reîncărcată.

    Funcții JQuery AJAX pentru interogarea bazei de date CRUD

    În funcția JQuery AJAX avem cazuri de comutare, adăugare, editare și ștergere. Aceste cazuri generează diferite șiruri de date de interogare și răspuns în funcție de acțiunile bazei de date.

    funcția showEditBox(id) ( $("#frmAdd").hide(); var currentMessage = $("#message_" + id + " .message-content").html(); var editMarkUp = ""+currentMessage+" SaveCancel"; $("#message_" + id + " .message-content").html(editMarkUp); ) function cancelEdit(message,id) ( $("#message_" + id + " .message-content") .html(mesaj); $("#frmAdd").show(); ) function callCrudAction(action,id) ( $("#loaderIcon").show(); var queryString; switch(action) (case "adăugați" ": queryString = "action="+action+"&txtmessage="+ $("#txtmessage").val(); break; case "edit": queryString = "action="+action+"&message_id="+ id + " &txtmessage="+ $("#txtmessage_"+id).val(); break; case "delete": queryString = "action="+action+"&message_id="+ id; break; ) jQuery.ajax(( url: "crud_action.php", data:queryString, tip: "POST", success:function(data)( switch(action) (case "add": $("#comment-list-box").append(data); break; case "editare": $("#message_" + id + ".message-content").html(date); $("#frmAdd").show(); pauză; caz "șterge": $("#message_"+id).fadeOut(); pauză; ) $("#txtmessage").val(""); $("#loaderIcon").hide(); ), eroare:funcție ()() )); )

    Script PHP pentru operațiuni CRUD

    Următorul cod efectuează interogări în baza de date. Acest script PHP, după efectuarea unei acțiuni CRUD, actualizează înregistrările ca urmare a răspunsului AJAX.

    require_once("dbcontroller.php"); $db_handle = nou DBController(); $acțiune = $_POST[„acțiune”]; if(!empty($action)) ( switch($action) (case "adăugați": $rezult = mysql_query ("INSERT INTO comment(mesage) VALUES("".$_POST["txtmessage"].")" ) ; if($rezultat)($insert_id = mysql_insert_id(); echo " Edit Delete " . $_POST["txtmessage"] . " "; ) break; case "edit": $result = mysql_query("UPDATE comment set message = "".$_POST["txtmessage"]."" WHERE id=".$_POST["message_id"]); if($result) echo $_POST["txtmessage"]; break; case "delete": if ( !empty($_POST["message_id"])) ( mysql_query("DELETE FROM comment WHERE id=".$_POST["message_id"]); ) break; ) )

    În aplicația mea Zend, scriu un pic de API pentru aplicații mobile. Pentru a le ușura dezvoltatorilor de telefonie mobilă, folosesc Swagger. Până acum totul funcționează bine, cu excepția unei cereri GET.

    Când apelez /user/messages/(sessionToken)? NumMessages = (numMessages) & pageNr = (pageNr) în browser, obțin rezultatele pe care le doresc, dar când încerc să-l las pe Swagger să execute această solicitare, este transmis doar sessionToken-ul. Am încercat aceste adnotări pentru Swagger:

    /** * @SWG\Api(path="/user/messages/(sessionToken)?numMessages=(numMessages)&pageNr=(pageNr)", * @SWG\Operation(* method="GET", * summary=" Primește mesajele paginate", * notes="", * type="string", * nickname="getUsermessagesPaged", * autorizații=(), * @SWG\Parameter(* name="sessionToken", * description="The token dintr-o sesiune de utilizator activă", * required=true, * type="string", * paramType="path", * allowMultiple=true *), * @SWG\Parameter(* name="numMessages", * description=" numărul de mesaje de pe pagină (numMessages și pageNr sunt ignorate dacă nu sunt setate ambele)", * required=true, * type="string", * paramType="query", * allowMultiple=true *), * @SWG\Parameter (* name="pageNr", * description="pagenumber (numMessages și pageNr sunt ignorate dacă nu sunt setate ambele)", * required=true, * type="string", * paramType="query", * allowMultiple=true *), * @SWG\ResponseMessage(code=200, message="json (messages => "user_messages")"), * @SWG\ResponseMessage(code=400, message="json cu eroare "not logged"" ) *) *) */

    Vede cineva greșeala mea?

    Orice ajutor este binevenit.

    Cu sinceritate

    Actualizați. După cum am sugerat, am schimbat ambele paramTypes în „interogare” și am schimbat calea:

    @SWG\Api(path="/user/messages/(sessionToken)",

    dar nu a lucrat ca luptător.

    xdebug în eclipse PDT arată:

    RequestURI => /ias/public/user/messages/(sessionToken)

    QueryParams => Zend\\Stdlib\\Parameters - *ArrayObject*storage => Array - =>

    smecher JSON:

    ( „apiVersion”: „1.0.0”, „swaggerVersion”: „1.2”, „apis”: [ ( „cale”: „\/utilizator”, „descriere”: „Operațiuni despre utilizatori” ) ], „informații” : ( „titlu”: „API de acces mobil”, „descriere”: „Acesta este API-ul de acces mobil xxx”, „termsOfServiceUrl”: null, „contact”: „xxx”, „licență”: nul, „licenseUrl” : null, „_partialId”: null, „_partials”: ​​, „_context”: ( „comentar”: „\/**\ * @SWG\\Info(\ * title="Mobile access API)",\ * description="This is the xxx mobile access api.",\ * contact="xxx",\ *)\ *\/", "line": 3 } } } !}

    Iată rezultatul /user:

    ( „basePath”: „http://localhost/ias/public”, „swaggerVersion”: „1.2”, „apiVersion”: „1.0.0”, „resourcePath”: „/user”, „apis”: [ ( „cale”: „/user/balance/(sessionToken)”, „operații”: [ ( „metodă”: „GET”, „rezumat”: „Obține soldul utilizatorului”, „nickname”: „getUserdata”, „type”: „șir”, „parametri”: [ ( „paramType”: „cale”, „nume”: „sessionToken”, „type”: „șir”, „obligatoriu”: adevărat, „allowMultiple”: fals, „descriere”: „Jetonul dintr-o sesiune de utilizator activă” ) ], „responseMessages”: [ ( „cod”: 200, „mesaj”: „json (balance => „user_balance”)” ), ( „cod”: 400, „mesaj” ": "json cu eroare "nu a fost conectat"" ) ], "note": "", "autorizări": () ) ]), ( "cale": "/utilizator/login", "operații": [ ( „method”: „POST”, „summary”: „Conectează utilizatorul în sistem”, „nickname”: „loginUser”, „type”: „șir”, „parametri”: [ ( „paramType”: „form”, „nume”: „e-mail”, „tip”: „șir”, „obligatoriu”: adevărat, „allowMultiple”: fals, „descriere”: „E-mailul utilizatorului pentru conectare” ), ( „paramType”: „form”, „nume”: „parolă”, „tip”: „șir”, „obligatoriu”: adevărat, „allowMultiple”: fals, „descriere”: „Parola pentru autentificare în text clar” ) ], „responseMessages”: [ ( „code”: 200, „message”: „json cu session_id, user_id, user_balance” ), ( „cod”: 400, „message”: „json cu eroare „niciun utilizator cu adresa de e-mail și parolă”” ), ( „ cod": 400, "mesaj": „json cu eroare „intrare nevalidă”” ), ( „cod”: 400, „mesaj”: „json cu eroare „fără cerere de postare”” ) ], „note”: „” , „autorizări”: () ) ] ), ( „cale”: „/utilizator/logout”, „operații”: [ ( „metodă”: „POST”, „rezumat”: „Deconectați utilizatorul”, „poreclă” : „logoutUser”, „type”: „șir”, „parametri”: [ ( „paramType”: „form”, „nume”: „sessionToken”, „type”: „șir”, „obligatoriu”: adevărat, „ allowMultiple": false, "description": "Jetonul dintr-o sesiune de utilizator activă" ) ], "responseMessages": [ ( "cod": 200, "message": "json (rezultat => "șters")" ), ( „cod”: 400, „mesaj”: „json cu eroare „fără sesiune de utilizator cu sid dat”” ), ( „cod”: 400, „mesaj”: „json cu eroare „intrare nevalidă”” ), ( „cod” „: 400, „message”: „json cu eroare „no post request”” ) ], „note”: „”, „autorizări”: () ) ]), ( „cale”: „/user/messages/( sessionToken)", „operații”: [ ( „metodă”: „GET”, „rezumat”: „Primește mesaje noi”, „nickname”: „getUsermessages”, „type”: „șir”, „parametri”: [ ( „paramType”: „cale”, „name”: „sessionToken”, „type”: „șir”, „required”: true, „allowMultiple”: false, „description”: „Jetonul dintr-o sesiune de utilizator activă” ) ], „responseMessages”: [ ( „cod”: 200, „message”: „json (mesaje => „mesaje_utilizator”)” ), ( „cod”: 400, „message”: „json cu eroare „nu a fost conectat” „” ) ], „note”: „”, „autorizări”: () ), ( „metodă”: „GET”, „rezumat”: „Primește paginarea mesajelor”, „nickname”: „getUsermessagesPaged”, „type” : „șir”, „parametri”: [ ( „paramType”: „cale”, „nume”: „sessionToken”, „type”: „șir”, „obligatoriu”: adevărat, „descriere”: „Jetonul dintr-un sesiune utilizator activă" ), ( "paramType": "interogare", "nume": "numMessages", "type": "string", "required": true, "description": "numărul de mesaje de pe pagină (numMessages & pageNr sunt ignorate dacă nu sunt setate ambele)" ), ( "paramType": "query", "name": "pageNr", "type": "string", "required": true, "description": "pagenumber ( numMessages și pageNr sunt ignorate dacă nu sunt setate ambele)" ) ], "responseMessages": [ ( "cod": 200, "message": "json (messages => "user_messages")" ), ( "cod": 400 , „mesaj”: „json cu eroare „nu a fost conectat”” ) ], „note”: „”, „autorizări”: () ) ]), ( „cale”: „/user/userdata”, „operații” : [ ( „metodă”: „POST”, „rezumat”: „Postează datele utilizatorului”, „nickname”: „postUserdata”, „type”: „șir”, „parametri”: [ ( „paramType”: „form”, „name”: „sessionToken”, „type”: „șir”, „required”: true, „allowMultiple”: false, „description”: „Jetonul dintr-o sesiune de utilizator activă” ), ( „paramType”: „form „, „nume”: „parolă”, „tip”: „șir”, „obligatoriu”: fals, „allowMultiple”: fals, „descriere”: „parolă nouă” ), ( „paramType”: „form”, „ nume": „adresă”, „tip”: „șir”, „obligatoriu”: fals, „allowMultiple”: fals, „descriere”: „adresă nouă” ), ( „paramType”: „form”, „nume”: „housenr”, „type”: „șir”, „required”: false, „allowMultiple”: false, „description”: „new housenr” ), ( „paramType”: „form”, „name”: „zip” , „type”: „șir”, „obligatoriu”: fals, „allowMultiple”: fals, „descriere”: „zip nou” ), ( „paramType”: „form”, „nume”: „oraș”, „tip „: „șir”, „obligatoriu”: fals, „allowMultiple”: fals, „descriere”: „oraș nou” ), ( „paramType”: „form”, „nume”: „e-mail”, „tip”: „ șir”, „obligatoriu”: fals, „allowMultiple”: fals, „descriere”: „e-mail nou” ) ], „responseMessages”: [ ( „cod”: 200, „mesaj”: „json (utilizator => „date utilizator” ")" ), ( "cod": 400, "mesaj": "json cu eroare

    Pare o eroare că swagger-ui-ul meu nu trimite niciun parametri de solicitare? Iată un exemplu cu un parametru de interogare, sessionToken: (controlat de FireBug 2.0.6)

    GET /ias/public/user/balance HTTP/1.1 Gazdă: localhost User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: application/json Accept-Language: de, en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/json Referer: http://localhost/ias/swagger/ Cookie: __utma=111872281.581414660.13667006727.1873.1873.1873.183. uvts=sB5Dda3cZBNdaTk; searchpanel-close=set Conexiune: păstrează-o

    Raspunsul a fost:

    HTTP/1.1 400 Data solicitării greșite: marți, 25 noiembrie 2014 14:58:20 GMT Server: Apache/2.4.9 (Win32) PHP/5.5.12 X-Powered-By: PHP/5.5.12 Lungime conținut: 25 Conexiune: close Content-Type: application/json; set de caractere=utf-8

    Răspunsul a fost corect deoarece nu a fost transmis niciun sessionToken.

    Acest lucru necesită muncă, dar nu vine de la swagger-ui:

    GET /ias/public/user/balance?sessionToken=HTTP/1.1 Gazdă: localhost User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: text/html,application/ xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Cookie: __utma=111872281.581414660 .1366700677.1394721873.1394723866.255; uvts=sB5Dda3cZBNdaTk; searchpanel-close=set Conexiune: păstrează-o