Hvordan bruke statlige diagrammer kan gjøre deg til en bedre Web Coder

Et verktøy som skal være i ditt webkodingsarsenal er statutediagrammet. Et tilstandsdiagram viser de forskjellige "tilstandene" (reaksjonene) som søknaden din (f.eks. Nettsted) kan være i, samt hvilken handling eller inngang (fra brukeren) er nødvendig for å komme til en bestemt tilstand. Et statsdiagram bidrar til å gjøre konkrete i tankene dine alle mulige bruker / applikasjonsinteraksjoner. Dette øker sjansene for at du i det minste vil vurdere koding for alle muligheter, bare fordi du nå kjenner dem alle - noe som reduserer sjansene for at du har buggy kode eller verre, glemte å håndtere spesifikke funksjoner.

Hvorfor bruk et statlig diagram?

Et tilstandsdiagram består av to komponenter: sirkler for å representere tilstander (applikasjonsreaksjoner / utgang) og piler for å representere overganger (brukerhandlinger / inngang). Statiske diagrammer er veldig nyttige for komplekse og ikke så komplekse dataprogrammer av noe slag. Men når det gjelder utvikling av nettsider, er statlige diagrammer ikke alltid i bruk:

1. Hvis du har en statisk nettside der navigasjonen garanterer at hver enkelt side kobler til hver annen side, er et statsdiagram overflødig. (I grenen av matematikk kalt grafteori, er denne situasjonen kjent som en "helkoblet graf". En graf er et sett med kanter og noder - dvs. overganger og tilstander.)
2. Hvis du har et dynamisk nettsted som kjører på et CMS (Content Management System) - som inkluderer bloggplattformer - så er så mye av overgangene til staten allerede kodet inn på nettstedet ditt. Så igjen er et statediagram ikke for mye bruk.

På den annen side, hvis du bygger et nettsted der du må håndtere spesielle overganger, kan et statediagram være til stor nytte:

1. Håndtering av spesiell brukerinngang, der det de velger, bestemmer neste tilstand. (For eksempel, skjemaer eller menyer som har rullegardin eller dynamiske lister.)
2. AJAX-y-nettsteder der, selv etter en betydelig brukerhandling, endres ikke URL-adressen. (Innhold gjør ikke nettadressen.)

Hvordan lager du statlige diagrammer?

Det overraskende er at statlige diagrammer ikke er alt som er komplisert å produsere. Likevel, etter min erfaring, blir de ikke brukt så ofte av de fleste programmører, til tross for fordelene (dypere forståelse av brukerinteraksjoner, kohesjon av kodingsarbeid). Jeg sverger ved dem - eller gjorde da jeg kodet hver dag i ulike jobber.

Det anbefales at du produserer tilstandsdiagrammer på papir først, og overfør dem til en digital kopi hvis og bare hvis det er nødvendig. (Det er noe om taktiliteten til skisseing / visning av relasjoner på papir som gjør dem mer konkrete i tankene dine, noe som gjør det lettere å imøtekomme alle mulige interaksjoner og dermed redusere feil i dine applikasjoner.)

Et tilstandsdiagram består av:

• Merkede pilelinjer for å vise brukerinngang / -handling (overgang).
• Merkede sirkler for å vise den resulterende visning av innhold (applikasjonsstatus).
• Start tilstand med en dobbelgrensesnitt.
• Slutttilstander (men ikke når søknaden er nettbasert. Se nedenfor for en forklaring.)

Du kan se et enkelt eksempel direkte nedenfor - som vil bli utvidet senere i denne artikkelen:

Her er trinnene for å opprette statlige diagrammer (med luting mot nettsidebaserte applikasjoner):

1. Lag en liste over alle mulige innganger av applikasjonsbrukeren, fra hver enkelt stat.
2. Tegn Start-tilstanden - en dobbelkrets sirkel merket med "S". Med et nettsted er startstatus startsiden og standardvisningen.
3. Tegn sirkler for mulig unikt tilstand eller delstat. For statiske nettsteder er hver nettside en egen stat. Hvis det for din webapp kan ha forskjellige delstater for samme nettadresse, må du tegne separate statssirkler.
4. For hver mulig handling fra starttilstanden, skriv merkede piler (overganger) til neste mulige tilstands sirkel.
5. Gjenta dette fra hver stat til du har et fullstendig statsdiagram for applikasjonen.
6. Ikke glem om sirkulære overganger. Eksempelvis fra en tilstand tilbake til seg selv (muligens på grunn av å klikke på den samme lenken to ganger).
7. Gjentatte overganger fra en klynge av beslektede stater kan representeres med litt kort form, slik det vil bli diskutert nedenfor.
8. Statiske diagrammer for ikke-webapplikasjoner har nesten alltid en "End" -status. Internett er imidlertid sagt å være "statsløs" fordi i en nettleser er hver enkelt stat en sluttstat. Du kan ta en handling og gå, eller ta en annen handling og deretter forlate, etc. Så for webapplikasjoner er det ikke nødvendig å tegne sluttstaten.

For å utvide på # 7 ovenfor, husk at med nettsteder, kan det være mye gjentakelse av handlinger. For eksempel hvis hver side inneholder samme navigasjonsmeny, er det ikke nødvendig å vise disse overgangene om og om igjen og rote opp statediagrammet. Bare representer klyngede handlinger med litt kortformat / symbol.

(Det er langt lettere å forstå et tilstandsdiagram hvis du er personen som tegner den, ett trinn om gangen. Hvis du er en person som ser på et ferdigstillet tilstandsdiagram, kan det være skremmende. Derfor bor statlige diagrammer ofte bare papir - forutsatt at du bruker dem.

Hvordan bruker statlige diagrammer på nettsidebaserte applikasjoner?

For et statisk nettsted som bruker Nei AJAX-y-funksjoner (dvs. en hvilken som helst funksjon der nettadressen ikke endres), er et tilstandsdiagram ganske enkelt å produsere, men generelt unødvendig. For eksempel, et statisk nettsted der hver side er koblet til hver annen side, resulterer i et tilstandsdiagram som noen ganger refereres til som en "fullstendig tilkoblet" graf. Slike statlige diagrammer er vanligvis meningsløse fordi det ikke er noen spesiell håndtering for å visualisere. Hver stat er knyttet til hver annen stat)

Hvor statlige diagrammer er mest nyttige er for dynamiske steder - spesielt de med AJAX-y-funksjoner (for eksempel drop-menyer, skyveknapper, trekkspill, gallerier, etc.). I sistnevnte tilfelle kan nettadressen i nettleseren ikke endres, men sidens innhold gjør det så delvis. Det er vanskeligere å visualisere alle mulige stater og overganger (handlinger) fordi en "side" kan ha flere delstater.

Et tilstandsdiagram (eller et sett med stadig mer detaljerte diagrammer) kommer veldig praktisk i dette tilfellet - spesielt hvis det er et team av kodere (og noen ganger designere) å jobbe med.

Et eksempel på statlig diagrambruk

I en kommende opplæring skal jeg vise deg hvordan du kan kode jQuery for to effekter jeg bruker i min OmMe-mal. Levende siden har noen CSS-glitcher som må strykes ut først. Jeg vil også legge til flere jQuery-baserte funksjoner hvis det er nok tid. Disse tilleggsfunksjonene vil bli gjenstand for vårt eksempel.

I fremtiden vil denne malen bli et gratis WordPress-tema rettet mot frilansere som ønsker å vise frem sitt arbeid (gigs) -opplevelse. For nå vil jeg vise hvordan statlige diagrammer kan hjelpe deg å forstå de nødvendige årsakene / reaksjonene (aka inngang / overganger) for "Current Gigs" -galleriet sett ovenfor. Å forstå de nødvendige overgangene hjelper deg å kode mer trygt, og det er alle kodende språkavhengige. Så du kan bestemme kodebiblioteket / språket etter å ha opprettet tilstandsdiagrammet.

Ønskede applikasjonsfunksjoner

Hvis du ser på "Current Gigs" -galleriet midt på venstre side av bildet ovenfor, eller på live-siden, vil du se at dette i hovedsak er det samme konseptet som et bildegalleri. Klikk på en kobling og detaljer om at "gig" vises. Men da jeg bygget live siden, var det ingen jQuery opplæringsprogrammer om hvordan å kaste tekst inn i blandingen, for hver "ramme" av utstillingsvinduet. Jeg måtte komme opp med min egen kode.

For å gjøre det måtte jeg først forstå alle mulige brukerinteraksjoner. Et tilstandsdiagram er ideelt for dette. La oss oppe ante, skjønt. Det jeg egentlig ønsket, er et showcase-område som viser både nåværende konserter og fortidsposter. Det er liksom en visuell C.V. (Curriculum Vitae, aka "CV"), viser et galleri av arbeidserfaring. Hver konsertramme inneholder et skjermbilde på tilhørende nettstedets hjemmeside, sammen med noen tekst som gir detaljer om arbeidet jeg gjorde / gjør der.

For nå har siden bare "Gjeldende Gigs", men også "Past Gigs". Her er en liste over funksjonelle krav til hva utstillingsområdet skal ha:

1. Tabbed jQuery-grensesnitt, men "usynlig". I stedet for å bruke vanlige faner, bruk mini-bannere som ligner på "Gjeldende Gigs" -grafikk.
2. Når en "tab" klikkes (Gjeldende Gigs, Past Gigs), vises den aktuelle konsertlisten, sammen med rammen (detaljer) for det første elementet.
3. Standard utstillingsvindu er "Gjeldende Gigs".
4. Når noen klikker "Past Gigs", må listen over tidligere spill viser, sammen med detaljrammen for det første elementet i listen.
5. Gigs lister. Hver "tab" vil gi en liste over spill som er plassert til venstre ved hjelp av et Blueprint CSS-nett.
6. Gigellisteelementene vil være tekstkoblinger.
7. Hver utstillingsvindu vil ha helt forskjellige lenker (tidligere og nåværende arbeid). Så en "arbeidserfaring" kan bare vises i ett showcase om gangen.
8. Når et element i en konsertliste klikkes, vises konsertens detaljer "ramme". Hver ramme vil vise et snapshot (tidligere lagret) og tilhørende jobbbeskrivelse. Grenseoppsettet for CSS grensesnitt vil bli brukt til å plassere presentasjonselementene. (Dette er ikke nødvendig, men det er det jeg satser på.)

Så for å gjenta, er målet å ha et flippert grensesnitt hvor kategoriene er merket "Gjeldende Gigs" og "Past Gigs". Dette gjør det mulig for flere faner senere, bare begrenset av bredden på hver etikett og bredden på utstillingsområdet (590 piksler). Men jeg vil at kategoriene skal være "usynlige", som nevnt. I stedet for de typiske kategoriene i et fanebladgrensesnitt, vil jeg bruke mini-bannere. Hvis du ser på live test siden, er det en mini-banner merket "Gjeldende Gigs", og en annen merket "Past Gigs". De vil være fanene. Her er et nærbilde skjermbilde av hva det siste utstillingsområdet kan se ut, med standardinnstillinger.

Opprette statsdiagrammet

For å opprette statsdiagrammet må vi først oppregne alle mulige unike tilstander, inngang og handling:

1. Start tilstand: Ved belastning på hjemmesiden:
   1. Skjul (ikke vise) alle gigrammer ved hjelp av CSS.
   2. Present "Current Gigs" showcase som standard.
   3. Innenfor standardfremvisningen presenterer du rammen for det første elementet i konsertlisten som standard. Så når noen klikker på Current Gigs "tab", vil showcaseet nullstille seg selv.
2. Mulige generiske handlinger fra Start-tilstanden:
   
   1. Klikk på "tab". Reaksjon / overgang: Gjør utstillingsvinduet som samsvarer med fanen klikket.
   2. Klikk på et spilleliste. Reaksjon / overgang: Gjør den tilsvarende gig-elementrammen.
3. Mulige generiske handlinger fra andre stater: akkurat det samme. Vi er heldige i dette tilfellet, fordi dette gjør statsdiagrammet så mye enklere.

Merk: På dette tidspunktet er vi bare opptatt av hva som skjer i C.V. vise frem. I statsdiagrammet bryr vi oss ikke om handlinger som påvirker andre deler av nettsiden. Vi viser bare handlinger / reaksjoner som påvirker C.V. vise frem.

Her er et eksempelstatistikkdiagram for funksjonen ovenfor.

Et par notater om dette diagrammet:

1. I forbindelse med denne diskusjonen er det ikke så viktig hva hver etikett egentlig er. Her representerer hver en nettside som jeg enten skriver for nå eller pleide å skrive for.
2. Det er ikke så komplisert som det ser ut. Bare fokus på en overgang om gangen, og det blir klart hva som skjer. [Her er handlingsetikettene de samme som statens etiketter. Det er ikke alltid tilfelle.] Det er vanligvis mye klarere når du tegner diagrammet selv, legger til nye statssirkler og overgangspiler en om gangen.
3. Overganger, aka brukerhandlinger, er representert av merkede piler. (Normalt vil etikettene være fulltekst, ikke de korte skjemaene som brukes her.)
4. Stater, aka reaksjoner, er representert av sirkler. Starttilstanden er alltid merket med en dobbel sirkel og en "S".
5. Korte former brukes til begge typer etiketter, for å holde diagrammet mindre rotete.
6. Statene og delstaten er fargekodede basert på om de er primære eller sekundære. For eksempel representerer blå primære stater (og overganger). Du kan gå fra Start-tilstand til en hvilken som helst blå stat med et enkelt klikk på den aktuelle linken. Du kan ikke gå til en lilla (sekundær) tilstand fra Start uten å først passere gjennom en primær tilstand.
7. Fordi det er mye repeterende overgang (det vil si fra et hvilket som helst gig-element til et annet), vises overgangsgrupper med en av de tykke skråstilt pilene (blå eller lilla fylling). For eksempel, mens du ser på FF (FreelanceFolder) gig-detaljer, kan du klikke på noen av konsertelementene som er oppført for CG (Current Gigs) utstillingsvinduet, inkludert FF selv. Eller du kan klikke på CG "fanen" og tilbakestille utstillingsvinduet. Du kan ikke gå fra en "gjeldende" konsertramme til en "fortid" konsertramme, og heller ikke omvendt.
8. Den korte, skisserte blå pilen inneholder overganger tilbake til CGs standardstatus. Den korte, skisserte lilla pilen inkluderer ikke overganger tilbake til PGs standardstatus. (Det er fordi disse overgangene allerede er vist eksplisitt. De var ikke for CG fordi diagrammet ville være altfor rotete.)

Ved å utvide på punkt # 5 ovenfor, er tommelfingerregelen at hvis det er flere repeterende overganger fra en relatert tilstandstilstand, kan du annotere overgangene med en slags kort form. Du vil bare få en følelse av de viktige overgangene slik at de er mest i tankene dine. En annen tilnærming er å ta et komplekst diagram og dele i deler: hovedoversikt, deretter "eksploderte" versjoner av overgangsklynger.

For eksempel kan diagrammet ovenfor ha hatt et hovedstandarddiagram som inneholder nodene S, CG og PG. Så ville det være to detaljerte diagrammer. Man ville ha S, CG, og de tilsvarende delstatene som representerer ulike konserter. Det andre detaljerte diagrammet vil ha S, PG, og de tilsvarende gig-delstaten.

Siste tanker

Samlet sett burde du nå ha et tydeligere mentalt bilde av hvordan showcase-delen fungerer. Jeg kommer ikke til å komme inn på hvordan man skal flytte fra et statutediagram til faktisk kode. Det burde bli tydelig når du forstår alle brukerinteraksjonene. Statiske diagrammer - og forståelsen av dem skal hjelpe deg med å skrive mer sammenhengende kode, og redusere sjansene for et buggy-program. Din kodingsteknikk endres ikke.