Hoe u JavaScript in uw webpagina kunt scheiden

Wanneer u voor het eerst een nieuw JavaScript schrijft, is de eenvoudigste manier om het in te stellen de JavaScript-code in te sluiten rechtstreeks op de webpagina zodat alles op één plek staat terwijl u het test om het te laten werken Rechtsaf. Evenzo, als u een vooraf geschreven script in uw website invoegt, kunnen de instructies u vertellen om delen of het hele script in de webpagina zelf in te sluiten.

Dit is prima om de pagina in te stellen en in de eerste plaats naar behoren te laten werken, maar zodra uw pagina naar behoren werkt, kunt u de pagina verbeteren door JavaScript uit te pakken in een extern bestand, zodat uw pagina-inhoud in de HTML niet zo rommelig is met niet-inhoudsitems zoals JavaScript.

Als u alleen JavaScripts kopieert en gebruikt die door andere mensen zijn geschreven, kunnen hun instructies over het toevoegen van hun script aan uw pagina mogelijk hebben geresulteerd in het hebben van een of meer grote delen van JavaScript is eigenlijk ingebed in uw webpagina zelf en hun instructies vertellen u niet hoe u deze code van uw pagina naar een apart bestand kunt verplaatsen en toch over JavaScript beschikt werk. Maak je echter geen zorgen, ongeacht welke code de JavaScript die je op je pagina gebruikt, je kunt de JavaScript eenvoudig verplaatsen van uw pagina en stel het in als een afzonderlijk bestand (of bestanden als u meer dan één stuk JavaScript in de pagina heeft ingebed). Het proces om dit te doen is altijd hetzelfde en kan het beste worden geïllustreerd met een voorbeeld.

Laten we eens kijken hoe een stuk JavaScript eruit zou kunnen zien wanneer het in uw pagina is ingesloten. Uw werkelijke JavaScript-code zal verschillen van die in de volgende voorbeelden, maar het proces is in alle gevallen hetzelfde.

Uw ingesloten JavaScript moet er ongeveer uitzien als een van de bovenstaande drie voorbeelden. Natuurlijk zal uw daadwerkelijke JavaScript-code verschillen van de getoonde, maar het JavaScript zal waarschijnlijk worden ingesloten in de pagina met behulp van een van de bovenstaande drie methoden. In sommige gevallen kan uw code de verouderde gebruiken taal = "javascript" in plaats van type = "text / javascript" in dat geval wilt u misschien eerst uw code actueler maken door het taalkenmerk te vervangen door het type één.

Voordat u JavaScript in een eigen bestand kunt uitpakken, moet u eerst de te extraheren code identificeren. In alle drie de bovenstaande voorbeelden moeten twee regels werkelijke JavaScript-code worden geëxtraheerd. Uw script zal waarschijnlijk veel meer regels bevatten, maar kan gemakkelijk worden geïdentificeerd omdat het dezelfde plaats op uw pagina inneemt als de twee JavaScript-regels die we hebben in de bovenstaande drie voorbeelden gemarkeerd (alle drie de voorbeelden bevatten dezelfde twee regels JavaScript, alleen de container eromheen is iets anders).

1. Het eerste wat u moet doen om JavaScript in een afzonderlijk bestand te extraheren, is een teksteditor openen en toegang krijgen tot de inhoud van uw webpagina. Vervolgens moet u het ingesloten JavaScript zoeken dat wordt omgeven door een van de codevariaties die in de bovenstaande voorbeelden worden weergegeven.
2. Nadat u de JavaScript-code hebt gevonden, moet u deze selecteren en naar uw klembord kopiëren. In het bovenstaande voorbeeld wordt de te selecteren code gemarkeerd. U hoeft geen scripttags of optionele opmerkingen te selecteren die rond uw JavaScript-code kunnen verschijnen.
3. Open een ander exemplaar van uw teksteditor (of een ander tabblad als uw editor het openen van meer dan één bestand tegelijk ondersteunt) en plaats daar de JavaScript-inhoud.
4. Selecteer een beschrijvende bestandsnaam voor uw nieuwe bestand en sla de nieuwe inhoud op met die bestandsnaam. Met de voorbeeldcode is het doel van het script om uit frames te breken, dus een geschikte naam zou kunnen zijn framebreak.js.
5. Dus nu we het JavaScript in een apart bestand hebben, gaan we terug naar de editor waar we de originele pagina-inhoud hebben om de wijzigingen daar aan te brengen om naar de externe kopie van het script te linken.
6. Omdat we het script nu in een afzonderlijk bestand hebben, kunnen we alles tussen de scripttags in onze oorspronkelijke inhoud verwijderen, zodat de label.
7. De laatste stap is om een ​​extra kenmerk toe te voegen aan de script-tag om aan te geven waar het externe JavaScript kan worden gevonden. We doen dit met behulp van een src = "bestandsnaam" attribuut. Met ons voorbeeldscript zouden we src = "framebreak.js" specificeren.
8. De enige complicatie hierbij is als we hebben besloten om de externe JavaScripts op te slaan in een aparte map van de webpagina's die ze gebruiken. Als u dit doet, moet u het pad van de webpagina naar de JavaScript-map voor de bestandsnaam toevoegen. Als de JavaScripts bijvoorbeeld worden opgeslagen in een js map in de map met onze webpagina's die we nodig zouden hebben src = "js / framebreak.js"

Dus hoe ziet onze code eruit nadat we JavaScript hebben gescheiden in een apart bestand? In het geval van ons voorbeeld JavaScript (ervan uitgaande dat JavaScript en HTML zich in dezelfde map bevinden) staat onze HTML op de webpagina nu:

We hebben ook een apart bestand met de naam framebreak.js dat bevat:

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

Uw bestandsnaam en bestandsinhoud zullen veel verschillen van die omdat u hebt uitgepakt JavaScript is ingebed in uw webpagina en heeft het bestand een beschrijvende naam gegeven op basis van wat het doet. Het daadwerkelijke extractieproces is echter hetzelfde, ongeacht de regels die het bevat.

Hoe zit het met die andere twee regels in elk van de voorbeelden twee en drie? Welnu, het doel van die regels in voorbeeld twee is het JavaScript te verbergen voor Netscape 1 en internet Explorer 2, die niemand meer gebruikt en daarom zijn die lijnen niet echt nodig in de eerste plaats. Als u de code in een extern bestand plaatst, wordt de code verborgen voor browsers die de scripttag niet effectiever begrijpen dan hoe dan ook in een HTML-commentaar. Het derde voorbeeld wordt gebruikt voor XHTML-pagina's om validators te vertellen dat JavaScript moet worden behandeld als pagina-inhoud en niet om het te valideren als HTML (als u een HTML-doctype gebruikt in plaats van een XHTML, weet de validator dit al en dus zijn die tags niet nodig zijn). Met het JavaScript in een apart bestand is er geen JavaScript meer op de pagina dat door validators moet worden overgeslagen en dus zijn die regels niet langer nodig.

Een van de handigste manieren waarop JavaScript kan worden gebruikt om functionaliteit aan een webpagina toe te voegen, is om een ​​soort verwerking uit te voeren als reactie op een actie van uw bezoeker. De meest voorkomende actie waarop u wilt reageren, is wanneer die bezoeker op iets klikt. De gebeurtenishandler waarmee u kunt reageren op bezoekers die op iets klikken, wordt genoemd bij klikken.

Wanneer de meeste mensen voor het eerst denken aan het toevoegen van een onclick-gebeurtenishandler aan hun webpagina, denken ze er meteen aan deze toe te voegen aan een label. Dit geeft een stukje code dat er vaak uitziet als:

Dit is de mis manier om onclick te gebruiken, tenzij je een echt zinvol adres in het href-kenmerk hebt, zodat mensen zonder JavaScript ergens naartoe worden overgedragen wanneer ze op de link klikken. Veel mensen laten ook de "return false" uit deze code weg en vragen zich vervolgens af waarom de bovenkant van de huidige pagina altijd wordt geladen nadat het script is uitgevoerd (dat is wat de href = "#" de pagina vertelt te doen, tenzij false wordt geretourneerd door alle gebeurtenishandlers. Natuurlijk, als je iets betekenisvols hebt als de bestemming van de link, wil je daar misschien naartoe nadat je de onclick-code hebt uitgevoerd en dan heb je de "return false" niet nodig.

Wat veel mensen zich niet realiseren, is dat de onclick-gebeurtenishandler kan worden toegevoegd ieder HTML-tag op de webpagina om te communiceren wanneer uw bezoeker op die inhoud klikt. Dus als je iets wilt uitvoeren wanneer mensen op een afbeelding klikken, kun je het volgende gebruiken:

Als je iets wilt uitvoeren wanneer mensen op tekst klikken, kun je het volgende gebruiken:

wat tekst

Natuurlijk geven deze niet de automatische visuele aanwijzing dat er een reactie zal zijn als uw bezoeker erop klikt zoals een link doet, maar je kunt die visuele aanwijzing eenvoudig genoeg zelf toevoegen door de afbeelding of reeks te stylen op gepaste wijze.

Het andere ding om op te merken over deze manieren om de onclick-gebeurtenishandler te koppelen, is dat deze niet vereist zijn "return false" omdat er geen standaardactie zal plaatsvinden als er op het element wordt geklikt gehandicapt.

Deze manieren om de onclick te bevestigen, zijn een grote verbetering van de slechte methode die veel mensen gebruiken, maar het is nog lang niet de beste manier om het te coderen. Een probleem met het toevoegen van onclick met behulp van een van de bovenstaande methoden is dat het nog steeds uw JavaScript combineert met uw HTML. bij klikken is niet een HTML-kenmerk, het is een JavaScript-gebeurtenishandler. Om onze JavaScript van onze HTML te scheiden om de pagina eenvoudiger te kunnen onderhouden, moeten we die onclick-verwijzing uit het HTML-bestand halen in een afzonderlijk JavaScript-bestand waar het hoort.

De eenvoudigste manier om dit te doen, is door de onclick in de HTML te vervangen door een ID kaart dat maakt het gemakkelijk om de gebeurtenishandler aan de juiste plek in de HTML te koppelen. Dus onze HTML kan nu een van deze verklaringen bevatten:

 wat tekst

We kunnen het JavaScript vervolgens coderen in een afzonderlijk JavaScript-bestand dat aan de onderkant van de pagina is gekoppeld of die bovenaan de pagina staat en waar onze code zich bevindt in een functie die zelf wordt genoemd nadat de pagina is geladen. Ons JavaScript om de event-handlers te koppelen ziet er nu als volgt uit:

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

Een ding om op te merken. U zult merken dat we altijd onclick volledig in kleine letters hebben geschreven. Wanneer u de verklaring codeert in hun HTML, ziet u dat sommige mensen deze als onClick schrijven. Dit is verkeerd omdat de namen van JavaScript-eventhandlers allemaal kleine letters zijn en er geen handler is zoals onClick. U kunt ermee wegkomen als u JavaScript rechtstreeks in uw HTML-tag opneemt, omdat HTML niet hoofdlettergevoelig is en de browser het aan de juiste naam voor u toewijst. U kunt niet wegkomen met het verkeerde hoofdlettergebruik in uw JavaScript zelf, omdat het JavaScript hoofdlettergevoelig is en er in JavaScript niet zoiets bestaat als onClick.

Deze code is een enorme verbetering ten opzichte van de vorige versies, omdat we nu het evenement aan het juiste element in onze HTML koppelen en we het JavaScript volledig gescheiden van de HTML hebben. We kunnen dit echter nog verder verbeteren.

Het enige probleem dat overblijft is dat we slechts één onclick-gebeurtenishandler aan een specifiek element kunnen koppelen. Moeten we op enig moment een andere onclick-gebeurtenishandler aan hetzelfde element koppelen, dan wordt de eerder gekoppelde verwerking niet langer aan dat element gekoppeld. Wanneer u verschillende scripts aan uw webpagina toevoegt voor verschillende doeleinden, is er ten minste een mogelijkheid dat twee of meer van hen misschien enige verwerking willen leveren die moet worden uitgevoerd wanneer hetzelfde element is geklikt. De rommelige oplossing voor dit probleem is om te bepalen waar deze situatie zich voordoet en om de verwerking die moet worden bijeengeroepen te combineren tot een functie die alle verwerking uitvoert.

Hoewel dit soort botsingen minder vaak voorkomen bij onclick dan bij onload, is het niet de ideale oplossing om de botsingen vooraf te identificeren en te combineren. Het is helemaal geen oplossing wanneer de feitelijke verwerking die aan het element moet worden gekoppeld in de loop van de tijd verandert, zodat er soms één ding is om te doen, soms een andere en soms beide.

De beste oplossing is om te stoppen met het volledig gebruiken van een gebeurtenishandler en in plaats daarvan een JavaScript-gebeurtenislistener te gebruiken (samen met de overeenkomstige attachEvent voor Jscript- omdat dit een van die situaties is waarin JavaScript en JScript verschillen). We kunnen dit het gemakkelijkst doen door eerst een addEvent-functie te maken die een gebeurtenislistener of bijlage toevoegt, afhankelijk van welke van de twee de taal die wordt uitgevoerd ondersteunt;

functie addEvent (el, eType, fn, uC) {if (el.addEventListener) {el.addEventListener (eType, fn, uC); waar terugkomen; } anders if (el.attachEvent) {return el.attachEvent ('on' + eType, fn); } }

We kunnen nu de verwerking koppelen die we willen laten plaatsvinden wanneer op ons element wordt geklikt met behulp van:

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

Het gebruik van deze methode voor het koppelen van de te verwerken code wanneer op een element wordt geklikt, betekent dat het maken van een andere addEvent-aanroep om een ​​andere functie toe te voegen worden uitgevoerd wanneer op een specifiek element wordt geklikt, wordt de eerdere verwerking niet vervangen door de nieuwe verwerking, maar kunnen in plaats daarvan beide functies worden rennen. We hoeven bij het aanroepen van een addEvent niet te weten of we al een functie aan de hebben gekoppeld element dat wordt uitgevoerd wanneer erop wordt geklikt, wordt de nieuwe functie uitgevoerd met en functies die eerder waren gehecht.

Als we de mogelijkheid nodig hebben om functies te verwijderen uit wat wordt uitgevoerd wanneer op een element wordt geklikt, kunnen we een maken bijbehorende deleteEvent-functie die de juiste functie aanroept voor het verwijderen van een gebeurtenislistener of als bijlage evenement?

Het enige nadeel van deze laatste manier om de verwerking toe te voegen, is dat echt oude browsers deze relatief nieuwe manieren voor het koppelen van gebeurtenisverwerking aan een webpagina niet ondersteunen. Er zouden nu maar weinig mensen die dergelijke verouderde browsers gebruiken om ze te negeren in wat J (ava) Script schrijven we los van het schrijven van onze code op zo'n manier dat het geen grote aantallen fouten veroorzaakt berichten. De bovenstaande functie is geschreven om niets te doen als geen van beide manieren wordt ondersteund. De meeste van deze echt oude browsers ondersteunen ook de getElementById-methode om naar HTML te verwijzen niet en dus een eenvoudige if (! document.getElementById) return false; bovenaan elk van uw functies die dergelijke oproepen doen, zou ook geschikt zijn. Natuurlijk zijn veel mensen die JavaScript schrijven niet zo attent van degenen die nog steeds antieke browsers gebruiken en dus die gebruikers moeten gewend raken aan het zien van JavaScript-fouten op bijna elke webpagina die ze nu bezoeken.

Welke van deze verschillende manieren gebruikt u om verwerking toe te voegen aan uw pagina om te worden uitgevoerd wanneer uw bezoekers op iets klikken? Als de manier waarop je het doet dichter bij de voorbeelden bovenaan de pagina staat dan bij die voorbeelden onderaan de pagina, dan is het misschien tijd die je hebt overwogen om de manier waarop je je onclick-verwerking schrijft te verbeteren om een ​​van de betere methoden te gebruiken die hieronder worden gepresenteerd bladzijde.

Kijkend naar de code voor de gebeurtenisbrowser voor meerdere browsers, zult u merken dat er een vierde parameter is die we hebben aangeroepen uC, waarvan het gebruik niet duidelijk is uit de voorgaande beschrijving.

Browsers hebben twee verschillende volgorde waarin ze gebeurtenissen kunnen verwerken wanneer de gebeurtenis wordt geactiveerd. Ze kunnen van buiten naar binnen werken vanaf de

• uC = waar te verwerken tijdens de vastlegfase
• uC = false om te verwerken tijdens de bellenfase.

Dus waar er verschillende andere tags zijn gewikkeld rond degene die het evenement werd geactiveerd op de vastlegfase die als eerste begint, beginnend met de buitenste tag en naar binnen naar degene die de gebeurtenis heeft geactiveerd en nadat de tag waaraan de gebeurtenis was bevestigd is verwerkt, keert de bellenfase het proces om en gaat terug nog een keer.

Internet Explorer en traditionele event-handlers verwerken altijd de bellenfase en nooit de vastlegfase en beginnen dus altijd met de meest specifieke tag en werken naar buiten toe.

Dus met event handlers:

xx