JavaScript is een prima oplossing om een website te laten voldoen aan de verwachtingen van een gebruiker. Door middel van JavaScript kan de gebruiker aan de hand geleid worden bij het invoeren van informatie zonder dat er telkens post-backs uitgevoerd moeten worden voor dynamisch gedrag. Met de komst van Ajax verandert op zich weinig, behalve dat er nu de call-back aan het arsenaal is toegevoegd. Helaas is JavaScript ook een bron van problemen, voornamelijk doordat de code zich niet door een compiler laat temmen.
Helaas is Javascript ook een bron van problemen, voornamelijk door het ontbreken van een compiler
Om succesvol JavaScript toe te passen in Asp.Net projecten en om die ook prettig te kunnen onderhouden is dus een aantal vaardigheden gewenst. Dit artikel gaat in op de belangrijkste mogelijkheden om het gebruik van JavaScript toch een positieve bijdrage te laten leveren aan uw projecten.
JavaScript is een niet zo strikte scripttaal: de broncode wordt niet door een compiler gecontroleerd en ook wordt geen semantische check uitgevoerd, voordat de code in de browser uitgevoerd wordt.
Dit betekent dus dat pas bij het uitvoeren van de JavaScript, meestal zelfs al bij het openen van de webpagina, aanwezige JavaScript-fouten zichtbaar worden (zie figuur 1). Er wordt soms een regelnummer getoond maar helaas geeft ook dit vaak niet voldoende handvaten om de code te repareren. Verdere uitvoer van de pagina kan zelfs onmogelijk zijn.
Fig. 1: Welk object wordt eigenlijk hier bedoeld?
Gelukkig is een aantal oplossingen aanwezig om toch succesvol JavaScript aan ASPX-pagina’s toe te voegen en te debuggen.
Wat Visual Studio kan aanbieden is het debuggen van JavaScript, compleet met breakpoints en gebruik van het Immediate window. De ontwikkelaar moet er dan wel voor zorgen dat de JavaScript code in aparte bestanden opgenomen wordt. We kijken eerst naar de ASPX pagina, daarna naar de JavaScript.
Neem in het HTML head-element van de ASPX pagina de volgende regel op (bv. na de
):
src="mijnjavascriptfuncties.js"
type="text/javascript">
Zie ook onderstaande figuur.

Fig. 2: Vanuit de ASPX pagina verwijzen naar JavaScript
Omdat de JavaScript-code dus in een apart bestand wordt ondergebracht, zal dit wel een (minimale) impact hebben op de laadtijd van de pagina.
Tevens moet in de gebruikte IE browser een instelling gewijzigd worden. Ga hiervoor naar IE Explorer | Menu | Tools | internet options | Tabblad Advanced en dan naar het kopje Browsing. Vink ‘Disable script debugging (Internet Explorer)’ en ‘Disable script debugging (Other)’ uit (zie figuur 3). Hierdoor kan Visual Studio als debugger gaan optreden. Kijk voor meer opties ook eens op http://www.stanford.edu/services/ess/pc/docs/ie/ie_6.html . Zo kan het cachen van pagina’s in de browser uitgezet worden en wordt dus altijd de laatst gecompileerde versie getoond.

Fig. 3: Forceer het gebruik van een JavaScript debugger
Schrijf nu in ‘mijnjavascriptfuncties.js’ de gewenste JavaScript methoden en roep deze aan. Bijvoorbeeld:
onchange="javascript:setPageIsChanged()">
Het is nu mogelijk om de debugger de breakpoints te laten uitvoeren. Dus het is ook mogelijk om de flow en de inhoud van variabelen te testen.
Toch nog code in de ASPX nodig?
Als onverhoopt toch JavaScript code uitgevoerd moet worden in de ASPX pagina (bv. in de events van een control of bv. via RegisterStartupScript of RegisterClientScriptBlock), dan is het mogelijk om om ook dit beperkt te debuggen. JavaScript heeft een functie genaamd ‘debugger;’ waarmee geforceerd wordt dat Visual Studio op die positie in de code halt houdt. Dit is een handige optie voor noodgevallen maar vergeet niet de methodeaanroep weer uit de code te halen na gebruik.
Basisafspraken voor uitvoer van JavaScript code
Bij het programmeren van JavaScript code wordt meestal gereageerd op Events. Het is onverstandig om hierbij gebruik te maken van het in cascade uitvoeren van verschillende methoden. Dit treedt op als het ene control het andere control wijzigt waarbij dan een event van dat tweede control afgaat, enz. De onderhoudbaarheid holt hiermee gaandeweg de projecten helaas snel achteruit.
Eerst is het verstandig om altijd onderaan de ASPX pagina een extra JavaScript methode aanroep op te nemen. Deze wordt bij iedere pageload op de client uitgevoerd. Zo kan eventueel de user interface nog aangepast worden voordat de gebruiker met de invoer verder gaat.

Fig. 4: Minimale uitvoer van JavaScript in een ASPX pagina
(PS: De CDATA verwijzing is opgenomen om aan de XHtml standaard te voldoen.)
Als extra opmerking kan nog vermeld worden dat tegenwoordig ook gereageerd kan worden op het verwerkt zijn van alle DOM elementen. Zodoende kunnen bv. menu’s al eerder script gaan uitvoeren. Kijk hiervoor op: http://tanny.ica.com/ica/tko/tkoblog.nsf/dx/domcontentloaded-event-for-browsers .
Aan het uitvoeren van client-side gedrag valt ook wel wat te verbeteren. Het is verstandig om één basismethode te schrijven welke slechts een parameter accepteert: de identificatie van de aanroepende control. Deze methode wordt dan overal aangeroepen waar een wijziging van een control invloed heeft op andere controls. Binnen die hoofdmethode zal dan een verdere afsplitsing plaats vinden om uit te zoeken hoe op de wijziging gereageerd moet worden. Waak er wel voor om geen inhoudelijke logica in die hoofdmethode te stoppen. Alle niet-flow logica moet dus in aparte functies geschreven worden.
Javascript functies met dezelfde interface kunnen elkaar wegdrukken
Let er tevens op dat in JavaScript functies met dezelfde interface (naam, parameters) elkaar kunnen wegdrukken. Van deze feature kan soms ook goed gebruik gemaakt worden, maar het kan zich ook tegen je keren. Omdat de volgorde van wegdrukken door de volgorde van het inlezen van script bestanden geforceerd wordt, dien je duidelijk met commentaar in de ASPX bestanden aan te geven hoe de bestandsvolgorde moet zijn.
Defensiever JavaScript coderen
Ik ben geen voorstander van defensieve broncode. Broncode kloppen voor problemen welke met precondities en postcondities afgevangen kunnen worden, moet voorkomen worden en slechts assertions genereren. Toch moet bij JavaScript wel een defensieve aanpak gekozen worden.
Omdat JavaScript pas bij executie de uitvoerbaarheid controleert kan een ontwikkelaar verrast worden door vervelende bijwerkingen. Kijk maar eens naar de volgende code:
if (document.getElementById('foutieveControlNaam').
style.display == 'block') {;}
Bij het uitvoeren van bovenstaande code zal een foutmelding gegeven worden door de opgegeven foutieve naam. De style wordt opgevraagd van een control die niet aangetroffen wordt en dus zal een aanroep van ‘null’ plaatsvinden.
Het is een eenvoudige verbetering van de code om hetzelfde code als volgt te coderen:
var controlGewenst =
document.getElementById('foutieveControlNaam');
if (controlGewenst == null)
{
alert('foutieveControlNaam niet gevonden.');
return;
}
controlGewenst.style.display = 'block';
Nu zal de ‘alert()’ uitgevoerd worden zodat de voortgang niet onderbroken wordt. Overigens werkt de dubbele & net als in C#. Het rechter lid wordt alleen uitgevoerd als het linker de waarde True vertegenwoordigt.
Bij Atos Origin BAS gebruiken wij overigens een codeerstandaard om bij boolean vergelijkingen de and’s en or’s over meerdere regels te verdelen (de positie van de ‘&&’ is vooraan op de aparte regel gesteld) en rijk aan haakjes. Hoewel dit voor mij toch ook even wennen was, blijkt dit zeer effectief te zijn om de vergelijking te doorgronden. De leesbaarheid laat zo geen mogelijkheid tot discussie meer toe.
De bovenstaande check kan dus ook als basis gebruikt worden om bij methodes de inputparameters te testen, voordat deze toegepast worden in de methode. Test dus met code je pre- en postcondities. Ook dit is een goede codeerstandaard.
Aanpassen van JavaScript en ASPX HTML zonder hercompileren van het Visual Studio project
Mocht tijdens het debuggen toch blijken dat JavaScript code of opmaak in de HTML aangepast moet worden, dan is het soms niet nodig om de sessie te stoppen en het totale project te hercompileren (wat veel tijd kost). Pas de JavaScript broncode of HTML aan indien uw Visual Studio instellingen dit toestaan. Sla de wijzigingen op en forceer en het herladen (Control-F5 in Internet Explorer. F5 is soms niet voldoende). De nieuwe inhoud is nu zichtbaar.
Breakpoint cursor gebruiken voor sprongen in broncode
Het laatste redmiddel tijdens een debugsessie bij foutieve code kan het stappen over die foutieve code heen zijn. De foutieve code wordt dan niet uitgevoerd op dat moment in de sessie.
Zet hiervoor een breakpoint vlak voor de foutieve code. Als de debugger stopt op de betreffende regel, dan zal een gele pijl zichtbaar worden als cursor (zie figuur 5). Nu is het mogelijk om de cursor te verslepen met de muis. Daarmee wordt dus in het verloop van de uitvoering ingegrepen.

Fig. 5: De gele pijl is te verslepen...
Zo kan zojuist uitgevoerde code nogmaals doorlopen worden. Maar als de cursor verplaatst wordt tot een punt na foutieve code, dan zal die foutieve JavaScript genegeerd worden. Pas hierbij wel op, de zo geforceerde werking van de applicatie kan gaan afwijken van werkelijke werking.
Conclusie
Het gebruik van JavaScript kan een welkome aanvulling op de Asp.Net server-side code zijn, maar met de voordelen komt ook een groot aantal risico’s mee. Gelukkig worden ontwikkelaars voldoende geholpen met tooling, codeerstandaarden en werkprocedures om deze risico’s zo klein mogelijk te houden.