Sådan separeres JavaScript på din webside

Når du først skriver en ny JavaScript, er den nemmeste måde at konfigurere den at integrere JavaScript-koden direkte ind på websiden, så alt er på det ene sted, mens du tester det for at få det til at fungere ret. På samme måde, hvis du indsætter et forudskrevet script på dit websted, kan instruktionerne fortælle dig at integrere dele eller hele scriptet på selve websiden.

Dette er okay til at konfigurere siden og få den til at fungere ordentligt i første omgang, men når din side fungerer som du vil, vil du være i stand til forbedre siden ved at udpakke JavaScript til en ekstern fil, så dit sideindhold i HTML'en ikke er så rodet med ikke-indholdsemner som JavaScript.

Hvis du bare kopierer og bruger JavaScripts skrevet af andre mennesker, kan deres instruktioner til, hvordan man tilføjer deres script til din side, muligvis have resulteret i, at du har en eller flere store sektioner af JavaScript er faktisk integreret i din webside selv, og deres instruktioner fortæller dig ikke, hvordan du kan flytte denne kode ud af din side til en separat fil og stadig har JavaScript arbejde. Vær dog ikke bange, for uanset hvilken kode den JavaScript du bruger på din side kan du nemt flytte JavaScript ud af din side og indstil den som en separat fil (eller filer, hvis du har mere end et stykke JavaScript indlejret på siden). Processen til at gøre dette er altid den samme og illustreres bedst med et eksempel.

Lad os se på, hvordan et stykke JavaScript kan se ud, når det er integreret på din side. Din faktiske JavaScript-kode vil være forskellig fra den, der vises i følgende eksempler, men processen er den samme i alle tilfælde.

Dit indlejrede JavaScript skal ligne et af de ovenstående tre eksempler. Naturligvis vil din faktiske JavaScript-kode være forskellig fra den, der vises, men JavaScript vil sandsynligvis blive indlejret på siden ved hjælp af en af ​​de ovennævnte tre metoder. I nogle tilfælde bruger din kode muligvis den forældede language = "javascript" i stedet for type = "text / javascript" i hvilket tilfælde du måske ønsker at bringe din kode mere opdateret til at begynde med ved at erstatte sprogattributten med typen én.

Før du kan udpakke JavaScript til sin egen fil, skal du først identificere den kode, der skal udvindes. I alle tre af de ovenstående eksempler er der to linjer med den faktiske JavaScript-kode, der skal udvindes. Dit script vil sandsynligvis have meget flere linjer, men kan let identificeres, fordi det vil besætte det samme sted på din side som de to linjer i JavaScript, som vi har fremhævet i ovenstående tre eksempler (alle tre eksempler indeholder de samme to linjer JavaScript, det er bare beholderen omkring dem, der er lidt forskellige).

1. Den første ting, du skal gøre for faktisk at udpakke JavaScript til en separat fil, er at åbne en almindelig teksteditor og få adgang til indholdet på din webside. Derefter skal du finde det indlejrede JavaScript, der vil være omgivet af en af ​​variationerne i koden vist i ovenstående eksempler.
2. Når du har fundet JavaScript-koden, skal du vælge den og kopiere den til dit udklipsholder. Med ovenstående eksempel fremhæves den kode, der skal vælges, du behøver ikke at vælge script-tags eller de valgfri kommentarer, der kan vises omkring din JavaScript-kode.
3. Åbn en anden kopi af din almindelige teksteditor (eller en anden fane, hvis din redaktør understøtter åbning af mere end én fil ad gangen) og forbi JavaScript-indholdet der.
4. Vælg et beskrivende filnavn, der skal bruges til din nye fil, og gem det nye indhold vha. Det pågældende filnavn. Med eksemplekoden er formålet med scriptet at bryde ud af rammer, så et passende navn kunne være framebreak.js.
5. Så nu har vi JavaScript i en separat fil, vi vender tilbage til redaktøren, hvor vi har det originale sideindhold for at foretage ændringerne der for at linke til den eksterne kopi af scriptet.
6. Da vi nu har scriptet i en separat fil, kan vi fjerne alt mellem script-tags i vores originale indhold, så tag.
7. Det sidste trin er at tilføje en ekstra attribut til scriptmærket, der identificerer, hvor det kan finde det eksterne JavaScript. Vi gør dette ved hjælp af en src = "filename" attribut. Med vores eksempel script, vil vi specificere src = "framebreak.js".
8. Den eneste komplikation til dette er, hvis vi har besluttet at gemme de eksterne JavaScripts i en separat mappe fra de websider, der bruger dem. Hvis du gør dette, skal du tilføje stien fra webside-mappen til JavaScript-mappen foran filnavnet. For eksempel, hvis JavaScripts gemmes i en js mappe i den mappe, der indeholder vores websider, vi har brug for src = "js / framebreak.js"

Så hvordan ser vores kode ud, når vi har adskilt JavaScript ud i en separat fil? I tilfælde af vores eksempel JavaScript (forudsat at JavaScript og HTML er i den samme mappe) læser vores HTML på websiden nu:

Vi har også en separat fil kaldet framebreak.js, der indeholder:

if (top.location! = self.location) top.location = self.location;

Dit filnavn og filindhold vil være meget anderledes end det, fordi du vil have trukket ud uanset JavaScript blev integreret i din webside og fik filen et beskrivende navn baseret på hvad det gør det. Selve processen med at udtrække den vil være den samme, uanset hvilke linjer den indeholder.

Hvad med de andre to linjer i hvert af eksemplerne to og tre? Formålet med disse linjer i eksempel to er at skjule JavaScript fra Netscape 1 og Internet Explorer 2, hvoraf ingen bruger mere, og derfor er disse linjer ikke rigtig nødvendige i det første placere. Placering af koden i en ekstern fil skjuler koden fra browsere, der ikke forstår script-tagget mere effektivt end omgivende den i en HTML-kommentar alligevel. Det tredje eksempel bruges til XHTML-sider til at fortælle validatorer, at JavaScript skal behandles som sideindhold og ikke for at validere det som HTML (hvis du bruger en HTML-doktype snarere end en XHTML, så ved valideren allerede dette, og derfor er disse tags ikke havde brug for). Med JavaScript i en separat fil er der ikke længere noget JavaScript på siden, der skal springes over af validatorer, og derfor er disse linjer ikke længere nødvendige.

En af de mest nyttige måder, hvorpå JavaScript kan bruges til at føje funktionalitet til en webside, er at udføre en slags behandling som svar på en handling fra din besøgende. Den mest almindelige handling, du vil reagere på, vil være, når den besøgende klikker på noget. Begivenhedshåndtereren, der giver dig mulighed for at svare på besøgende, der klikker på noget, kaldes onclick.

Når de fleste først tænker på at tilføje en onclick-begivenhedshåndterer til deres webside, tænker de straks at føje den til en tag. Dette giver et stykke kode, der ofte ser ud:

Dette er forkert måde at bruge onclick på, medmindre du har en faktisk meningsfuld adresse i href-attributten, så de uden JavaScript overføres et sted, når de klikker på linket. Mange mennesker udelader også "return falske" fra denne kode og undrer sig derfor over, hvorfor toppen af ​​den aktuelle side altid bliver indlæst efter at scriptet er kørt (hvilket er hvad href = "#" beder siden om at gøre, medmindre der er returneret falsk fra alle begivenhedshåndterere. Selvfølgelig, hvis du har noget meningsfuldt som destinationen for linket, kan det være en god ide at gå dertil efter at have kørt onclick-koden, og så har du ikke brug for "return falsk".

Hvad mange ikke ved, er, at onclick-begivenhedshåndtereren kan føjes til nogen HTML-tag på websiden for at interagere, når din besøgende klikker på dette indhold. Så hvis du vil have noget til at køre, når folk klikker på et billede, kan du bruge:

Hvis du vil køre noget, når folk klikker på tekst, kan du bruge:

noget tekst

Disse giver naturligvis ikke den automatiske visuelle anelse om, at der vil være et svar, hvis din besøgende klikker på dem som et link gør, men du kan tilføje den visuelle ledetråd let nok selv ved at style billedet eller span korrekt.

Den anden ting at bemærke om disse måder at fastgøre onclick-begivenhedshåndtereren er, at de ikke kræver "return falsk", fordi der ikke er nogen standardhandling, der vil ske, når der klikkes på elementet, der skal være handicappet.

Disse måder at fastgøre onclick er en stor forbedring af den dårlige metode, som mange mennesker bruger, men det er stadig langt fra at være den bedste måde at kode den på. Et problem med at tilføje onclick ved hjælp af en af ​​ovenstående metoder er, at det stadig blander din JavaScript ind med din HTML. onclick er ikke en HTML-attribut, det er en JavaScript-begivenhedshåndterer. Som sådan for at adskille vores JavaScript fra vores HTML for at gøre siden lettere at vedligeholde, er vi nødt til at få denne onclick-reference fra HTML-filen til en separat JavaScript-fil, hvor den hører hjemme.

Den nemmeste måde at gøre dette på er at erstatte onclick i HTML med en id der gør det nemt at knytte begivenhedshåndtereren til det passende sted i HTML. Så vores HTML kan nu indeholde en af ​​disse udsagn:

 noget tekst

Vi kan derefter kode JavaScript i en separat JavaScript-fil, der enten er knyttet til bunden af ​​siden på siden eller som er i toppen af ​​siden, og hvor vores kode er inde i en funktion, der i sig selv kaldes, når siden er færdig med indlæsningen. Vores JavaScript til at vedhæfte begivenhedshåndterere ser nu sådan ud:

document.getElementById ('img1'). onclick = dosomething; document.getElementById ('sp1'). onclick = dosomething;

En ting at bemærke. Du vil bemærke, at vi altid har skrevet onclick helt med små bogstaver. Når du koder udsagnet i deres HTML vil du se nogle mennesker skrive det som onClick. Dette er forkert, da navne på JavaScript-begivenheder er alle små bogstaver, og der er ingen sådanne handler som onClick. Du kan slippe af med det, når du inkluderer JavaScript i dit HTML-tag direkte, da HTML ikke er store og små bogstaver, og browseren vil kortlægge det til det rigtige navn til dig. Du kan ikke slippe af med den forkerte store bogstaver i din JavaScript, da JavaScript er små og små bogstaver, og der er ikke noget i JavaScript som onClick.

Denne kode er en enorm forbedring i forhold til de tidligere versioner, fordi vi nu begge knytter begivenheden til det korrekte element i vores HTML, og vi har JavaScript helt adskilt fra HTML. Vi kan forbedre dette endnu mere.

Det eneste problem, der er tilbage, er, at vi kun kan knytte en onclick-begivenhedshåndterer til et specifikt element. Skulle vi til enhver tid være nødt til at knytte en anden onclick-begivenhedshåndterer til det samme element, vil den tidligere tilknyttede behandling ikke længere være knyttet til dette element. Når du tilføjer en række forskellige scripts til din webside til forskellige formål er der mindst en mulighed for, at to eller flere af dem muligvis vil give en vis behandling, der skal udføres, når det samme element er klikket på. Den rodede løsning på dette problem er at identificere, hvor denne situation opstår, og at kombinere behandlingen, der skal kaldes sammen til en funktion, der udfører hele behandlingen.

Mens sammenstød som dette er mindre almindeligt med onclick, end de er med onload, er det ikke den ideelle løsning at identificere sammenstødene på forhånd og kombinere dem sammen. Det er slet ikke en løsning, når den faktiske behandling, der skal knyttes til elementet, ændres over tid, så nogle gange er der en ting at gøre, nogle gange en anden, og nogle gange begge dele.

Den bedste løsning er at stoppe med at bruge en begivenhedshåndterer fuldstændigt og i stedet bruge en JavaScript-begivenhedslytter (sammen med det tilhørende attachEvent for Jscript- da dette er en af ​​de situationer, hvor JavaScript og JScript afvige). Vi kan gøre dette lettere ved først at oprette en addEvent-funktion, der tilføjer enten en begivenhedslytter eller en vedhæftet fil, afhængigt af hvilken af ​​de to, det sprog, der køres understøtter;

funktion addEvent (el, eType, fn, uC) {if (el.addEventListener) {el.addEventListener (eType, fn, uC); vende tilbage sandt; } andet hvis (el.attachEvent) {return el.attachEvent ('on' + eType, fn); } }

Vi kan nu vedhæfte den behandling, vi ønsker, skal ske, når vores element klikkes på ved hjælp af:

addEvent (document.getElementById ('spn1'), 'klik', dosomething, false);

Ved hjælp af denne metode til at vedhæfte den kode, der skal behandles, når der klikkes på et element, betyder det, at det at foretage et andet addEvent-opkald for at tilføje en anden funktion, der skal køres, når der klikkes på et bestemt element, ikke erstatter den forudgående behandling med den nye behandling, men tillader i stedet begge funktioner løb. Vi har ikke behov for at vide, når vi ringer til et addEvent, om vi allerede har en funktion knyttet til element, der skal køres, når det klikkes på, køres den nye funktion sammen med og funktioner, der tidligere var vedlagt.

Skulle vi have brug for evnen til at fjerne funktioner fra det, der køres, når der klikkes på et element, kunne vi oprette en tilsvarende deleteEvent-funktion, der kalder den passende funktion til at fjerne en begivenhedslytter eller vedhæftet begivenhed?

En ulempe ved denne sidste måde at vedhæfte behandlingen er, at de virkelig gamle browsere ikke understøtter disse relativt nye måder at knytte begivenhedsbehandling til en webside. Der skulle være få mennesker, der bruger sådanne forældede browsere nu til at se bort fra dem i hvad J (ava) Manuskript skriver vi bortset fra at skrive vores kode på en sådan måde, at det ikke forårsager et stort antal fejl Beskeder. Ovenstående funktion er skrevet for ikke at gøre noget, hvis ingen af ​​de måder, den bruger, understøttes. De fleste af disse virkelig gamle browsere understøtter heller ikke getElementById-metoden til at henvise til HTML og så en enkel hvis (! document.getElementById) returnerer falsk; øverst på nogen af ​​dine funktioner, der udfører sådanne opkald, ville det også være passende. Naturligvis er mange, der skriver JavaScript, ikke så hensynsfulde af dem, der stadig bruger antikke browsere og så disse brugere skal vænne sig til at se JavaScript-fejl på næsten hver webside, de besøger nu.

Hvilken af ​​disse forskellige måder bruger du til at vedhæfte behandling på din side, der skal køres, når dine besøgende klikker på noget? Hvis den måde, du gør det på, er tættere på eksemplerne øverst på siden end til eksemplerne i bunden af ​​siden, er det måske den gang du tænkte på at forbedre den måde, du skriver din onclick-behandling på, for at bruge en af ​​de bedre metoder, der er præsenteret nede på side.

Ser du på koden til cross-browser begivenhedslytteren vil du bemærke, at der er en fjerde parameter, som vi kaldte UC, hvis anvendelse ikke er indlysende fra den forudgående beskrivelse.

Browsere har to forskellige ordrer, hvor de kan behandle begivenheder, når begivenheden udløses. De kan arbejde udefra og indad fra

• uC = sandt at behandle i optagelsesfasen
• uC = falsk at behandle i boblefasen.

Så hvor der er adskillige andre tags pakket rundt om det, som begivenheden blev udløst i optagelsesfasen, kører først med det yderste tag og flytter ind mod den, der udløste begivenheden, og så når boblen, når først mærket, som begivenheden blev knyttet til, er blevet behandlet, vender boblefasen processen og går tilbage ud igen.

Internet Explorer og traditionelle begivenhedshåndterere behandler altid boblefasen og aldrig optagelsesfasen og starter derfor altid med det mest specifikke tag og arbejder udad.

Så med begivenhedshåndterere:

xx