Hur du separerar JavaScript på din webbsida

När du först skriver ett nytt JavaScript är det enklaste sättet att konfigurera det att bädda in JavaScript-koden direkt in på webbsidan så att allt är på ett ställe medan du testar det för att få det att fungera rätt. På samma sätt, om du sätter in ett förskrivet skript på din webbplats kan instruktionerna säga att du bäddar in delar eller hela skriptet på själva webbsidan.

Detta är okej för att ställa in sidan och få den att fungera ordentligt i första hand, men när din sida fungerar som du vill ha den kommer du att kunna förbättra sidan genom att extrahera JavaScript till en extern fil så att sidinnehållet i HTML inte är så rörigt med icke-innehåll som t.ex. JavaScript.

Om du bara kopierar och använder JavaScripts skriven av andra människor kan deras instruktioner för hur du lägger till deras skript på din sida ha resulterat i att du har en eller flera stora delar av JavaScript är faktiskt inbäddat i själva din webbsida och deras instruktioner säger inte hur du kan flytta den här koden från din sida till en separat fil och fortfarande har JavaScript arbete. Oroa dig inte men för oavsett vilken kod JavaScript du använder på din sida kan du enkelt flytta JavaScript från din sida och ställa in den som en separat fil (eller filer om du har mer än ett stycke JavaScript inbäddat på sidan). Processen för att göra detta är alltid densamma och illustreras bäst med ett exempel.

Låt oss titta på hur en del av JavaScript kan se ut när den är inbäddad på din sida. Din faktiska JavaScript-kod kommer att skilja sig från den som visas i följande exempel, men processen är densamma i alla fall.

Din inbäddade JavaScript ska se ut som något av ovanstående tre exempel. Naturligtvis kommer din faktiska JavaScript-kod att vara annorlunda än den som visas men JavaScript kommer antagligen att inbäddas på sidan med hjälp av en av ovanstående tre metoder. I vissa fall kan din kod använda den föråldrade language = "JavaScript" istället för type = "text / javascript" i vilket fall kanske du vill ta upp din kod mer uppdaterad till att börja med genom att ersätta språkattributet med typen en.

Innan du kan extrahera JavaScript till sin egen fil måste du först identifiera koden som ska extraheras. I alla tre exemplen ovan finns det två rader med faktisk JavaScript-kod som ska extraheras. Ditt skript kommer förmodligen att ha mycket fler rader men kan lätt identifieras eftersom det kommer att uppta samma plats på din sida som de två raderna i JavaScript som vi har markerat i ovanstående tre exempel (alla tre exemplen innehåller samma två rader av JavaScript, det är bara behållaren runt dem som är något annorlunda).

1. Det första du behöver göra för att faktiskt extrahera JavaScript till en separat fil är att öppna en vanlig textredigerare och få tillgång till innehållet på din webbsida. Du måste sedan hitta det inbäddade JavaScript som kommer att omges av en av varianterna av koden som visas i ovanstående exempel.
2. När du har hittat JavaScript-koden måste du välja den och kopiera den till ditt urklipp. Med exemplet ovan markeras koden som ska väljas, du behöver inte välja skripttaggarna eller valfria kommentarer som kan visas runt din JavaScript-kod.
3. Öppna en annan kopia av din vanliga textredigerare (eller en annan flik om din redigerare stöder att öppna mer än en fil åt gången) och förbi JavaScript-innehållet där.
4. Välj ett beskrivande filnamn som ska användas för din nya fil och spara det nya innehållet med det filnamnet. Med exempelkoden är skriptets syfte att bryta ut ramar så att ett lämpligt namn kan vara framebreak.js.
5. Så nu har vi JavaScript i en separat fil vi återvänder till redaktören där vi har det ursprungliga sidinnehållet för att göra ändringarna där för att länka till den externa kopian av skriptet.
6. Eftersom vi nu har skriptet i en separat fil kan vi ta bort allt mellan skripttaggarna i vårt ursprungliga innehåll så att märka.
7. Det sista steget är att lägga till ett extraattribut till skriptetiketten som identifierar var den kan hitta det externa JavaScript. Vi gör detta med en src = "filnamn" attribut. Med vårt exempelskript skulle vi ange src = "framebreak.js".
8. Den enda komplikationen till detta är om vi har beslutat att lagra de externa JavaScripts i en separat mapp från webbsidorna som använder dem. Om du gör detta måste du lägga till sökvägen från webbsidesmappen till JavaScript-mappen framför filnamnet. Om till exempel JavaScripts lagras i en js mappen i mappen som innehåller våra webbsidor som vi skulle behöva src = "js / framebreak.js"

Så hur ser vår kod ut efter att vi har separerat JavaScript ut i en separat fil? När det gäller vårt exempel JavaScript (förutsatt att JavaScript och HTML finns i samma mapp) läser nu vår HTML på webbsidan:

Vi har också en separat fil som heter framebreak.js som innehåller:

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

Ditt filnamn och filinnehåll skiljer sig mycket från det eftersom du har extraherat vad Javascript var inbäddat i din webbsida och gav filen ett beskrivande namn baserat på vad det gör det. Den faktiska processen för att extrahera den kommer att vara densamma men oavsett vilka rader den innehåller.

Vad sägs om de andra två raderna i vart och ett av exemplen två och tre? Tja, syftet med de raderna i exempel två är att dölja JavaScript från Netscape 1 och Internet Utforskaren 2, varken någon använder mer, och därför är dessa rader egentligen inte nödvändiga i det första plats. Att placera koden i en extern fil döljer koden från webbläsare som inte förstår skriptetiketten mer effektivt än omger det i en HTML-kommentar ändå. Det tredje exemplet används för XHTML-sidor för att berätta validerare att JavaScript ska behandlas som sidinnehåll och inte för att validera det som HTML (om du använder en HTML-doktyp snarare än en XHTML, då vet valideraren redan detta och därför är dessa taggar inte behövs). Med JavaScript i en separat fil finns det inte längre någon JavaScript på sidan som ska hoppas över av validerare och därför behövs de raderna inte längre.

Ett av de mest användbara sätten som JavaScript kan användas för att lägga till funktionalitet på en webbsida är att utföra någon form av behandling som svar på en åtgärd från din besökare. Den vanligaste åtgärden du vill svara på är när den besökaren klickar på något. Händelseshanteraren som låter dig svara på besökare som klickar på något kallas onclick.

När de flesta människor först tänker lägga till en onclick-händelsehanterare på sin webbsida tänker de omedelbart att lägga till den till en märka. Detta ger en kodkod som ofta ser ut:

Det här är fel sätt att använda onclick om du inte har en faktiskt meningsfull adress i href-attributet så att de utan JavaScript kommer att överföras någonstans när de klickar på länken. Många människor lämnar också "return falskt" från den här koden och undrar sedan varför toppen av den aktuella sidan alltid laddas efter att skriptet har körts (vilket href = "#" säger att sidan ska göra om inte falskt returneras från alla händelseshanterare. Naturligtvis, om du har något meningsfullt som destinationen för länken, kanske du vill åka dit efter att ha kört onclick-koden och då behöver du inte "return falsk".

Vad många inte inser är att händelseshanteraren onclick kan läggas till några HTML-tagg på webbsidan för att interagera när din besökare klickar på det innehållet. Så om du vill att något ska köras när människor klickar på en bild kan du använda:

Om du vill köra något när folk klickar på text kan du använda:

lite text

Naturligtvis ger dessa inte den automatiska visuella ledtråden att det kommer att bli ett svar om din besökare klickar på dem sätt som en länk gör men du kan lägga till den visuella ledtråden lätt nog själv genom att utforma bilden eller spännvidden lämpligt sätt.

Det andra att notera om dessa sätt att fästa onclick-händelseshanteraren är att de inte kräver "return falsk" eftersom det inte finns någon standardåtgärd som kommer att hända när du klickar på elementet som måste göras Inaktiverad.

Dessa sätt att fästa onclick är en stor förbättring av den dåliga metoden som många använder, men det är fortfarande långt ifrån att vara det bästa sättet att koda det. Ett problem med att lägga till onclick med någon av ovanstående metoder är att det fortfarande blandar in din JavaScript med din HTML. onclick är inte ett HTML-attribut, det är en JavaScript-händelsehanterare. Som sådan för att separera vår JavaScript från vår HTML för att göra sidan enklare att underhålla måste vi få den onclick-referensen från HTML-filen till en separat JavaScript-fil där den hör hemma.

Det enklaste sättet att göra detta är att ersätta onclick i HTML med en id som gör det enkelt att koppla händelsehanteraren till rätt plats i HTML-koden. Så vår HTML kan nu innehålla ett av dessa uttalanden:

 lite text

Vi kan sedan koda JavaScript i en separat JavaScript-fil som antingen är länkad till botten av sidan på sidan eller som är i huvudet på sidan och där vår kod är inuti en funktion som själv kallas efter att sidan har laddats. Vår JavaScript för att ansluta evenemangshanterarna ser nu ut så här:

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

En sak att notera. Du kommer att märka att vi alltid har skrivit onclick helt med små bokstäver. När du kodar uttalandet i deras HTML ser du att vissa människor skriver det som onClick. Detta är fel eftersom JavaScript-händelseshanterarna alla är små och det finns ingen sådan hanterare som onClick. Du kan komma undan med det när du inkluderar JavaScript i din HTML-tagg direkt eftersom HTML inte är skiftlägeskänsligt och webbläsaren kommer att kartlägga det till rätt namn för dig. Du kan inte sluta med fel versaler i din JavaScript själv eftersom JavaScript är skiftlägeskänsligt och det finns inget sådant i JavaScript som onClick.

Den här koden är en enorm förbättring jämfört med tidigare versioner eftersom vi nu båda kopplar händelsen till rätt element i vår HTML och vi har JavaScript helt separat från HTML. Vi kan dock förbättra detta ytterligare.

Det enda problemet som återstår är att vi bara kan koppla en onclick-händelsehanterare till ett specifikt element. Skulle vi när som helst behöva koppla en annan onclick-händelsehanterare till samma element, kommer den tidigare bifogade behandlingen inte längre att kopplas till det elementet. När du lägger till en mängd olika skript till din webbsida för olika ändamål finns det åtminstone ett möjlighet att två eller flera av dem kanske vill tillhandahålla viss behandling som ska utföras när samma element är klickade på. Den smutsiga lösningen på detta problem är att identifiera var den här situationen uppstår och att kombinera behandlingen som måste samlas till en funktion som utför all behandling.

Även om kollisioner som detta är mindre vanliga med onclick än de är med onload, är det inte den perfekta lösningen att identifiera kollisionerna i förväg och kombinera dem tillsammans. Det är inte en lösning alls när den faktiska behandlingen som måste kopplas till elementet ändras över tid så att det ibland är en sak att göra, ibland en annan och ibland båda.

Den bästa lösningen är att sluta använda en händelsehanterare helt och istället använda en JavaScript-händelse lyssnare (tillsammans med motsvarande attachEvent för Jscript- eftersom detta är en av de situationer där JavaScript och JScript skilja sig). Vi kan göra detta lättast genom att först skapa en addEvent-funktion som lägger till antingen en händelse lyssnare eller bilaga beroende på vilken av de två som språket som körs stöder;

funktion addEvent (el, eType, fn, uC) {if (el.addEventListener) {el.addEventListener (eType, fn, uC); tillbaka sant; } annars om (el.attachEvent) {return el.attachEvent ('on' + eType, fn); } }

Vi kan nu bifoga behandlingen som vi vill ha när vårt element klickas på med hjälp av:

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

Att använda den här metoden för att bifoga koden som ska behandlas när ett element klickas på betyder att ett nytt addEvent-samtal görs för att lägga till en annan funktion som ska kör när du klickar på ett specifikt element kommer inte att ersätta den tidigare bearbetningen med den nya behandlingen utan tillåter istället båda funktionerna springa. Vi behöver inte veta när vi ringer ett addEvent om vi redan har en funktion kopplad till element som ska köras när det klickas på kommer den nya funktionen att köras tillsammans med och tidigare funktioner bifogad.

Skulle vi behöva förmågan att ta bort funktioner från vad som körs när ett element klickas på kan vi skapa en motsvarande deleteEvent-funktion som anropar lämplig funktion för att ta bort en händelse lyssnar eller bifogas händelse?

Den ena nackdelen med detta sista sätt att koppla behandlingen är de riktigt gamla webbläsare som inte stöder dessa relativt nya sätt att koppla händelsehantering till en webbsida. Det borde finnas tillräckligt få människor som använder sådana föråldrade webbläsare nu för att bortse från dem i vad J (ava) Manus skriver vi bortsett från att skriva vår kod på ett sådant sätt att det inte orsakar stort antal fel meddelanden. Ovanstående funktion är skriven för att inte göra något om inget av de sätt det använder stöds. De flesta av dessa riktigt gamla webbläsare stöder inte getElementById-metoden för att hänvisa HTML heller och så en enkel om (! document.getElementById) returnerar falsk; högst upp i någon av dina funktioner som gör sådana samtal skulle också vara lämplig. Naturligtvis är många som skriver JavaScript inte så hänsynsfull till dem som fortfarande använder antika webbläsare och så dessa användare måste vänja sig att se JavaScript-fel på nästan varje webbsida de besöker nu.

Vilka av dessa olika sätt använder du för att bifoga bearbetning på din sida som ska köras när dina besökare klickar på något? Om du gör det närmare exemplen längst upp på sidan än exemplen längst ner på sidan är det kanske tid du funderade på att förbättra hur du skriver din onclick-behandling för att använda en av de bättre metoder som presenteras längre ner på sida.

När du tittar på koden för händelsen lyssnaren över webbläsare kommer du att märka att det finns en fjärde parameter som vi ringde UC, vars användning inte är uppenbar från den tidigare beskrivningen.

Webbläsare har två olika beställningar där de kan behandla händelser när händelsen utlöses. De kan arbeta från utsidan och inåt från

• uC = sant att bearbeta under infångningsfasen
• uC = falskt att bearbeta under bubbelfasen.

Så där det finns flera andra taggar som är lindade runt den som händelsen utlöste på fångningsfasen körs först med den yttersta taggen och flyttar in mot den som utlöste händelsen och sedan när taggen som händelsen var kopplad till har bearbetats så vänder bubbelfasen processen och går tillbaka ut igen.

Internet Explorer och traditionella evenemangshanterare bearbetar alltid bubbelfasen och aldrig fångningsfasen och börjar därför alltid med den mest specifika taggen och arbeta utåt.

Så med evenemangshanterare:

xx