Cum puteți utiliza diagramele de stat pentru a vă face un coder Web mai bun

Un instrument care ar trebui să fie în arsenalul dvs. de codificare web este diagrama de stare. O diagramă de stare arată diferitele "stări" (reacții) pe care aplicația dvs. (de exemplu, site-ul web) le poate conține, precum și ce acțiuni sau intrări (de la utilizator) sunt necesare pentru a ajunge la o anumită stare. O diagramă de stare vă ajută să realizați în minte toate interacțiunile posibile între utilizatori și aplicații. Acest lucru crește șansele ca cel puțin să luați în considerare codarea pentru toate posibilitățile, pentru că acum le cunoașteți pe toate - ceea ce reduce șansele de a avea cod de buggy sau mai rău, ați uitat să vă ocupați de funcționalitatea specifică.

De ce să utilizați o diagramă de stat?

O schemă de stare constă din două componente: cercurile pentru a reprezenta stările (reacțiile / ieșirile aplicației) și săgețile pentru a reprezenta tranzițiile (acțiunile utilizatorului / intrarea). Diagramele de stare sunt foarte utile pentru aplicațiile complexe și nu atât de complexe, de orice tip. Cu toate acestea, atunci când vine vorba de dezvoltarea site-ului, diagramele de stare nu sunt întotdeauna de folos:

1. Dacă aveți un site web static, în care navigarea garantează că fiecare pagină se leagă de fiecare pagină, atunci o diagramă de stare este redundantă. (În sfera matematicii numită Teoria grafurilor, această situație este cunoscută ca un "grafic complet conectat". Un grafic este un set de margini și noduri - adică tranziții și stări.)
2. Dacă aveți un site dinamic care rulează pe un CMS (Content Management System) - care include platforme de bloguri - atunci atât de multe dintre tranzițiile de stat sunt deja codate pe site-ul dvs. Deci, încă o dată, o diagramă de stare nu este de mare folos.

Pe de altă parte, dacă construiți un site web unde trebuie să se ocupe de tranziții speciale, atunci o diagrama de stare poate fi de mare folos:

1. Manipularea intrărilor speciale ale utilizatorilor, în cazul în care ele selectează decizia următoarei stări. (De exemplu, formulare sau meniuri care au listele drop-down sau dinamice.)
2. Site-uri AJAX-y unde chiar și după o acțiune semnificativă de către utilizator, adresa URL nu se modifică. (Conținutul nu, adresa URL nu.)

Cum creați diagrame de stare?

Lucrul surprinzător este că diagramele de stat nu sunt toate complicate pentru a produce. Cu toate acestea, din experiența mea, ei nu sunt folosiți de tot de multe ori de majoritatea programatorilor, în ciuda beneficiilor (înțelegerea mai profundă a interacțiunilor utilizatorilor, coeziunea efortului de codificare). Jur pe ele - sau când am codat în fiecare zi în diferite locuri de muncă.

Se recomandă să faceți mai întâi diagrame de stare pe hârtie, apoi să le transferați pe o copie digitală dacă și numai dacă este necesar. (Există ceva despre tactilitatea de a schița relațiile de intrare / afișare pe hârtie, ceea ce le face mai concrete în mintea ta, făcând mai ușor să găzdui toate interacțiunile posibile și, astfel, să reduci bug-urile în aplicațiile tale).

O diagramă de stare constă din:

• Etichete cu linii săgeți pentru a afișa intrarea / acțiunea utilizatorului (tranziție).
• Cercuri marcate pentru a afișa afișarea conținutului rezultat (starea aplicației).
• Stare de start cu un cerc dublu-margine.
• Stările finale (dar nu și atunci când aplicația este bazată pe web.) Pentru mai multe explicații, vedeți mai jos.

Puteți vedea un exemplu simplu direct de mai jos - care va fi extins mai târziu în acest articol:

Iată pașii pentru crearea diagramelor de stare (cu aplicații orientate către aplicații bazate pe site):

1. Efectuați o listă a tuturor intrărilor posibile de către utilizatorul aplicației, din fiecare stat.
2. Desenați starea Start - un cerc dublu de margine etichetat cu "S". Cu un site web, starea de start este pagina de pornire și afișajul său implicit.
3. Desenați cercuri pentru o stare unică sau sub-stată unică. Pentru site-urile statice, fiecare pagină web este o stare separată. Dacă pentru aplicația dvs. web există substații diferite pentru aceeași adresă URL, atunci trebuie să desenați cercuri de stat separate.
4. Pentru fiecare acțiune posibilă din starea inițială, trageți săgețile etichetate (tranziții) în cercul următor al posibilei stări.
5. Repetați acest lucru din fiecare stare până când aveți o diagramă completă de stare pentru aplicație.
6. Nu uitați de tranzițiile circulare. De exemplu, dintr-o stare înapoi la ea însăși (posibil din cauza faptului că faceți dublu clic pe același link).
7. Tranzițiile repetitive dintr-un grup de state conexe pot fi reprezentate cu o formă scurtă, așa cum se va vorbi mai jos.
8. Diagramele de stare pentru aplicațiile non-Web au aproape întotdeauna o stare "End". Cu toate acestea, se spune că Web-ul este "apatrid", deoarece într-un browser web, fiecare stat este un stat final. Poți să faci o acțiune și să pleci sau să faci altă acțiune și atunci concediu etc. Deci, pentru aplicațiile web, nu este nevoie să desenați starea de sfârșit.

Pentru a extinde numărul # 7 de mai sus, rețineți că prin intermediul site-urilor web, s-ar putea să se repete acțiunile. De exemplu, dacă fiecare pagină include același meniu de navigare, nu este necesar să afișați acele tranziții mereu și repede și să agitați diagrama de stare. Doar reprezintă acțiuni grupate cu o notație / simbol de scurtă durată.

(Este mult mai ușor să înțelegi o diagrama de stare dacă tu ești persoana care o desenează, un pas la un moment dat Dacă ești o persoană care uită la o schemă de stare completă, ar putea fi intimidantă.De aceea, diagramele de stat trăiesc adesea doar pe hârtie - presupunând că le folosiți.

Cum se aplică diagramele de stat aplicațiilor bazate pe site-uri web?

Pentru un site web care utilizează Nu Funcțiile AJAX-y (adică orice caracteristică în care adresa URL nu se modifică), o diagramă de stare este destul de ușor de produs, dar în general inutilă. De exemplu, un site web static în care fiecare pagină este conectată la fiecare altă pagină are ca rezultat o diagramă de stare care uneori este denumită grafic "complet conectat". Astfel de diagrame de stare sunt de obicei inutile, pentru că nu există o manevrabilitate specială de vizualizare. Fiecare stat este conectat la orice alt stat)

În cazul în care diagramele de stare sunt cele mai utile, este pentru site-urile dinamice - especiale cu AJAX-y caracteristici (cum ar fi meniurile drop, glisiere, acordeoane, galerii, etc). În acest din urmă caz, este posibil ca URL-ul din browser să nu se modifice, dar conținutul paginii se face parțial. Este mai greu să vizualizăm toate stările posibile și tranzițiile (acțiunile), deoarece o "pagină" poate avea mai multe sub-stări.

O diagramă de stare (sau un set de diagrame tot mai detaliate) vine foarte util în acest caz - mai ales dacă există o echipă de coderi (și uneori designeri) care să lucreze cu.

Un exemplu de utilizare a diagramei de stat

Într-un tutorial viitoare vă voi arăta cum să codificați jQuery pentru două efecte pe care le folosesc în șablonul About Me. Pagina live are câteva erori CSS care trebuie mai întâi finisate. Aș dori, de asemenea, să adaug câteva caracteristici bazate pe jQuery dacă este suficient timp. Aceste caracteristici suplimentare vor face obiectul exemplului nostru.

În viitor, acest șablon se va transforma într-o temă gratuită WordPress destinată freelancerilor care doresc să-și prezinte experiența lor de lucru (concerte). Pentru moment, vreau să arăt cum diagramele de stare vă pot ajuta să înțelegeți cauza / reacțiile necesare (adică intrare / tranziții) pentru galeria "Current Gigs" văzută mai sus. Înțelegerea tranzițiilor necesare vă ajută să codificați cu mai multă încredere, iar codarea este independentă de limbă. Deci puteți decide biblioteca / limbajul de cod după crearea diagramei de stare.

Funcțiile dorite ale aplicației

Dacă vă uitați la galeria "Curiile actuale" în centrul din stânga imaginii de mai sus sau pe pagina live, veți vedea că acesta este, în esență, același concept ca și o galerie de imagini. Dați clic pe un link și vor apărea detalii despre acel "gig". Cu toate acestea, atunci când am construit pagina live, nu au existat tutoriale jQuery cu privire la modul de aruncare a textului în mix, pentru fiecare "cadru" al vitrinei. Trebuia să vină cu propriul meu cod.

Pentru a face acest lucru, a trebuit să înțeleg mai întâi toate interacțiunile posibile ale utilizatorilor. O diagramă de stare este ideală pentru acest lucru. Să mergem în față, totuși. Ceea ce am vrut cu adevărat este o zonă de prezentare care prezintă atât concerte curente, cât și concerte anterioare. Este un fel de C.V. (Curriculum Vitae, aka "resume"), care prezintă o galerie de experiență de lucru. Fiecare cadru al concertului conține o imagine a paginii de pornire a site-ului asociat, împreună cu un text care oferă detalii despre munca pe care am făcut-o sau o fac acolo.

Pentru moment, pagina are doar "Concursuri curente", dar ar trebui să aibă și "Concursuri anterioare". Iată o listă a cerințelor funcționale pentru ceea ce ar trebui să aibă zona de prezentare:

1. Interfața jQuery cu interfață, dar "invizibilă". În loc să utilizați filele obișnuite, utilizați mini-bannere asemănătoare graficului "Curente".
2. Atunci când se face clic pe o "filă" (Concursuri curente, Concursuri anterioare), se afișează lista corespunzătoare a concursului, împreună cu cadrul (detalii) primului element.
3. Afișajul implicit este "Concursuri curente".
4. Atunci când cineva face clic pe "Gigs Past", atunci lista de concerte trecute trebuie să apară, împreună cu cadrul detaliat al primului element din lista respectivă.
5. Liste de liste. Fiecare "filă" va furniza o listă de gigări poziționate spre stânga utilizând o grilă Blueprint CSS.
6. Elementele listei de mesaje vor fi linkuri text.
7. Fiecare vitrină va avea linkuri complet diferite (lucrare trecută și prezentă). Deci, o "experiență de lucru" poate apărea doar într-o vitrină la un moment dat.
8. Atunci când se face clic pe un element dintr-o listă de gigă, vor apărea detaliile "cadrului" gigului. Fiecare cadru va afișa un snap de ecran (salvat anterior) și descrierea asociată a postului. Cadrul de rețea Blueprint CSS va fi utilizat pentru a poziționa elementele vitrinei. (Nu este necesar, dar asta este scopul meu.)

Așadar, pentru a reitera, obiectivul este să aveți o interfață cu tab-uri, unde filele sunt etichetate "Concursuri curente" și "Concursuri anterioare". Acest lucru permite mai multe file mai târziu, limitată numai de lățimea fiecărei etichete și de lățimea spațiului de expunere (590 de pixeli). Dar vreau ca filele să fie "invizibile", așa cum am menționat. În loc de filele tipice dintr-o interfață tab, vreau să folosesc mini-bannere. Dacă te uiți la pagina de testare live, există un mini-banner etichetat "Concursuri curente" și un alt etichetat "Gigs Past". Acestea vor fi filele. Aici este un snap de ecran de aproape de ceea ce ar putea arata zona de prezentare finală, cu setările implicite.

Crearea diagramei de stat

Pentru a crea diagrama de stare, trebuie mai întâi să enumerăm fiecare stare, intrare și acțiune unică:

1. Stare de pornire: La încărcarea paginii de pornire:
   1. Ascundeți (nu afișați) toate cadrele GIG utilizând CSS.
   2. Prezentați prezentarea "Curente pentru concerte" ca implicită.
   3. În cadrul vitrării implicite, prezentați ca element implicit cadrul pentru primul element din lista gigant. Deci, ori de câte ori cineva face clic pe "Câmpurile curente", prezentarea se va reseta.
2. Posibile acțiuni generice din starea Start:
   
   1. Faceți clic pe "fila". Reacție / tranziție: redați afișajul corespunzător filei pe care ați făcut clic.
   2. Faceți clic pe un element de listă gigă. Reacția / tranziția: realizați cadrul corespunzător pentru elementul de concurs.
3. Posibile acțiuni generice din alte state: exact la fel. Suntem norocosi in acest caz, pentru ca acest lucru face diagrama de stat mult mai simpla.

Notă: În acest moment, ne ocupăm doar de ceea ce se întâmplă în C.V. casetă de prezentare. În diagrama de stare, nu ne pasă de acțiunile care afectează alte părți ale paginii web. Nu prezentăm decât acțiuni / reacții care afectează C.V. casetă de prezentare.

Iată o schemă de stare a eșantionului pentru funcționalitatea de mai sus.

Câteva note despre această diagramă:

1. În scopul acestei discuții, nu este atât de important ce este de fapt fiecare etichetă. Aici, fiecare reprezintă un site pe care îl scriu acum sau pentru care îl scriu.
2. Nu este atât de complicat cât pare. Concentrează-te doar pe o tranziție la un moment dat și va fi clar ce se întâmplă. [Aici, etichetele de acțiune sunt aceleași cu etichetele de stare. Acest lucru nu este întotdeauna cazul.] De obicei, este mult mai clară atunci când desenați diagrama, adăugând noi cercuri de stat și săgeți de tranziție una câte una.
3. Tranzițiile, numite acțiuni ale utilizatorilor, sunt reprezentate de săgeți etichetate. (În mod normal, etichetele ar fi text integral, nu formele scurte folosite aici).
4. Statele, reacții cunoscute, sunt reprezentate de cercuri. Starea de pornire este întotdeauna marcată cu un cerc dublu și un "S".
5. Formele scurte sunt utilizate pentru ambele tipuri de etichete, pentru a menține diagrama mai puțin aglomerată.
6. Stările și sub-stările sunt colorate pe baza faptului că acestea sunt primare sau secundare. De exemplu, albastrul reprezintă stările primare (și tranzițiile). Puteți trece de la starea Start la orice stare albastră cu un singur clic pe link-ul corespunzător. Nu puteți trece la o stare purpurie (secundară) de la Start fără a trece mai întâi printr-o stare primară.
7. Deoarece există o mulțime de tranziții repetitive (adică, de la orice element de concurs la altul), grupurile de tranziții sunt afișate cu una dintre săgețile grosate (plin albastru sau purpuriu). De exemplu, în timp ce vizualizați detaliile despre gigantul FF (FreelanceFolder), puteți să faceți clic pe oricare dintre elementele de concurs listate pentru prezentarea CG (Concursuri curente), inclusiv FF în sine. Sau puteți să faceți clic pe fila "CG" și să resetați prezentarea. Nu poți să te duci de la un cadru actual "gig" la un cadru "trecut" al gigului, și nici invers.
8. Săgeata albastră, conturată, include tranziții înapoi la starea implicită a CG. Săgeata purpuriu scurtă și conturată nu include tranzițiile înapoi la starea implicită a PG. (Asta pentru că acele tranziții sunt deja afișate explicit, nu pentru CG, deoarece diagrama ar fi prea aglomerată.)

Extinzând la punctul # 5 de mai sus, regulile de bază sunt că, dacă există mai multe tranziții repetitive dintr-un grup de state asociat, puteți adnota tranzițiile cu un fel de scurt formular. Pur și simplu doriți să obțineți un sentiment al tranzițiilor importante, astfel încât acestea să fie primii în mintea voastră. O altă abordare este să se ia o diagramă complexă și să se împartă în părți: prezentarea generală, apoi versiunile "explodate" ale clusterelor de tranziție.

De exemplu, diagrama de mai sus ar fi putut avea o diagramă de stare principală care conține nodurile S, CG și PG. Apoi vor exista două diagrame detaliate. Unul ar avea S, CG, și sub-state corespunzătoare reprezentând diverse concursuri. Cealaltă diagrama detaliată ar avea S, PG și sub-stările corespunzătoare gig.

Gândurile finale

În general, acum ar trebui să aveți o imagine mai clară despre modul în care funcționează secțiunea vitrină. Nu voi intra în modul de a trece de la o schemă de stare la un cod real. Acest lucru ar trebui să devină evident odată ce înțelegeți toate interacțiunile utilizatorilor. Diagramele de stare - și înțelegerea lor ar trebui să vă ajute să scrieți un cod mai coerent, reducând șansele unei aplicații buggy. Tehnica de codare nu se schimbă.