Hoe het gebruik van statusdiagrammen u een betere webcoder kan maken

Een hulpmiddel dat in uw webcoderingsarsenaal hoort, is het toestandsdiagram. Een toestandsdiagram toont de verschillende "toestanden" (reacties) die uw toepassing (bijv. Website) kan bevatten, evenals welke actie of invoer (van de gebruiker) nodig is om een specifieke toestand te bereiken. Een toestandsdiagram helpt om alle mogelijke interacties tussen gebruikers en applicaties in je hoofd te zetten. Dit vergroot de kans dat je in ieder geval de codering voor alle mogelijkheden overweegt, simpelweg omdat je ze nu allemaal kent - wat de kans verkleint dat je een foutcode of nog erger hebt, vergeten bent om met specifieke functionaliteit om te gaan.

Waarom een staatsschema gebruiken?

Een statusdiagram bestaat uit twee componenten: cirkels om staten te vertegenwoordigen (toepassingsreacties / uitvoer) en pijlen om overgangen weer te geven (gebruikersacties / invoer). Toestandsdiagrammen zijn erg handig voor complexe en niet zo complexe computertoepassingen van welke aard dan ook. Als het echter om de ontwikkeling van websites gaat, zijn statusdiagrammen niet altijd van nut:

Als u een statische website heeft waarbij de navigatie garandeert dat elke pagina naar elke andere pagina linkt, is een statusdiagram overbodig. (In de tak van de wiskunde die Graph Theory wordt genoemd, staat deze situatie bekend als een 'volledig verbonden grafiek'. Een grafiek is een reeks randen en knooppunten - d.w.z. overgangen en toestanden.)
Als u een dynamische website draait op een CMS (Content Management System) - inclusief blogplatforms - dan zijn zoveel van de statusovergangen al in uw site gecodeerd. Dus nogmaals, een toestandsdiagram is niet erg nuttig.

Aan de andere kant, als u een website bouwt waar u speciale overgangen moet afhandelen, dan kan een toestandsdiagram van groot voordeel zijn:

Omgaan met speciale gebruikersinvoer, waarbij wat ze selecteren de volgende status bepaalt. (Bijvoorbeeld formulieren of menu's met vervolgkeuzelijsten of dynamische lijsten.)
AJAX-y-sites waarbij zelfs na een aanzienlijke gebruikersactie de URL niet verandert. (Inhoud doet dat, URL doet dit niet.)

Hoe maak je staatdiagrammen?

Het verrassende is dat statusdiagrammen niet zo gecompliceerd zijn om te produceren. Maar in mijn ervaring, ze worden niet zo vaak gebruikt door de meeste programmeurs, ondanks de voordelen (dieper inzicht in gebruikersinteracties, samenhang van coderingsinspanningen). Ik zweer bij ze - of deed toen ik elke dag codeerde in verschillende banen.

Het wordt aanbevolen dat u eerst toestandsdiagrammen op papier maakt en deze vervolgens naar een digitale kopie overbrengt als en alleen als dat nodig is. (Er is iets aan de tactiliteit van het schetsen van input / display-relaties op papier, waardoor ze concreter worden in je geest, waardoor het gemakkelijker wordt om alle mogelijke interacties te accommoderen en zo bugs in je applicaties te verminderen.)

Een toestandsdiagram bestaat uit:

Gelabelde pijllijnen om gebruikersinvoer / actie te tonen (overgang).
Gelabelde cirkels om de resulterende weergave van inhoud weer te geven (applicatiestatus).
Startstatus met een dubbele randcirkel.
Eindtoestanden (maar niet wanneer de toepassing webgebaseerd is. Zie hieronder voor een uitleg.)

U ziet een eenvoudig voorbeeld direct hieronder - dat later in dit artikel wordt uitgebreid:

Hier zijn de stappen voor het maken van statusdiagrammen (met een neiging naar website-gebaseerde applicaties):

Maak een lijst met alle mogelijke invoer door de gebruiker van de toepassing, vanuit elke afzonderlijke status.
Teken de startstatus: een dubbele randcirkel met het label "S". Bij een website is de startstatus de startpagina en de standaardweergave.
Teken cirkels voor een mogelijke unieke staat of substaat. Voor statische sites heeft elke webpagina een afzonderlijke status. Als uw web-app voor dezelfde URL verschillende substatussen kan hebben, moet u afzonderlijke statuscirkels tekenen.
Teken voor elke mogelijke actie vanuit de startstatus gelabelde pijlen (overgangen) naar de cirkel van de volgende mogelijke status.
Herhaal dit van elke status totdat u een volledig statusschema voor de toepassing hebt.
Vergeet cirkelvormige overgangen niet. Bijvoorbeeld, van de ene status terug naar zichzelf (mogelijk omdat twee keer op dezelfde link wordt geklikt).
Herhaalde overgangen van een cluster van verwante toestanden kunnen worden weergegeven met een korte vorm, zoals hieronder zal worden besproken.
Toestandsdiagrammen voor niet-webtoepassingen hebben bijna altijd de status "Einde". Het web zou echter "staatloos" zijn, omdat in een webbrowser elke afzonderlijke status een eindtoestand is. U kunt een actie ondernemen en vertrekken, of een andere actie ondernemen en dan verlof, enz. Dus voor webtoepassingen is het niet nodig om de eindstatus te tekenen.

Als u wilt uitbreiden op nummer 7 hierboven, moet u er rekening mee houden dat er met websites veel herhalingen kunnen optreden. Als bijvoorbeeld elke pagina hetzelfde navigatiemenu bevat, is het niet nodig om die overgangen keer op keer weer te geven en het toestandsdiagram overzichtelijk te maken. Vertegenwoordig geclusterde acties met een korte notatie / symbool.

(Het is veel eenvoudiger om een toestandsdiagram te begrijpen als u degene bent die het tekent, stap voor stap.) Als u een persoon bent die naar een ingevuld toestandsdiagram kijkt, kan dit intimiderend zijn. Om deze reden leven statusdiagrammen vaak alleen op papier - ervan uitgaande dat je ze gebruikt.

Hoe kunnen toestandsdiagrammen worden toegepast op op websites gebaseerde toepassingen??

Voor een statische website die gebruikt Nee AJAX-y-kenmerken (d.w.z. elke functie waarbij de URL niet verandert), een toestandsdiagram is tamelijk gemakkelijk te produceren, maar in het algemeen onnodig. Een statische website waarop elke pagina is verbonden met elke andere pagina resulteert bijvoorbeeld in een statusdiagram dat soms wordt aangeduid als een 'volledig verbonden' grafiek. Dergelijke toestandsdiagrammen zijn meestal zinloos omdat er geen speciale afhandeling is om te visualiseren. Elke staat is verbonden met elke andere staat)

Waar toestandsdiagrammen het meest handig zijn, is voor dynamische sites - vooral die met AJAX-y-functies (zoals vervolgkeuzemenu's, schuifregelaars, accordeons, galerijen, enz.). In het laatste geval kan de URL in de browser mogelijk niet veranderen, maar de pagina-inhoud doet dit gedeeltelijk. Het is moeilijker om alle mogelijke toestanden en overgangen (acties) te visualiseren omdat een "pagina" veelvoudige sub-toestanden kan hebben.

Een toestandsdiagram (of set van steeds gedetailleerdere diagrammen) is in dit geval erg handig - vooral als er een team van codeerders (en soms ontwerpers) is om mee te werken.

Een voorbeeld van gebruik van toestandsdiagrammen

In een volgende tutorial ga ik je laten zien hoe je de jQuery codeert voor twee effecten die ik gebruik in mijn AboutMe-sjabloon. De live-pagina bevat enkele CSS-glitches die eerst moeten worden gladgestreken. Ik wil ook nog wat meer op jQuery gebaseerde functies toevoegen als er voldoende tijd is. Deze extra functies zullen het onderwerp van ons voorbeeld zijn.

In de toekomst zal dit sjabloon veranderen in een gratis WordPress-thema gericht op freelancers die hun werk (optredens) willen laten zien. Voor nu wil ik laten zien hoe toestandsdiagrammen je kunnen helpen de noodzakelijke oorzaak / reacties (alias invoer / overgangen) voor de hierboven getoonde "Current Gigs" galerij te begrijpen. Het begrijpen van de noodzakelijke overgangen helpt je om met meer vertrouwen te coderen, en het is allemaal taalonafhankelijk coderen. U kunt dus beslissen over codebibliotheek / taal na het maken van het toestandsdiagram.

Gewenste toepassingsfuncties

Als je de galerij "Current Gigs" links in het midden van de afbeelding hierboven of op de live-pagina bekijkt, zie je dat dit in essentie hetzelfde concept is als een afbeeldingengalerij. Klik op een link en details van dat "optreden" zullen verschijnen. Toen ik echter de live-pagina bouwde, waren er geen jQuery-zelfstudies over hoe je tekst in de mix gooide, voor elk "frame" van de showcase. Ik moest met mijn eigen code komen.

Om dat te doen, moest ik eerst alle mogelijke gebruikersinteracties begrijpen. Een toestandsdiagram is hier ideaal voor. Laten we echter de ante op een rijtje zetten. Wat ik echt wilde, is een showcase-gedeelte dat zowel Current Gigs als Past Gigs laat zien. Het is een beetje zoals een visuele C.V. (Curriculum Vitae, ook bekend als "cv"), met een galerij met werkervaring. Het frame van elk optreden bevat een schermafbeelding van de startpagina van de bijbehorende site, samen met wat tekst met details over het werk dat ik deed / doe daar.

Voorlopig bevat de pagina alleen 'Current Gigs', maar ook 'Past Gigs'. Hier is een lijst met functionele vereisten voor wat het showcase-gebied zou moeten hebben:

Interface met jQuery-tab, maar "onzichtbaar". Gebruik in plaats van gewone tabbladen minibanners die lijken op de afbeelding "Current Gigs".
Wanneer er op een "tabblad" wordt geklikt (Current Gigs, Past Gigs), wordt de juiste lijst met optredens getoond, samen met het frame (details) van het eerste item.
De standaard showcase is "Current Gigs".
Wanneer iemand op 'Past Gigs' klikt, moet de lijst met eerdere optredens worden weergegeven, samen met het detailsframe van het eerste item in die lijst.
Opstartlijsten. Elke "tab" geeft een lijst met optredens aan de linkerkant met behulp van een Blueprint CSS-raster.
De lijst items van de lijst zullen tekstlinks zijn.
Elke vitrine heeft geheel andere schakels (werk uit heden en verleden). Dus een "werkervaring" kan maar in één showcase tegelijk worden weergegeven.
Wanneer er op een item in een gig-lijst wordt geklikt, verschijnen de details van het optreden "frame". Elk frame toont een schermmagneet (eerder opgeslagen) en de bijbehorende taakomschrijving. Het Blueprint CSS-rasterwerk zal worden gebruikt om de vitrine-elementen te positioneren. (Dit is niet noodzakelijk, maar dat is waar ik naar streef.)

Dus nogmaals, het doel is om een interface met tabbladen te hebben met de tabbladen "Current Gigs" en "Past Gigs". Dit staat later meer tabbladen toe, alleen beperkt door de breedte van elk label en de breedte van de showcase-ruimte (590 pixels). Maar ik wil dat de tabbladen "onzichtbaar" zijn, zoals vermeld. In plaats van de typische tabbladen in een tab-interface, wil ik minibanners gebruiken. Als je kijkt naar de live testpagina, is er een minibanner met het label "Current Gigs" en een andere met het label "Past Gigs". Dat zijn de tabbladen. Hier is een close-upscherm van hoe het uiteindelijke showcase-gebied eruit zou kunnen zien, met standaardinstellingen.

Het staatsschema maken

Om het toestandsdiagram te maken, moeten we eerst alle mogelijke unieke status, invoer en actie opsommen:

Startstatus: Bij het laden van de startpagina:
1. Verberg (niet-weergave) alle gig-frames met behulp van CSS.
2. Huidige 'Huidige optredens' presenteren zich standaard.
3. Binnen de standaard showcase, presenteer je het frame voor het 1e item in de lijst als standaard. Dus wanneer iemand op het tabblad 'Huidige optredens' klikt, wordt de vitrine opnieuw ingesteld.
Mogelijke generieke acties vanuit de startstatus:
1. Klik op "tabblad". Reactie / overgang: render de vitrine die overeenkomt met het tabblad waarop is geklikt.
2. Klik op een item uit een lijst met evenementen. Reactie / overgang: render het corresponderende frame met jolitems.
Mogelijke generieke acties van andere staten: precies dezelfde. We hebben geluk in dit geval, omdat dit het toestandsdiagram zo veel eenvoudiger maakt.

Opmerking: op dit punt maken we ons alleen zorgen over wat er gebeurt in de C.V. showcase. In het toestandsdiagram geven we niet om acties die andere delen van de webpagina beïnvloeden. We laten alleen acties / reacties zien die van invloed zijn op de C.V. vitrine.

Hier is een voorbeeldstatusdiagram voor de bovenstaande functionaliteit.

Een paar opmerkingen over dit diagram:

Voor de doeleinden van deze discussie is het niet zo belangrijk wat elk label eigenlijk is. Hier vertegenwoordigt elk een website waar ik nu voor schrijf of waar ik vroeger voor schreef.
Het is niet zo ingewikkeld als het lijkt. Richt je gewoon op één overgang per keer en het zal duidelijk zijn wat er aan de hand is. [Hier zijn de actielabels hetzelfde als de statuslabels. Dat is niet altijd het geval.] Het is meestal een stuk duidelijker wanneer je het diagram zelf tekent, waarbij je nieuwe toestandscirkels en overgangspijlen een voor een toevoegt.
Overgangen, ook wel gebruikersacties genoemd, worden weergegeven met gelabelde pijlen. (Normaal gesproken zijn de labels full-text, niet de korte formulieren die hier worden gebruikt.)
Staten, ook wel reacties genoemd, worden weergegeven door cirkels. De startstatus is altijd gemarkeerd met een dubbele cirkel en een "S".
Korte formulieren worden gebruikt voor beide typen labels om het diagram minder rommelig te houden.
De toestanden en sub-staten hebben een kleurcode op basis van of ze primair of secundair van aard zijn. Blauw staat bijvoorbeeld voor primaire staten (en overgangen). Je kunt met een enkele klik op de betreffende link van startstatus naar elke blauwe status gaan. Je kunt niet vanuit Purple naar een paarse (secundaire) staat gaan zonder eerst door een primaire status te gaan.
Omdat er veel herhalende overgang is (d.w.z. van elk willekeurig item naar een ander), worden groepen van overgangen getoond met een van de dikke omlijnde pijlen (blauwe of paarse vulling). Als u bijvoorbeeld de details van het FF-bestand (FreelanceFolder) bekijkt, kunt u klikken op een van de items die worden vermeld voor de CG-show (Current Gigs), inclusief FF zelf. Of u kunt op het tabblad CG klikken en de vitrine opnieuw instellen. Je kunt niet van een "actueel" jolframe naar een "verleden" jolframe gaan, noch andersom.
De korte, omlijnde blauwe pijl bevat overgangen terug naar de standaardstatus van CG. De korte, geschetste paarse pijl bevat geen overgangen naar de standaardstatus van PG. (Dat komt omdat die overgangen al expliciet worden weergegeven. Ze waren niet voor CG omdat het diagram veel te rommelig zou zijn.)

Uitgaand van punt 5 hierboven is de vuistregel dat als er meerdere repetitieve overgangen zijn vanuit een verwant cluster van toestanden, je de overgangen kunt annoteren met een soort korte vorm. U wilt gewoon een idee krijgen van de belangrijke overgangen, zodat ze vooroplopen in uw gedachten. Een andere benadering is om een complex diagram te nemen en op te delen in delen: hoofdoverzicht en vervolgens 'geëxplodeerde' versies van transitieclusters.

Het diagram hierboven zou bijvoorbeeld een hoofdtoestandsdiagram kunnen hebben met de knooppunten S, CG en PG. Dan zouden er twee gedetailleerde diagrammen zijn. Men zou S, CG en de corresponderende sub-toestanden hebben die verschillende optredens representeren. Het andere gedetailleerde diagram zou S, PG en de overeenkomstige gig-subtoestanden hebben.

Laatste gedachten

Over het geheel genomen zou u nu een duidelijker beeld moeten hebben van hoe de showcase-sectie functioneert. Ik ga niet begrijpen hoe je van een toestandsdiagram naar echte code kunt gaan. Dat moet duidelijk worden zodra u alle interacties met de gebruiker begrijpt. Toestandsdiagrammen - en uw begrip hiervan moet u helpen om meer samenhangende code te schrijven, waardoor de kans op een buggy-applicatie afneemt. Uw coderingstechniek verandert niet.

Code