Hey! Bezoek

In een vorige post schreef ik over het stoeien met de Google Maps API. Nu is het voor mijn werk niet meer nodig om me te verdiepen in de geheimen van de Google Maps code. Het project waarvoor dat van belang was, de vernieuwde corporate website, is uitgesteld tot na de geplande fusie. Eerlijk gezegd ben ik er niet rouwig om. De druk om binnen een (te) korte tijd een sexy stukje functionaliteit op te leveren kan ik missen als kiespijn.

Het kwaad is echter geschied. Ik ben behoorlijk verslaafd geraakt aan het knutselen met Google Maps functionaliteit. Voor mijn kids website bouw ik daarom vrolijk verder aan een Google Maps mashup met tips voor een dagje uit.

Ik ben redelijk tevreden met de versie die ik uit mijn toetsenbord gewrongen heb. Ondanks dat ik de afgelopen dagen een stevig gevecht moest leveren met mijn Google Maps pagina. In retrospect niet zozeer met Google Maps functies, maar meer met de pagina layout. Vanuit het oogpunt van usability leek het een goed plan om eens te kiezen voor een liquid layout. Een design waarin een percentage van het scherm gevuld wordt door de kaart en de rest door elementen als banner, voettekst en navigatie. Deze pagina - Solar Maps San Francisco - vormde mijn bron van inspiratie. De Helsinki openbaar vervoer mashup is trouwens ook behoorlijk vloeibaar.

Ai! Dat blijkt toch te hoog gegrepen voor een middelmatig codeerkonijn als ikzelf. Een liquid design zorgt voor een stortvloed aan technische opstakels. Om een paar zaken aan te halen: een pixel perfecte positionering in zowel Internet Explorer 6 en 7 als Firefox is een probleem. En Opera gedraagt zich uitermate bokkig.

Voorlopig toch maar op safe spelen met een pagina met vaste afmetingen.

Als het tegenzit dan ...
... kom je er na drie dagen konkelen achter dat je niet zelf de klikken op een Google Adsense blok kunt bijhouden (zonder te zondigen tegen de Google Adsense ToS). Hey, da's de primaire reden dat Google besloot om de Adsense advertenties in een externe iframe te laden. Je haalt diep adem en besluit de boel de boel te laten.

... ontdek je op een gegeven moment dat Internet Explorer het .onload event (op zowel document- als elementniveau) echt maar één keer uitvoert. Als de pagina voor de eerste keer geladen wordt. En daarna blind vertrouwt op de browser cache. Waardoor jouw javascript-code keihard in het stof bijt. Dan:

(1) ga je heel hard vloeken. Volgens mijn gelovige vrienden bij de EO een duidelijk teken van onmacht - het helpt niet echt!
(2) vervloek je de ongebreidelde arrogantie van M$ om de W3C specificaties naar eigen goeddunken te interpreteren. Volgens al mijn (on)gelovige vrienden het utieme teken van onmacht: het helpt zeer zeker niet!!!
(3) verkoop je je eigen naïviteit (lees: de gedachte dat de W3C specificaties een solide basis voor je scripts zijn) een ongenadige rotschop
(4) huil je een paar krokodillen-tranen omdat je zo'n ongelofeloze droplul bent die - tegen beter weten in - zijn tijd verdoet met het schrijven van cross-browser code.
(5) haal je diep adem / je schouders op om als de donder een workaround te verzinnen.

Als het meezit dan ...
... krijg je een joppie aangeboden om tegen het minimum jeugdloon kliko's achter de gemeentelijke vuilniswagen te hangen en kom je elke dag om half vijf zonder een geplaagde geest thuis van je werk ...

... kom je tot de conclusie dat het schrijven van onobstrusive javascript eigenlijk ontzettend simpel is door mee te liften op de codebase van libraries als Ben Nolan's behaviour.js.

De achtergrond
Met Company of Kids ben ik voorzichtig aan het nadenken over een vorm van samenwerking. Om te beginnen ben ik door Company of Kids gevraagd om een flash banner op Leuk voor kids te zetten. Om vervolgens maar eens een dooddoener-konijn uit de hoge hoed te trekken: meten is weten.

En ik wil graag weten hoe vaak de banner van Company of Kids aangeklikt wordt.

Het idee
Oké, dat is niet zo spannend zou je zeggen. Hang een javascript event handler aan het flash object en laat deze event handler een serverside script aanroepen dat het klik-veld van de betreffende record in de hey_hoevaak_wordt_er_op_mij_geklikt tabel met één ophoogt. Een kind kan de was doen ...

Het probleem
Een kind kan de was doen ... maar niet heus. In theorie klinkt het bovenstaande dan wel logisch, maar in de praktijk blijkt het gemakkelijker gezegd dan gedaan. Want hoewel het in Firefox niet zo'n probleem is om bij een klik op de flash banner de klikteller te updaten, werken Internet Explorer versies 6 en 7 niet mee. En aangezien het overgrote deel van de bezoekers langskomt met deze browsers en versies, MOET een en ander werken onder Internet Explorer 6+. Het probleem lijkt hem erin te zitten dat het flashfilmpje zich in de documentstructuur op de bovenste laag bevindt en derhalve het onclick event van het javascript onderschept. De banner voorzien van de wmode = transparent parameter (geopperd op de Adobe website) biedt evenmin uitkomst. Grrr. Op internet is weliswaar voldoende naslagwerk te vinden over het probleem van de layering van swf objecten in een htmlbestand, maar voor mijn specifieke situatie heb ik geen oplossing gevonden.

De oplossing
Ik kan slecht tegen mijn verlies. Dus heb ik net zolang lopen klooien totdat ik een workaround gevonden had. Toegegeven, ik betwijfel of mijn uiteindelijke fix voor het bovenstaande probleem de schoonheidsprijs verdient, maar hey ... het werkt in elk geval wel. Oké, wat heb ik dan gedaan? Door te rommelen met absolute positionering en de z-index, en daarnaast vals te spelen met de in de flashbanner geprogrammeerde doorklik naar de Company of Kids website (lees: de doorklik wordt gedaan door het javascript in plaats van de flash banner) is het gelukt om een tracking van het aantal kliks op de banner te realiseren.

Ik heb een div gebruikt en daarin een absoluut gepositioneerde afbeelding (een transparante gif) geplaatst. Daaronder laad ik een nog een div in, waarin tenslotte de flashbanner zich bevindt. Aan de transparante gif heb ik een onclick event opgehangen, die zorgt voor (1) het verhogen van de teller en (2) het laden van de achterliggende website.

De code
1. html en javascript

<div id="container-banner-cok">
  <img id="anker" src="/img/transparant-468x60.gif" />
  <div id="flashbanner">
  <script type="text/javascript">

  // <![CDATA[

  var fo = new FlashObject("pad naar flash bestand", "", "468", "60", "6", "#f0f0f0", true);
  fo.addParam("wmode", "transparent");
  fo.write("flashbanner");
  var container = document.getElementById("container-banner-cok");
  var anker = document.getElementById("anker");
  anker.style.cursor = "pointer";
  anker.onclick = function () { updateBannerClicks('cok022007'); window.open('url die geopende moet worden'); }

  // ]]>
  </script>
  </div>
</div>

2. stijlblad dingen

#container-banner-cok { width: 468px; height: 60px; display: block; background: #fff; margin: 10px 10px 10px 20px; padding: 0; z-index: 100; text-align: left; }
#anker { position:absolute; display: block; border: none; z-index: 99; width: 468px; height: 60px; margin: 0; padding: 0; }
#flashbanner { position: absolute; display: block; width: 468px; height: 60px; z-index: 0; padding: 0; margin: 0; }

Oh ja, in het bovenstaande geval heb ik gebruik gemaakt van Geoff Sterns' flash object voor het inladen van de Flash banner.

Ajax technieken. Ik moet zeggen, ik maak er redelijk vaak gebruik van. Maar net als met alcohol geldt voor Ajax: gebruik met mate! Ik doe dan ook mijn best om asynchrone javascript calls niet te pas en te onpas in mijn websites te gebruiken. Als je Ajax gebruikt kom je af en toe de mindere kanten van de techniek tegen. Dat is net zo onvermijdellijk als dat dat je de minder fraaie karaktertrekjes van je partner gaan opvallen zodra de eerste verliefdheid voorbij is.

Eén van de onhebbelijkheden van Ajax waar ik onlangs tegenaan liep is het feit dat sommige browsers moeite hebben met asynchrone calls, als de in je javascript code aangeroepen url niet uniek is. Het gevolg is vervelend: je code gedraagt zich niet zoals verwacht. Want de browser ziet dezelfde paginaaanvraag als eerder en toont de gecachte versie van de pagina. Het gedeelte van de pagina die je met behulp van Ajax wilt updaten wordt niet ververst. Grrrrrr!!!! In elk geval hebben versies 6 en 7 van Internet Explorer last hiervan. Firefox daarentegen grijpt niet naar de pagina uit het cache.

Gelukkig is de oplossing voor dit Internet Explorer probleempje simpel te implementeren. Geef je url gewoon een dummy parameter mee. Zoals een datumtijdstempel. Door bijvoorbeeld de output van var datum = new Date(); var stamp = datum.getTime(); mee te nemen in je POST of GET request zorg je voor een gegarandeerd unieke url. Hey, de dummy parameter blijft helemaal ongebruikt, maar zorgt er wel voor dat de browser denkt dat de url uniek is. En die gaat vervolgens aan het werk in plaats van de pagina uit de browsercache op het scherm te zetten.

Het stukje tekst over de image map in combinatie met een javascript dat ik een paar dagen geleden plaatste is wel erg marginaal. Ik ben van mening dat het vaak geen ruk uitmaakt of je gaat voor de quick and dirty manier. Of dat je je best doet om iets niet alleen te laten werken maar het daarnaast ook nog een beetje netjes te implementere. Wel vind ik dat het belangrijk is dat je weet hoe het beter kan.

Vandaar hier tussen de kerstbezoekjes door een ietwat verbeterde versie. Met een javascript event handler zodat het geheel (zowel in de html als in het javascript) wat cleaner oogt.

De HTML van de image map

<div id="container-locatie">
<div id="map-locatie">
<img src="img/map.gif" width="380" height="380" border="0" usemap="#mapLocatie" />
<map name="mapLocatie" id="mapLocatie">
<area id="sh1" shape="circle" coords="36,85,11" href="#" alt="Sportpark De Eendracht" />
<area id="sh2" shape="circle" coords="68,72,11" href="#" alt="Speelpark Confucius" />
<area id="sh3" shape="circle" coords="96,132,11" href="#" alt="Confuciusplein" />
<area id="sh4" shape="circle" coords="116,115,11" href="#" alt="Eengezinswoningen" />
<area id="sh5" shape="circle" coords="122,174,11" href="#" alt="Kinderboerderij Het Sloterpark" />
<area id="sh6" shape="circle" coords="175,68,11" href="#" alt="Plein ’40 – ‘45" />
<area id="sh7" shape="circle" coords="165,114,11" href="#" alt="Tram 13" />
<area id="sh8" shape="circle" coords="153,94,11" href="#" alt="Tram 7 & 14" />
<area id="sh9" shape="circle" coords="129,187,11" href="#" alt="Sloterplas"/>
</map></div>
<br class="clearme" />
</div>
</div>


En het javascript


isLocLoaded = 0;

window.onload = function () {
 var allArea = document.getElementsByTagName("area");
 for (i=0;i<allArea.length;i++) {
  var el = allArea[i];
  if (document.addEventListener) {
   el.addEventListener("click", popMe, false);
  }
  else if (el.attachEvent) {
   el.onclick=popMe;
  }
 }
}

function popMe() {
 var ouder = this.parentNode;
 var ballon = document.createElement("img");
 ballon.src = "img/"+ this.id + ".gif";
 ballon.alt = this.alt;
 ballon.style.cursor = "pointer";
 ballon.id = "hotspot-groot";
 ballon.className = "ballon-hotspot";
 ballon.style.border = "none";
 ballon.style.width = "200px";
 ballon.style.height = "140px";
 
 isLocLoaded = 1;
 arCoords = this.coords.split(",");
 var l = arCoords[0]-6;
 var t = arCoords[1];
 ballon.style.left = l + "px";
 ballon.style.top = t + "px";
 ballon.onclick = function () { isLocLoaded = 0; ballon.parentNode.removeChild(ballon); }
 ouder.appendChild(ballon);
}

Voor het geval je enigszins geïnteresseerd bent in de technische achtergrond van de image map waar ik het in mijn post over de Thuis in de Confuciusbuurt website over had, hieronder vind je de coderegels van de html, het stijlblad en het javascriptje. Naar de pagina waar één en ander in het wild te zien is klik je hierzo.

Oké, om te beginnen de html van de client side image map. Hier is van belang dat er aan de map areas een onclick javascript event handler gekoppeld is: de popupLocA functie.

<div id="container-locatie">
<div id="map-locatie">
<img src="img/locatie/hotspots-380x380.gif" width="380" height="380" border="0" usemap="#mapLocatie" />
<map name="mapLocatie" id="mapLocatie">
<area id="sh1" shape="circle" coords="36,85,11" href="#" onclick="popupLocA(1);" alt="Sportpark De Eendracht" />
<area id="sh2" shape="circle" coords="68,72,11" href="#" onclick="popupLocA(2);" alt="Speelpark Confucius" />
<area id="sh3" shape="circle" coords="96,132,11" href="#" onclick="popupLocA(3);" alt="Confuciusplein" />
<area id="sh4" shape="circle" coords="116,115,11" href="#" onclick="popupLocA(4);" alt="Eengezinswoningen" />
<area id="sh5" shape="circle" coords="122,174,11" href="#" onclick="popupLocA(5);" alt="Kinderboerderij Het Sloterpark" />
<area id="sh6" shape="circle" coords="175,68,11" href="#" onclick="popupLocA(6);" alt="Plein ’40 – ‘45" />
<area id="sh7" shape="circle" coords="165,114,11" href="#" onclick="popupLocA(7);" alt="Tram 13" />
<area id="sh8" shape="circle" coords="153,94,11" href="#" onclick="popupLocA(8);" alt="Tram 7 & 14" />
<area id="sh9" shape="circle" coords="129,187,11" href="#" onclick="popupLocA(9);" alt="Sloterpark zwembad"/>
</map>
</div>
<br class="clearme" />
</div>

Vervolgens de stijlblad code. Om de boel in Internet Explorer naar behoren te laten werken is het van belang om de image map in een container div te plaatsen. Anders verneukt IE de positionering van de afbeelding die je tijdens de onclick event in het Document Object Model invoegt:

#container-locatie { text-align: left; display: block; width: 380px; height: 380px; margin: 0 auto; padding: 0; }
#map-locatie { position: absolute; border: 1px solid #fff; margin: 0; padding: 0; }
#s1 { display: block; width: 2px; height: 2px; border: none; }
#hotspot-groot { position: absolute; z-index: 100; border: 0px solid #fff; }

En tenslotte een paar regels javascript om in het Document Object Model een afbeeldingsobject in te voegen. Het leuke (en eigenlijk de enige reden dat ik de broncode hier online zet) is dat de coords eigenschap van de hotspot wordt ingezet om de gegenereerde afbeelding automagisch op de juiste plek in te voegen:

var isLocLoaded = 0;

function popupLocA(id) {

    if (isLocLoaded == 0) {
     var parentEl = "map-locatie";
     var el = document.getElementById(parentEl);
     var ballon = document.createElement("img");
     ballon.src = "img/locatie/b" + id + ".gif";
     ballon.alt = "Thuis in de Confuciusbuurt - klik om de afbeelding te sluiten";
     ballon.style.cursor = "pointer";
     ballon.id = "hotspot-groot";
     ballon.className = "ballon-hotspot";
     ballon.style.border = "none";
     ballon.style.width = "229px";
     ballon.style.height = "170px";
     isLocLoaded = 1;

     var areaId = "sh"+id;
     var area = document.getElementById(areaId);
     var coords = area.coords;
     arCoords = coords.split(",");
     var l = arCoords[0] - 6;
     var t = arCoords[1];
     ballon.style.left = l+"px";
     ballon.style.top = t+"px";
     ballon.onclick = function () { isLocLoaded = 0; ballon.parentNode.removeChild(ballon); }
     el.appendChild(ballon);
  }
}

Net een paar dagen aan de slag bij mijn nieuwe werkgever. Omdat de websites aan de serverkant gebruik maken van asp classic betekent dit dat er gecodeerd moet worden in vbscript. In principe is daar niks mis mee. In het verleden heb ik me er in elk geval nooit aan gestoord. Nu ik gewend ben met andere scripttalen te werken realiseer ik me pas wat een beperkt lingootje vbscript is. Vijf jaar geleden stond ik niet stil bij de capriolen die je soms allemaal moet uithalen om iets werkend te krijgen met vbscript.

Neem nou arrays. Arrays zijn een functioneel onderdeel waarin vbscript errug zuinig is. Welgeteld zeven functies heb je tot je beschikking. Dan is php toch een heel stuk rijker. Niks geen gehannes. Of je nou een reeks wilt sorteren, een item aan een array wilt toevoegen of juist verwijderen, een reeks wilt randomizen of de sleutel wilt ophalen. Je kunt het zo gek niet bedenken of in php is er een functie die het werk snel en makkelijk voor je doet.

Dat wordt denk ik toch leren werken met asp.net en Visual Basic (om een beetje in de buurt te blijven van asp classic) ...

Het voordeel van het op slot gooien van de uitslagen door de KNVB is dat je min of meer gedwongen wordt om zelf wat in elkaar te flansen. Zelf denken in plaats van een deeplink hengelactie richting KNVB data. Ik had verwacht dat het erg lastig zou zijn om een uitslagenmatrix te bouwen. Maar dat valt reuze mee. Als je de beschikking heb over een tabel met wedstrijdresultaten ...


In pseudo zoiets als

Almkerk tegen NOAD32 werd 1 : 4
Brakel tegen Sleeuwijk werd 3 : 2
NEO25 tegen ASH werd 6 : 2



... ben je in business.

Er zijn vast een heleboel andere manieren waarop je een uitslagenmatrix kunt maken, en ongetwijfeld ook betere implementaties dan de mijne. Desalniettemin wil je hier toch even vermoeien met mijn oplossing.

Ik draai een query op de databasetabel met wedstrijdresultaten en sla de thuisspelende teams en uitspelende teams op in een array. De arrays voeg ik samen, haal de duplicaten eruit, gum de lege array items uit en sorteer de array. N.b. in mijn geval is het nodig om twee arrays te maken, maar als je bijvoorbeeld een tabel hebt waarin alle teams staan, kun je hiermee direct uit de voeten:

$sql_teams = "SELECT wedstrijd_team_thuis, wedstrijd_team_uit FROM $tabel";
$get_teams = mysql_query($sql_teams);
$teams_thuis = array();
$teams_uit = array();

while ($get_team = mysql_fetch_row($get_teams)) {
$team_thuis = trim($get_team[0]);
$team_uit = trim($get_team[1]);
array_push($teams_thuis, $team_thuis);
array_push($teams_uit, $team_uit);
}

$teams = array_values(array_unique(array_merge($teams_thuis,$teams_uit)));
sort($teams);


De code
Om de matrix te bouwen (hiervoor gebruik ik een tabel) schrijf ik eerst een rij met daarin alle teams. Loopen door de $teams array dus. Tot zover niks spannends.

$num_cols = count($teams);
$self = 0;

$matrix = "";
$matrix .= "$welk_team_tekst";

for ($a=0;$a < count($teams); $a++) {
$matrix .= "" . $teams[$a] . "";
}

$matrix .= "";

Voor het weergeven van de teams in de eerste kolom loop ik nogmaals door de $teams array. En om in de cellen van de tabel de uitslagen te kunnen weergeven start ik binnen deze loop nog een conditionele statement. De waarden van $teams[$a] en $teams[$x] worden gebruikt als parameters in een database query om het wedstrijdresultaat op te halen (geef me de doelpunten van de thuisploeg en de uitploeg in de wedstrijd van team A tegen team B). Als de wedstrijd in kwestie al gespeeld is wordt in de betreffende matrixcel de uitslag weergegeven. Anders blijft de cel gewoon leeg.

Als je je afvroeg wat de rol van de variable $self in de code is? $self is een teller waarmee wordt bepaald of de cel in de matrix ingevuld moet worden of dat de cel in kwestie het snijpunt is van hetzelfde team. Als dat het geval is wordt de betreffende cel van een stijlblad class voorzien (class="zelf"). In het screenshot zijn dat de cellen met een zwarte achtergrond.

for ($a=0;$a < count($teams); $a++) {


$matrix .= "";
$matrix .= "" . $teams[$a] . "";

for ($x = 0; $x < $num_cols; $x++) {
if ($self == $x) {
$matrix .= "";
}
else {
$sql_uitslagmatrix = "SELECT wedstrijd_doelpunten_team_thuis, wedstrijd_doelpunten_team_uit FROM $tabel WHERE wedstrijd_team_thuis = '$teams[$a]' and wedstrijd_team_uit = '$teams[$x]'";
$get_uitslagen = mysql_query($sql_uitslagmatrix);
if (mysql_num_rows($get_uitslagen) > 0) {
$get_uitslag = mysql_fetch_row($get_uitslagen);
$doelpunten_voor = $get_uitslag[0];
$doelpunten_tegen = $get_uitslag[1];
$matrix .= "" . $doelpunten_voor . " - " . $doelpunten_tegen . "";
}
else {
$matrix .= " ";
}

}
}

$matrix .= "";
$self++;

}

$matrix .= "";
print $matrix;


Het resultaat
Tenslotte, hieronder zie je een screendump van hetgeen de bovenstaande code uitspuugt ...

In de categorie: niet nuttig maar wel aardig:

als je ooit iets in een programmeer- of scripttaal gemaakt hebt, is het meer dan waarschijnlijk dat je de ultieme beginnersfunctie geschreven hebt: de functie die als output de tekst hello world naar het scherm schrijft.

In een lange lijst van bijna 300 script- en programmeertalen (met behulp van anderen door Wolfram Rösler samengesteld) kun je zien hoe de Hello World functie er in de betreffende programmeertaal uitziet.

Leuk!

Hello World lijst bekijken

Via een artikel op Download Squad kwam ik terecht op Curvy Corners. Op de Curvy Corners website draait het allemaal om een leuk javascript dat DIV elementen, slechts op basis van een stukje javascript, voorziet van afgeronde hoeken.

Nu zijn er natuurlijk meerdere wegen die naar Rome leiden. Zelf hanteerde ik tot nu toe een oplossing met cascading style sheets en achtergrond afbeeldingen om kaders met ronde hoeken te creëren. Een implementatie hiervan kom je tegen op één van de nullbeta diezijnz pagina's. Het werkt naar behoren, maar ik ben de eerste om toe te geven dat het niet echt een charmante manier is om je kaders te stylen.

Nee, dan is de Curvy Corners manier om kaders te voorzien van ronde hoeken een heel stuk eleganter en flexibeler. Wat heeft Curvy Corners dan te bieden? Onder andere:

– Afgeronde hoeken op basis van javascript
– Geen afbeelding noodzakelijk voor het maken van de ronde hoeken
– Ondersteuning van anti-aliasing
– Ondersteuning van een achtergrondafbeelding in het afgeronde kader (zie mijn demopagina voor een voorbeeld)
– Toepasbaar in vloeibare layouts
– Aanpasbare ronding van de hoeken

Op een demopagina heb ik even uitgeprobeerd hoe gemakkelijk het script is in de omgang. En ik ben behoorlijk enthousiast over de mogelijkheden van het Curvy Corners javascript. Snel en simpel! En mooi bovendien. Aangezien het script gebruik maakt van DOM scriptfuncties is een stukje object detectie voldoende om het script zonder sputteren te laten degraderen als de browser niet voldoet aan de eisen die curvyCorners stelt.

Check anders zelf wat het Curvy Corners script je allemaal te bieden heeft ...

Website APIs zijn soms hartstikke leuk. Ze geven je de kans om op een simpele manier aardige dingen te doen met de data van de betreffende site. Een goed voorbeeld van een website die APIs in de aanbieding hebben is del.icio.us. Zo kun je via één van de del.icio.us APIs eenvoudig een xml bestand genereren met je bookmarks. En als je eenmaal een xml-bestand hebt, staat niks je in de weg om daar verder mee te knutselen :-)

$this->usr = "gebruikersnaam";
$this->pwd = "wachtwoord";
$this->max_rows_deli = 5;
$this->url_deli = "https://" . $this->usr . ":" . $this->pwd . "@del.icio.us/api/posts/recent?count=" . $this->max_rows_deli;
$this->handle_deli = @fopen($this->url_deli, "r");

Een tijdje geleden (heeft de overname door Yahoo! hier is mee van doen?) besloten ze bij del.icio.us dat het hoog tijd was om hun APIs te wijzigen. Andere host. Versienummer in de url. Versleuteld verkeer via ssl.

Het logische gevolg: mijn stukje code die de API aanroept en vervolgens een aantal bewerkingen op het xml-outputbestand uitvoert, gaf de geest. Want del.icio.us/api/posts/recent? via http was api.del.icio.us/v1/posts/recent? via https geworden.

In eerste instantie lijkt dit niet zo'n probleem. De url even aanpassen en gaan met die handel. Want de php fopen wrapper die ik gebruik ondersteunt https:

$this->url_deli = "https://" . $this->usr . ":" . $this->pwd . "@api.del.icio.us/v1/posts/recent?count=" . $this->max_rows_deli;

Ai!! Da's blijkbaar toch te simpel gedacht. Want de php file wrappers kunnen het https protocol wel aan, maar dan moet er op de webserver wel support voor SSL zijn. En dat is momenteel niet het geval. Want we praten hier over IIS? Is er voor gebruik met Internet Information Server überhaupt wel een port van het opensource openSSL beschikbaar? Of een alternatief?

Damn! Voorlopig sta ik even met mijn mond vol tanden wat betreft api.del.icio.us ...

De IBM Developers Works website is met regelmaat te betrappen op het publiceren van handige en prima leesbare artikelen op het gebied van scripting. Zo is er een heel aardige serie over de inzet van asynchrone javascripts.

Maar ook voor een goed stukje tekst over serverside scripting ben je bij IBM Delevelops Works aan het juiste adres. Bijvoorbeeld hoe de in PHP aanwezige functies voor versleuteling te gebruiken. Een aantal zaken die in dit encryptie artikel besproken worden zullen (als het goed is) de meeste mensen bekend zijn. Voor mij was het in elk geval niet nieuw. Het stukje over public key encryptie op basis van GNU Privacy Guard (GPG) daarentegen was voor mij wel vers en interessant leesvoer.

Ik vraag me alleen af of gpg standaard te vinden is op de meeste Linux webservers ... ** start ftp proggie van keuze om eens te neuzen op een webserver **

Yep, op één van de Linux webservers waar ik bij kan is gpg gewoon aanwezig. Binnenkort eens in de praktijk uitproberen ...

Gelaagd bouwen van websites is naar mijn mening meestal een vereiste. Op optionele technologie zeker niet vertrouwen, tenzij je zeker weet dat je webknutsel in een beheerde omgeving gebruikt wordt!

Dus niet meteen tevreden achterover leunen als je hippe javascriptjes eindelijk werken. Maar je bijvoorbeeld eens afvragen wat er gebeurt als je bezoeker (bewust of onbewust) zonder javascript op de koffie komt. Als het goed is heb je dan een uitwijkplan achter de hand. Zeker als het kritische functionaliteit betreft.

Om snel te checken of er op een website überhaupt over de inzet van javascript en foutafhandeling is nagedacht, geef ik de submit knop van het contactformulier soms ongegeneerd een zwier. Meestal blèrt een javascript melding me dan toe dat één of meer verplichte velden niet zijn ingevuld. Oké. Nog eens proberen, maar dan met javascript op non-actief. Als het goed is wordt het formulier ook aan de serverkant ge-evalueerd. De ervaring leert helaas dat niet iedereen dit belangrijk vindt en wordt een leeg formulier verzonden.

Maar het kan altijd erger. Ik zal de website in kwestie of de organisatie erachter niet noemen, maar bij het versturen van het contactformulier zonder javascript breekt de achterliggende PEAR bibliotheek finaal zijn nek. Ik kan me niet voorstellen dat dit naar behoren of zelfs maar een beetje getest is. Als er gelaagd gebouwd was met de beperkingen van optionele technologie zoals javascript in het achterhoofd, dan was deze toch wel pijnlijke script crash er zeker uitgehaald.

Op forgetfoo (note: FoO rules, but may || may not be safe for work) woeden sinds vorige week redelijk intense discussies over het bestrijden van comment spam. Een post van vorige week en eentje van vandaag.

Ik moet zeggen: ik vind deze discussie meer dan interessant. Niet in de laatste plaats omdat ik zonder al teveel sores een voor-de-meeste-gevallen-veilige oplossing uit mijn hoge hoed wil kunnen toveren.

Dat is de hoofdreden dat ik een paar uur code knagen geïnvesteerd heb in het bouwen van een op plaatjes gebaseerde captcha. Zoals gezegd naar mijn mening een implementatie die behoorlijk monkey proof is.

Oké, hoe werkt het? De bestandsnamen van de plaatjes staan hardgecodeerd in de php (maar zouden natuurlijk net zo goed uit een databasetabel kunnen worden gelezen), waarna ze in een array worden geladen. De array items worden nog wat door elkaar gehusseld zodat de volgorde op het scherm random is en vervolgens wordt de client side output gebouwd.

Het contactformulier bevat het gebruikelijke verborgen veld, waar bijgehouden wordt op welke afbeelding werd geklikt toen het formulier verstuurd werd. Het id van het contactformulier is gedurende servertijd dynamisch samengesteld uit de md5 van een salt met een datumtijdstempel (beperkt tot het uur). Doordat het id van het verborgen veld elk uur wijzigt is het naar mijn mening behoorlijk bestendig tegen scripts die graag je comments- of contactformulier volplempen met aanbiedingen voor Viagra of werken aan een vergroting van het aantal inbound links.

Desalniettemin, als je denkt dat je mijn poging om een contact- of commentaarformulier te beveiligen tegen spambot-mishandeling zonder pijn of moeite een 9mm slug door het hoofd weet te jagen is hoor ik het natuurlijk graag.

Nooit te oud om bij te leren ...

De beste stuurlui ...
De afgelopen tijd heb ik me hier en daar wat minder positief uitgelaten over de code die content management systemen nogal eens produceren.

Om voor de verandering eens een stapje verder te gaan dan alleen wat wild in de rondte te bijten, ga ik zelf eens aan de slag met het knutselen van een editor. Kijken of ik het beter kan.

Te bestempelen als een typisch gevalletje het wiel opnieuw uitvinden? Niet helemaal. Ik zie het nut wel in van deze exercitie. Het is een prima praktische inventarisatie van de (on)mogelijkheden van manipulatie van het Document Object Model.

Functionaliteit
Op basis van javascript wil ik een editor in elkaar zetten die in elk geval de volgende functionaliteit biedt:

Element nodes (koppen, paragrafen, lijsten) invoegen, muteren en positioneren
Binnen een element node een tekstselectie maken en deze voorzien van opmaak. Bijvoorbeeld vetgedrukt of cursief
Binnen een element node een tekstselectie maken en deze veranderen in een link

Small print
Let op: momenteel is dit prulletje alleen geschikt voor Mozilla Firefox. Support voor de quirks van Internet Explorer volgt wellicht later. Verder moet je weten dat het geheel er niet al te gelikt uitziet. Verwacht geen verleidelijke knoppen of een consistent doorgevoerde interface. Voordat ik hier aandacht aan besteed wil mijn tijd voornamelijk steken in het bouwen van de functionaliteit.

Dat gezegd hebbend ... een allereerste beginnetje van de editor is inmiddels via deze website te misbruiken.

Bevindingen
1) Het grootste struikelblok dat ik tot nu toe ben tegengekomen is het omvormen van een tekstselectie in een link. Het is me niet gelukt om dit te doen zonder gebruik te maken van de innerHTML eigenschap van een element.

2) Ook leuk. Als een paragraaf gewijzigd wordt en de veranderingen worden teruggeschreven, verliezen de childNodes hun eventListener hooks.

Leeuwen en beren
Er zijn vast plenty blaartrekkende zaken waar ik tegenaan ga lopen bij het bouwen van de javascript editor.
Eén ding waar ik mee om dien te gaan is het muteren van een eerder ingevoegde link. In de editor selecteer je een element door erop te klikken. Maar bij een link opent dat natuurlijk standaard de url die erachter verborgen zit. Dus er moet een stukje code komen die ervoor zorgt dat de klik niet verder bubbelt dan voor het muteren van de informatie nodig is. Hmm. Misschien ook voorzien in een keuze of je de link wilt volgen of het element wilt muteren.

De Google AJAX Search API (zoals zoveel van de Google speeltjes in constante beta-fase) is aardig om eens te proberen. Vraag een API key aan en je krijgt de beschikking over een stukje code (een paar regels javascript en een verwijziging naar een stijlblad) die je in je eigen website kunt prakken. Voila. Het resultaat is asynchrone Google zoekfunctionaliteit. De API sleutel zorgt ervoor dat je tot 1000 zoekopdrachten per dag kunt doen.

Leuk. Maar het default uiterlijk van de Google Ajax zoekelementen spreekt me niet zo aan. En helaas biedt de Google Ajax Search API documentatie geen soelaas:

Styling The Search Control

Coming Soon...
Styling Search Results

Coming Soon...

Niet getreurd. Ook zonder de hulp van Google is er wel wat te veranderen. Als je het stijlblad kopieert naar een locatie binnen je web, kun je de volledige look and feel naar je eigen smaak inrichten. Ikoontjes niet mooi? Alle ico's zijn gedefinieerd als een achtergrond image. Dus gewoon het pad naar een locatie binnen je een eigen web laten wijzen en de van je keuze daar parkeren.

Een tooltje om het DOM te bekijken is wel handig om te checken waar de stijlblad-elementen nou eigenlijk naar verwijzen. Experimenteren door middel van een tijdelijk achtergrondkleurtje kan natuurlijk ook. In elk geval kun je met een paar veranderingen het standaard uiterlijk al aardig opfrissen.

check de Google Ajax Search API op emmeloord.nullbeta.net

Natuurlijk wil je graag nette webpagina's bouwen. Dan zorg je voor een pagina met semantische, gestructureerde inhoud, laat je de opmaak over aan een extern stijlblad en stop je de eventuele actie in een extern bestandje met javascript.

In het onderstaande voorbeeld kun je op een vrij nette en onopdringerige manier je (x)html tags (in dit geval linkjes) voorzien van een javascript actie. Staat javascript uit? Geen probleem. De basisfunctionaliteit (het inladen van de pagina achter de link) blijft intact.

Ik heb twee verschillende manieren gebruikt. De eerste maakt gebruik van addEventListener en de tweede van onclick = functie.

Bij het gebruik van addEventListener je moet je je code vorken, omdat Internet Explorer (hoe kan het ook anders) attachEvent gebruikt in plaats van de W3C methode addEventListener. Een tweede nadeel van de addEventListener methode is het feit dat je de bubble van de gebeurtenis moet stoppen. Met andere woorden, zonder verdere (tegen)actie wordt de javascript code die je met behulp van addEventListener aan een gebeurtenis van een tag hebt gehangen uitgevoerd, waarna de klik vrolijk verder door de DOM tree marcheert. En dus de pagina laadt die achter event.target schuilgaat. Precies wat je niet wilt. Dus ik vind eigenlijk de in de attachLinkAlternatieveManier functie beschreven manier een stukje handiger.

Om aan te geven waarover ik het heb, hieronder een voorbeeldje. Wat heb je nodig? Niet zoveel.

Een pagina met daarop een paar linkjes, waarbij van alleen van belang is dat 1 of meerdere links van de klasse klik zijn. In mijn voorbeeld wordt namelijk aan de hand van de className eigenschap van een link tag bepaald, of de event listener gebeurtenis aan de link gekoppeld moet worden ... meer lezen

Aardig kort snippet javascript om een reeks van scripts in te laden


var JSdocs = [
"main1.js",
"main2.js"
];
function loadJSFiles() {
  var head = document.getElementsByTagName("head")[0];
  for (var i=0; i<JSdocs.length; i++) {
    var script = document.createElement("script");
    script.setAttribute("type","text/javascript");
    script.setAttribute("src",JSdocs[i]);
    head.appendChild(script);
  }
}
window.onload = loadJSFiles;



Via FoO, oorspronkelijk afkomstig van Canned Laughter.

Meer dan handig: een cheat sheet om de meest belangrijke zaken die van belang zijn bij de hand te hebben. Even snel checken welke array functie je het beste kunt gebruiken of welke eigenschappen een bepaald stijlblad element ook alweer had.

Peter Freitag heeft er een hele rits van verzameld op zijn website. Je vind er sheets van onder andere (X)Html, javascript, MySQL, websafe kleuren in hex, cascading style sheets en reguliere expressies. Het is weer wat minder noodzakelijk geworden om scherp te blijven. Met een cup-a-soup en een stapeltje op A3 uitgedraaide cheats kom je er ook wel ...

Go get those cheats!

PGO: de Algemene Periodieke Keuring voor kleine mensjes. Ik geloof dat hij/zij tegenwoordig anders genoemd wil worden, maar vroeger heette die meneer of mevrouw die je tijdens je basisschoolcarriere doorlichtte de schooldokter.

Bij de GGD Eemland wordt momenteel een project opgestart waarbij ook senioren hun schokbrekers kunnen laten controleren en zich ervan kunnen laten vergewissen dat er nog voldoende profiel op de bandjes zit. Het PGO voor Ouderen dus.

Oké to the point: om een aantal mensen hiervoor te benaderen zijn er gegevens opgevraagd uit de GBA. Het bedrijf dat de uitnodigingsbrieven gaat versturen wilde bij de adressering voorletters gebruiken in plaats van de uit het GBA aangeleverde voornamen. Op zo'n moment is het handig als je ooit eens het VBA for Dummies handboek hebt doorgebladerd. Dan heb je net genoeg kennis om vies en snel een paar regels code te kloppen die het klusje klaren:


Sub voornaam_naar_voorletters()

Dim arVoornamen As Variant
Dim extractVoorletters As String
Dim Voornaam As String
Dim Voorletters As String
Dim Rij As Integer
Dim HuidigeCelWaarde As String
Dim Teller As Integer

Rij = 2

Do Until Range("A" & Rij).Value = ""
Range("A" & Rij).Select
HuidigeCelWaarde = Range("A" & Rij).Value
arVoornamen = Split(HuidigeCelWaarde, " ")
Teller = 0

Do Until Teller > UBound(arVoornamen)
Voornaam = arVoornamen(Teller)
extractVoorletters = Left(Voornaam, 1)
Voorletters = Voorletters & UCase(extractVoorletters) & ". "
Teller = Teller + 1
Loop

Range("A" & Rij).Value = Voorletters
Voorletters = ""
Rij = Rij + 1
Loop

End Sub


Twee minuten werk om te schrijven, nog een paar om te testen en 3 tellen om alle voornamen te vervangen door voorletters. Dat kan geen secretaresse tegenop typen.

Dynamische maar nikszeggende urls van het type www.mijnmuziekwinkeltje.nl/muziek.php?m=cd&type=hm&id=55 hebben me altijd al mateloos geïrriteerd. Aangezien ik nooit de moeite heb genomen om uit te zoeken hoe ik (met behulp van mod_rewrite) deze cryptische monsters het beste in beschrijvende links als www.mijnmuziekwinkeltje/cd/metal/rammstein/ om kon zetten, bleef ik ook op mijn eigen websites tegen die hatelijke query strings aankijken.

Het feit dat één van mijn sites op een Internet Information Server draait en ik van het bestaan van een oplossing voor het herschrijven van links onder IIS niet afwist droeg niet bij aan aan een probleemoplossend houding mijnerzijds.

Bij toeval stuitte ik gisteren op de IIS addon isapi rewrite. Isapi rewrite is het IIS equivalent van de Apache module mod_rewrite. En aangezien mijn hosting provider Isapi rewrite geheel en al blijkt te ondersteunen was duidelijk dat ik aan de slag moest. Het slappe excuus om het niet te doen (volgens mij kan dat niet hoor, vriendelijke links met iis) was weggevallen.

Achteraf lijkt het altijd meegevallen, maar het kostte me toch wel een paar uur om mijn scriptcode-soepje zo op smaak te brengen dat isapi rewrite het lust.Waar ik ook nog even mee geworsteld heb is het gebruik van een numerieke id in de url. Absoluut beschrijvend, maar wel zo makkelijk omdat er minder code aan te passen was. Natuurlijk zou de blogtitel als identifier symantisch geschikter zijn. Maar ook gevaarlijker. Want het wijzigen van de titel van een blogpost leidt dan mogelijkerwijs tot een 404 - niet gevonden. Bovendien waren er in de titels van mijn posts nogal wat speciale karakters, die eruit gefilterd zouden moeten worden. Uiteindelijk heb ik maar voor de (mijns inziens) meest charmante maar meteen ook meest arbeidsintensieve oplossing gekozen. Door de betreffende database-tabel te voorzien van een extra veld, gebaseerd op het titelveld. Maar dan zonder vreemde tekens en met underscores tussen de woorden.

Het resultaat? Behalve wat gemoedsrust en urls die voor bezoekers makkelijk te begrijpen zijn? Hopelijk een website die binnenkort wat beter in de smaakt valt bij Googlebot en collega's. Nu het op Apache draaiende leukvoorkids.nl nog.

Code kloppen kan wel een zekere rush geven. Tenminste, als het een beetje lukken wil. Als je een halve dag aan het zoeken bent naar een verdwaalde puntkomma wordt het plezier al snel een onsje minder. Gelukkig overkomt me dat (die puntkomma die de weg kwijt is bedoel ik) niet al te vaak en verloopt het bouwproces meestal redelijk productief.

En af en toe zelfs ronduit bevredigend. Zoals nu. Als verschillende technieken (javascript voor het om zeep helpen manipuleren van het DOM en ajax voor het zetten van een PHP sessie-variable om een client-setting van pagina naar pagina te laten reizen) harmonieus samenwerken. Zeg maar het script-equivalent van een gezin dat voor de verandering eens zonder kibbelen een dagje naar het strand gaat.

Voor het geval je je afvraag waar ik het eigenlijk over heb? Over de mogelijkheid om het bovenste deel van het scherm (de drie kolommen die altijd geladen worden) te verbergen / tonen door een klik op de tab aan de linkerkant van het scherm. Werkt naar behoren in moderne versies van de bladeraar van uw keuze. En, niet onbelangrijk aangezien het hier slechts ** blingbling ** functionaliteit betreft: indien nodig zorgt objectdetectie ervoor dat het geheel zonder morren degradeert.

Hey! Functionaliteit die echt belangrijk is hang je toch sowieso niet op aan optionele technologie. Is het wel?

De naar mijn mening handigste manier om een unobtrusive javascript aan elkaar te plakken is door gebruik te maken van DOM scripting. In combinatie met een stukje object detectie. Wordt het betreffende object ondersteund? Mooi, laat die code maar lopen. Geen support? Zorg voor een alternatieve afhandeling.

Door middel van het invoegen van een pagina-element met behulp van DOM scripting hoef je je in ieder geval geen zorgen te maken dat gebruikers wiens browsers de pensioensgerechtige leeftijd heeft bereikt met een niet-functioneel onderdeel te maken krijgen.

Een voorbeeld is zijn deze blogpagina's. Als javascript aanstaat en de browser ook nog de betreffende functionaliteit aankan (in mijn geval XMLHttpRequest en het bouwen van DOM-dingen), dan wordt er gebruik gemaakt van asynchroon geladen blog-categoriën en een javascript voortgangsbalk. En anders? Dan wordt gewoon die pagina geladen. Zonder de toeters en de bellen.

Aardig nieuws over Internet Explorer 7. Op de blog van de codeknagers die zich met de bouw van IE7 bezig houden is te lezen dat het XMLHttpRequest object in IE7 op cross-browser wijze ondersteund wordt. Dus ActiveX hoeft niet meer aan te staan om een pagina asynchroon te kunnen updaten.

Oude versies van IE moeten natuurlijk nog wel via het MSXML object worden aangesproken. Dus het duurt waarschijnlijk nog even voordat je het vorken van je code achterwege kunt laten. Het breed inzetten van Microsoft op AJAX technieken voor de functionaliteit van bijvoorbeeld Windows Live zal er wel aan ten grondslag liggen.

Na het lange tijd uitgesteld te hebben heb ik eindelijk een begin gemaakt om de php-spaghetti procedures achter nullbeta.net om te zetten naar object georiënteerde code.

Ik vraag me wel af of het de moeite loont om echt alle php code te herschrijven naar classes. Ook als dat niet het geval is, alleen al het nadenken over de inzetbaarheid van OO code is de moeite waard.

Vandaag even tijd besteed aan het wat gebruikersvriendelijker maken van de beta comment. Concreet: de comments zijn onder meer voorzien van een previewmogelijkheid.
Hier wordt de komende dagen nog wel verder aan gewerkt. In elk geval een mini editor om de spaarzaam toegestane html opmaaktags via klikkerdeklik toe te voegen te gebruiken in plaats van ze zelf te moeten coderen.

En jaaaa, ik weet dat er ongeveer een miljoen cms-achtige tooltjes zijn die je zo kunt gebruiken, maar hier op nullbeta.net is mijn motto
Waarom een out-of-the-box tool gebruiken als je de code gewoon lekker zelf kunt schrijven?

Hieronder op een rijtje gezet: thumbs up punten voor AJAX, waarom AJAX zuigt en of je toch beter voor Flash kunt kiezen in je streven naar een rich user experience. Zou je verplicht verliefd moeten worden op de techniek of kun je AJAX beter links laten liggen? Zoals wel vaak met een techniek die übersexy lijkt, is het bij nadere studie niet alles goud wat er blinkt ... meer lezen ...

Ik beschouw mezelf nou niet direct als een grote flash adept. Sterker nog, ik ben altijd erg huiverig om flashfilmpjes in websites te gebruiken. Terwijl ik de techniek erachter eigenlijk best sexy vind. De mogelijkheden die het action script programmeerlingootje biedt zijn in ieder geval indrukwekkend. Waarom dan toch niet enthousiast? Ik vermoed dat mijn aversie te maken heeft met de overvloed aan wannabe-hippe, show off introductiefilmpjes zonder duidelijke meerwaarde waarmee je nogal eens lastiggevallen wordt. Flashintrootjes waarbij de creativiteit in door het beeld vliegende logootjes en tekstblokken is gestoken en de skip flash intro optie helaas is vergeten. Aaarggh!

Zijn er dan geen situaties waarin het gebruik van Flash gepast is? Natuurlijk wel ...meer lezen