Den moderne webutvikleren som ikke anser Ajax når man planlegger eller bygger sine nettsteder, kan potensielt gå glipp av et kraftig verktøy for å øke brukervennligheten.
Det er imidlertid utfordringer i å implementere Ajax-funksjonalitet på en nettside.
I denne artikkelen diskuterer vi løsninger på fem av de vanligste utfordringene som en utvikler står overfor når du bruker Ajax for å forbedre innholdet på nettstedet deres.
Selv om det er mye mer å diskutere og undersøke om alle fem temaene, bør dette innlegget gi nybegynnere og mellomliggende Ajax-utviklere noen gode tips om implementering av Ajax-funksjonalitet på en mer brukervennlig og tilgjengelig måte .
Dette problemet oppstår når en designer har innlemmet JavaScript og Ajax-forbedringer i nettstedets arkitektur uten å gjøre bestemmelser for nettlesere som har deaktivert JavaScript.
Ingenting er galt med å planlegge et nettsted med JavaScript og Ajax; Faktisk, i dagens marked, bør JavaScript-hensyn være integrert i planleggingsprosessen. Men du bør likevel sørge for at nettsiden er bakoverkompatibel (eller at den nedbrytes grasiøst) ved lanseringen.
Selv om Ajax kan være integrert i planleggingen av nettstedets arkitektur, må du sørge for at alt innhold er tilgjengelig via konvensjonelle server-side metoder.
La oss si at du har en "Medarbeiderinformasjon" -side som har en egen lenke for hver ansatt. Ved hjelp av server-side-teknologi kan du vise innholdet for en bestemt ansatt basert på en verdi som sendes gjennom spørringsstrengen, slik:
Alle linkene over viser til samme side, siden "Ansatte" , som endres i henhold til variabelen i spørringsstrengen. Hver ansattes informasjon vil bli lastet fra serveren, som kan gjøres på flere måter: via server-side inkluderer; gjennom en database; eller til og med bruke XML.
Uansett hvilken ansattslink som er klikket, må hele siden lastes for at den ønskede informasjonen skal leveres.
Så innholdet er fullt tilgjengelig før noen Ajax-forbedringer er lagdelt på toppen. Da, ved hjelp av JavaScript, kan fullstendig sideoppdatering avbrytes og innholdet lastes i stedet via Ajax. Den klikkte lenken kan identifiseres med en ID eller ved å sjekke verdien av HREF-attributtet i ankeret.
Selv om innholdet er fullt tilgjengelig med JavaScript deaktivert, vil de fleste brukere se den forbedrede Ajax-drevne versjonen.
Prinsippet om progressiv forbedring for Ajax er velkjent, fordi den vanligvis brukes for diskret JavaScript-teknikker og er iboende av CSS, som illustrert av grafikken nedenfor:
Så bygg nettstedet ditt for å jobbe uten JavaScript, og legg deretter til JavaScript som en forbedring, akkurat som du vil markere innholdet ditt i HTML og deretter "forbedre" det med CSS.
Nesten alle nettlesere har en måte å visuelt indikere på brukeren at innholdet lastes inn. I nåværende nettlesere vises indikatoren på fanen som laster inn innholdet.
Bildene nedenfor viser denne animerte indikatoren fra noen få populære nettlesere.
Lasterindikatoren for Internet Explorer er en solid sirkel med en gradient som spinner mens innholdet lastes.
Firefox viser et lignende ikon med små snirkirkler i forskjellige nyanser av grå.
Google Chrome spinner en halv sirkel.
Problemet er at Ajax-forespørsler ikke utløser denne "loading" -indikatoren som er innebygd i nettlesere.
Den vanlige løsningen på dette er å innlemme en tilpasset fremdriftsindikator i Ajax-forespørselen. En rekke nettsteder tilbyr gratis "Ajax loading" grafikk.
Preloaders.net har en rekke fancy, tilpassbare animerte grafikk å velge mellom.
Implementering av denne egendefinerte laste grafikken eller fremdriftsindikatoren, inn i nettstedets Ajax-funksjonalitet, er bare et spørsmål om å vise og gjemme det på de aktuelle tidspunktene via JavaScript.
Din Ajax-kode vil inneholde kodelinjer som forteller deg om forespørselen er i gang eller fullført. Ved hjelp av JavaScript kan du vise den animerte grafikken mens forespørselen behandles og deretter skjule den når handlingen er fullført.
Dette er relatert til det forrige problemet, men blir ofte overset, fordi utvikleren kan anta at forsvinningen av "loading" -indikatoren er tilstrekkelig til å informere brukeren om at innholdet er fullstendig lastet. Men i de fleste tilfeller er det definitivt en bedre indikasjon på at innholdet har blitt oppdatert eller oppdatert.
Dette kan gjøres likt hvordan skjemainnlegg er bekreftet. Etter at en lenke er sendt inn på Digg , siden kan du vite veldig tydelig at innleveringen din er mottatt:
Selv om denne indikatoren ikke peker ut en fullført Ajax-forespørsel, er prinsippet det samme: "Suksess" -boksen vises etter at siden som legger inn skjemaet er fullført, og boksen er fargerik og tydelig.
En lignende grafikk eller indikator kan brukes ved slutten av en Ajax-forespørsel for å fortelle brukere at innholdet er oppdatert. Dette ville bli implementert i tillegg til, ikke i stedet for, fremdriftsindikatoren som ble foreslått for det forrige problemet.
En lignende, men mindre subtil måte å indikere at et innholds område har blitt oppdatert, er gul fade teknikk . Denne metoden er kjent for brukere, diskret og fungerer godt med Ajax-lastet innhold.
De XMLHttpRequest
objektet, som ligger til grunn for alle Ajax-forespørsler, er begrenset til å stille forespørsler på samme domene som siden som gjør forespørselen. Men det er tilfeller når du vil ha tilgang til tredjepartsdata via en Ajax-forespørsel. Mange webtjenester gjør dataene tilgjengelige via en API.
Løsningen på dette problemet er å bruke serveren som en proxy mellom tredjepartstjenesten og nettleseren. Selv om detaljene i denne løsningen er langt utover omfanget av denne artikkelen, går vi over det grunnleggende prinsippet på jobben.
Fordi en Ajax-forespørsel kommer fra klientens nettleser, må den referere til en fil på et annet sted, men på samme domene som kilden til forespørselen.
Din server, men i motsetning til klientens nettleser, er ikke begrenset på denne måten. Så når siden på serveren din heter, går den i bakgrunnen som det normalt ville, men med tilgang til et hvilket som helst domene.
Dette gir ingen sikkerhetsrisiko for brukeren fordi forespørslene til tredjepartstjenesten er gjort på serveren din. Så når informasjonen er oppnådd på servernivå, er neste trinn i Ajax-samtalen å sende et svar tilbake til klienten, som i dette tilfellet vil inkludere dataene fra tredjepartstjenesten.
Hvis du vil ha mer informasjon om denne kraftfulle metoden for å kombinere webtjenestetilgang med egendefinert Ajax, må du sjekke ut andre ressurser, hvorav noen er oppført nedenfor.
Dette er et vanskeligere problem, men kan ikke være nødvendig, avhengig av hvilken type nettside eller applikasjon du har. Problemet oppstår når innhold lastes via Ajax, og deretter blir «tilstand» på nettstedet endret uten nettadressen som peker på siden som påvirkes.
Hvis brukeren returnerer til siden via et bokmerke eller deler lenken med en venn, blir det oppdaterte innholdet ikke automatisk vist. Nettstedet vil i stedet gå tilbake til sin opprinnelige tilstand. Flash-nettsteder pleide å ha det samme problemet: de tillot ikke at brukere koblet til noe annet enn den første skjermen.
For å sikre at en bestemt "tilstand" på en Ajax-drevet nettside er koblet og bokmerket, kan du bruke interne sidelinker, som endrer nettadressen, men ikke oppdaterer siden eller påvirker vertikal stilling.
Denne enkle koden demonstrerer hvordan dette gjøres:
var currentAnchor = document.location;currentAnchor = String(currentAnchor);currentAnchor = currentAnchor.split("#");if (currentAnchor.length > 1) {currentAnchor = currentAnchor[1];} else {currentAnchor = currentAnchor[0];}switch(currentAnchor) {case "section1":// load content for section 1break;case "section2":// load content for section 2break;case "section3":// load content for section 3break;default:// load content for section 1break;}
Ovenstående er ikke et fungerende stykke kode, men snarere et teoretisk eksempel for å demonstrere de viktigste trinnene som er involvert.
De to første kodelinjene angir den nåværende sidestedet (URL) i en variabel. Deretter konverteres plasseringen til en streng slik at vi kan manipulere den.
Deretter deler vi strengen i to deler via ankersymbolet (#) og kontrollerer deretter for å se om arrayet som er opprettet fra delingen, er større enn ett element. Større enn ett element betyr at nettadressen har et anker.
Hvis nettadressen kun har en del, betyr det at det ikke finnes anker. Den påfølgende "bryter" -oppstillingen laster innholdet i henhold til ankerets verdi. Bryteroppstillingen har et "standard" alternativ hvis det ikke finnes anker, noe som vil være det samme som å laste siden i sin opprinnelige tilstand.
Videre vil vi bruke kode for å håndtere koblinger som peker direkte på bestemt innhold gjennom interne ankre. En lenke som peker til "content2" vil laste innholdet i "content2", og strengen "# content2" vil bli lagt til den nåværende nettadressen.
Dette ville endre nettadressen ved å legge til et internanker uten å endre visningen av siden, men å beholde en identifikator som angir ønsket side på siden.
Denne forklaringen er bare teori. Konseptet fungerer, og det fungerer veldig bra. Men jeg har ikke forklart alle mulighetene, ulempene og andre finesser om å bygge en nettside eller side på denne måten.
Følg linkene nedenfor for en mer omfattende diskusjon om emnet, eller eksperimenter med det selv. Vær også oppmerksom på at dette kan testes med innhold som endres med JavaScript alene, og trenger ikke å benytte Ajax.
Dette innlegget ble skrevet utelukkende for Webdesigner Depot av Louis Lazaris, frilansskribent og webutvikler. Louis løper Imponerende Webs , hvor han legger inn artikler og opplæringsprogrammer på webdesign. Du kan følge Louis på Twitter eller ta kontakt med ham gjennom hans nettside .
Kjenner du til noen løsninger på disse eller andre Ajax-utfordringene? Vennligst del dine kommentarer nedenfor ...