Welkom bij TheHotSeat, pseudoniem voor een Gentse freelance webontwikkelaar. Maar bovenal een blog over webdesign, webontwikkeling en (digitale) vormgeving
Een dynamisch schuifregister in code
28 jan 2009•In een vorige blogpost kon je lezen over het hoe en waarom van een schuifregister. In dit artikel vatten we de koe bij de horens en gebruiken we CSS en jQuery om een dynamisch schuifregister te maken. Voor wie op hete kolen zit: dit is het resultaat en hier vind je een iets stijlvollere variant.
In den beginne was er HTML
We starten met een eenvoudige htmlpagina: een artikel met daaronder lezersreacties. Als je de bron van die webpagina bekijkt, dan zie je dat ik de plaatsen waarnaar het register moet verwijzen heb aangeduid met een id en een class. In dit geval gaat het om twee h1-tags, maar je zou evengoed een combinatie van andere htmltags kunnen gebruiken:
<h1 id="artikel" class="registerknop">Zwart gat</h1>
<h1 id="reacties" class="registerknop">Reacties</h1>
jQuery maakt het wat pittiger
jQuery maakt voor elk element met de class ‘registerknop’ een aanduiding in het schuifregister. Hoe dat in zijn werk gaat kan je hieronder meevolgen. Tussen de code vind je heel wat uitleg, maar ook straks kom ik er nog even op terug.
$(document).ready(function(){
//bereken de paginahoogte
var pageHeight = $('body').height();
//bereken de hoogte van het browservenster
var windowHeight = $(window).height();
//lengte schuifbalk tov de paginahoogte
//de pijltjes van de scrollbar nemen ongeveer 41 pixels in beslag
var scrollBreuk = (windowHeight-41)/pageHeight;
//voor elk element dat de class registerknop meekreeg
$('.registerknop').each(function(i) {
//als het het eerste element betreft
if(i == 0) {
//maak een htmllijst aan
$('body').prepend('<ul id="schuifregister"></ul>');
}
//wat is de id van dit element
var id = $(this).attr('id');
//de positie van dit element vanaf de top van de pagina
var yPos = $(this).offset().top;
//waar de schuifbalk moet zijn om het element te zien
//Math.round zorgt voor een afgerond getal zonder decimalen
//de +3 zorgt voor een net iets hogere scrollbarpositie op Mac (is mooier)
var scrollPos = Math.round(yPos * scrollBreuk) + 3;
//voeg een list item aan de lijst toe voor het huidige element
//accesskey is de eerste letter van de id
$('#schuifregister').append('<li><a accesskey="' + id[0] + '" href="#' + id + '">' + id + '</a></li>');
//plaats het nieuwste list item op de juiste schuifbalkpositie
$('#schuifregister li:last-child').css('top', scrollPos + 'px');
});
});
Zoals je kan zien zoeken we eerst de hoogte van de schuifbalk ten opzichte van de browservensterhoogte. We trekken 41 pixels af van de hoogte van het browservenster omdat dat de ruimte is die de pijltjes van de schuifbalk zelf innemen op een Mac:
Die ingenomen hoogte varieert trouwens een beetje op Windows én de plaatsing is anders. Om goed te zijn zou je die waarde (41) dus moeten laten afhangen van het besturingssysteem van de gebruiker, maar zover heb ik het in dit voorbeeld niet gedreven. (Het kan dus zijn dat dit schuifregister niet helemaal accuraat werkt op Windows computers!)
Soit, terug naar het stukje code van hierboven: nadat we enkele vaste waarden in variabelen hebben opgeslagen, gaat het script op zoek naar elk html element met registerknop als class. Als zo’n element gevonden wordt dan wordt een htmllijst aangemaakt (ul) waarin per registerknop een list item (li) verschijnt. De htmllijst is makkelijk vorm te geven met CSS en kan ontelbaar veel list items bevatten. Zoals je kan zien in het stukje code kan je het schuifregister ook via accesskeys bedienen. (De code hiervoor is weliswaar niet waterdicht.)
De plaatsing van elk list item wordt in het voorlaatste regeltje code afgehandeld.
Plaatsing en vormgeving met CSS
Hoewel we jQuery gebruiken om de plaatsing van elk list item via CSS in te stellen, is de belangrijkste opmaak toch wel apart in een stylesheet terug te vinden. De CSS die nodig is om het schuifregister vorm te geven heb ik telkens in de head sectie van de htmlpagina geplaatst:
ul#schuifregister {
list-style: none;
}
ul#schuifregister li {
position: fixed;
font-size: .9em;
right: 0;
background: url(pijl.png) no-repeat center right;
padding-right: 15px;
text-transform: capitalize;
}
Het meest opmerkelijke stukje is hier het instellen van de fixed position. Hierdoor blijft elk list item mooi in positie staan als de schuifbalk schuift.
De andere CSS-code die ik in een externe stylesheet heb geplaatst is niet zo belangrijk voor het schuifregister op zich maar zorgt voor de opmaak van de rest van de pagina-elementen. We mogen onszelf nu trouwens wel al eens op de borst kloppen: dit is ons resultaat.
Meeschalen met het browservenster
Het komt aardig in de buurt maar mist nog iets: als de gebruiker het browservenster kleiner of groter maakt, dan klopt de aanduiding van het schuifregister niet meer. Maar met behulp van een vleugje jQuery kunnen we dit makkelijk oplossen: we gieten onze code in een functie toonRegister() die we uitvoeren wanneer het venster geschaald wordt.
Belangrijk is dat we hierbij telkens eerst het schuifregister ook verwijderen om na verloop van tijd geen honderden schuifregisters te zien. Ik schreef hier de welluidende functie verbergRegister() voor:
$(document).ready(function(){
//voer de functie toonRegister() uit als de pagina geladen is
toonRegister();
//als het browservenster geschaald wordt
$(window).resize(function(){
verbergRegister();
toonRegister();
});
//de code van hierboven in een functie gestopt
function toonRegister() {
var pageHeight = $('body').height();
var windowHeight = $(window).height();
var scrollBreuk = (windowHeight-41)/pageHeight;
(...)
}
function verbergRegister() {
//verwijder de htmllijst en hiermee het volledige schuifregister
$('#schuifregister').remove();
}
});
Dit is het resultaat. Schaal gerust je browservenster eens door de rechterbenedenhoek vast te nemen en te verslepen. Je zal zien dat de plaatsing van de aanduidingen in het schuifregister telkens mee aangepast wordt aan de nieuwe afmetingen van het venster. Nice!
Een vleugje finesse
Eigen aan blogs en dynamische websites is dat je als ontwerper niet kan voorzien hoe lang de teksten zullen zijn die je klant op zijn website plaatst. Nu lijkt het een beetje onnozel om een schuifregister te hebben op een pagina waar niet gescrold moet worden (deze bijvoorbeeld). Wat meer is: de aanduidingen zijn niet meer helemaal juist. Daarom heb ik nog een bijkomende controle toegevoegd in het stukje javascriptcode die er voor zorgt dat het schuifregister niet getoond wordt wanneer alle belangrijke elementen duidelijk zichtbaar zijn op de pagina:
function toonRegister() {
(...)
//als alles mooi zichtbaar is dan moet er geen schuifregister te zien zijn
if($('.registerknop:last').offset().top > windowHeight) {
$('.registerknop').each(function(i) {
(...)
});
}
Het resultaat
Dit is het resultaat van het experiment. Bekijk ook deze iets stijlvollere variant. In de broncode vind je nog eens alle code op een rijtje.
Het is een makkelijk aanpasbaar en stijlbaar schuifregister geworden. De gebruiker kan bovendien heel snel doorheen de pagina navigeren met behulp van accesskeys.
Ik ben benieuwd naar jullie bevindingen. Vind je zo’n schuifregister duidelijk en gebruiksvriendelijk? Of denk je dat het net verwarrend werkt?
Categorieën: Ontwerp, Ontwikkeling, jQuery, Webomgeving,
Zend Framework en jQuery formuliervalidering
2 dec 2008•Hoewel ik voldoende vertrouwd ben met php en javascript, voel ik me in de eerste plaats een ontwerper. Dat is ongetwijfeld de reden waarom ik zo hou van frameworks want als ik toch de programmeerkant opga dan laten ze me toe om snel robuuste code te schrijven. Sinds enkele maanden ben ik voor een klant intensief bezig met het Zend Framework voor php en jQuery voor javascript.
Het project waaraan ik werk maakt uitvoerig gebruik van HTML-formulieren (via Zend_Form) en dus is het valideren van de gegevens die een eindgebruiker invult een noodzaak. Een voorbeeldje van formuliervalidering vind je hieronder. Als de gebruiker op de ‘Aanmelden’ knop klikt zonder een paswoord in te vullen, dan wordt het formulier niet verzonden maar verschijnt er een boodschap op het scherm. Het paswoordveld is immers verplicht in te vullen.
Het Zend Framework zorgt voor goede validering aan de serverkant, maar ik twijfelde over hoe ik de validering zou aanpakken aan de clientkant.
Javascript en php
De meest voor de hand liggende oplossing is natuurlijk het schrijven van javascriptfuncties die de formuliervalidering aan de clientkant voor hun rekening nemen. Maar ik hou er niet van om twee keer code te schrijven met hetzelfde einddoel: één keer in php en één keer in javascript. In een project dat in de maanden na lancering ongetwijfeld nog heel wat aanpassingen zal ondergaan lijkt het me niet aangewezen om telkens zowel de php-code als de javascriptcode te moeten wijzigen wanneer er iets verandert aan een formulier.
Laat Zend_Form de validering maar doen!
Ik heb er dan maar voor gekozen om alles wat betreft formuliervalidering te laten afhandelen door het Zend Framework. Dankzij een jQuery ajax oproep naar de Zend_Form isValidPartial() functie ben ik toch in staat om een gebruiksvriendelijke en snelle validering per formulierveld op het scherm van de gebruiker te tonen.
In de indexAction() van mijn controller regelt het onderstaande stukje code de server-side validering. Niets nieuws voor wie ooit al eens Zend_Form heeft gebruikt. De isValid() functie checkt de input en geeft een foutmelding weer op het scherm van de gebruiker als die ongeldige gegevens in het formulier heeft ingebracht. Pas wanneer alle input geldig is wordt het formulier echt verzonden en de database geüpdatet.
if($this->_request->isPost()) {
$formData = $this->_request->getPost();
if($form->isValid($formData)) {
//update database
} else {
$form->populate($formData);
}
}
Het nadeel van bovenstaande code is dat de validering pas gebeurt nadat het formulier wordt verzonden. De gebruiker moet dus wachten op een paginavernieuwing alvorens te weten of zijn ingevulde gegevens geldig of ongeldig waren. ‘So nineties!’, hoor ik je roepen. Dat komt inderdaad niet overeen met de snelle responstijd die een gebruiker vandaag verwacht van een webapplicatie.
jQuery to the rescue!
jQuery zal er voor zorgen dat de ingevulde gegevens van elk veld gevalideerd worden op de server net na het invullen van het veld via een Ajax oproep. Zo weet de gebruiker meteen of het veld goed ingevuld is of niet, en dat zonder te moeten wachten op een paginavernieuwing.
jQuery roept daarvoor telkens een tweede action aan in mijn Zend Framework controller. Ik heb die validateformpartial genoemd:
public function validateformpartialAction() {
if($this->_request->isPost()) {
$formData = $this->_request->getPost();
if($form->isValidPartial($formData)) {
//update database
$this->view->result = true;
} else {
//geeft foutief ingevulde velden weer met hun foutmelding
$this->view->messages = $form->getMessages();
$this->view->result = false;
}
}
}
Het verschil zit in de aangeroepen functie: isValidPartial() laat toe om enkel het doorgegeven stukje formdata te valideren. Heb je dus een formulier dat uit 5 velden bestaat en je wil maar 1 veld valideren dan kan dat via isValidPartial(). getMessages() geeft de fouten weer per veld. (Meer informatie over getMessages vind je in de Zend Framework handleiding.)
Belangrijk is wel dat je via je javascript functie enkel json (of xml) terugkrijgt van die Zend Framework action. Je moet dus Zend_Layout en Zend_View uitschakelen voor die ene action. Dat kan makkelijk in de initAction() van je controller dankzij de AjaxContext helper:
$ajaxContext = $this->_helper->getHelper('AjaxContext');
$ajaxContext->addActionContext('validateformpartial','json')->initContext();
Alles wat je in de validateformpartialAction() als variabele aan de view meegeeft (via $this->view->variableName) wordt dan meteen door die functie als json geretourneerd. Dat maakt het makkelijk om die variabelen in jQuery op te vangen en er iets mee te doen. Zo kan je bijvoorbeeld via jQuery per veld tonen welke fout de gebruiker gemaakt heeft tijdens het invullen van het formulier.
Ter vervollediging is hier de jQuery ajax functie die de waarde van het ingevulde formulierveld doorstuurt naar de validateformpartialAction van daarnet uit de Zend Framework controller:
$.ajax({
type: "POST",
//dataString is een string in dit formaat: &naam=johnny&beroep=bouwvakker
//je geeft dus de value van alle ingevulde formuliervelden die je wil valideren mee
data: $dataString,
//baseUrl bevat het pad naar je webapplicatie
url: baseUrl + "/controllernaam/validateformpartial",
dataType: "json",
//showSpinner toont een grafisch element dat de gebruiker er op wijst dat er iets aan het gebeuren is
beforeSend: function(){ showSpinner(); },
//handleResponse verwerkt de teruggekregen json data en toont de gebruiker het resultaat van de validering
//hideSpinner() verbergt het grafische element
success: function(json){ handleResponse(json); hideSpinner(); },
});
That’s it. Door de vele requests naar de server is het misschien niet de meest aangewezen manier om formuliervalidering te doen voor grootschalige webapplicaties, maar voor het project waar ik aan werk is het zeker voldoende. Het systeem zal zelfs op hoogdagen nooit door meer dan 100 gebruikers tegelijk gebruikt worden.
Het grote voordeel is dat de formvalidering overgelaten wordt aan Zend_Form. Eén regeltje wijzigen in je Form class is dus voldoende om zowel je formulier, de ajaxvalidering als de php validering up-to-date te brengen. Geen dubbel javascript valideringswerk dus. Het maakt mijn applicatie een stuk makkelijker te onderhouden.
Categorieën: Ontwikkeling, jQuery, PHP, Zend Framework,
Over 
TheHotSeat is Thomas Byttebier, freelance webontwikkelaar en grafisch ontwerper.
Op deze website blog ik over alles wat met webdesign en digitale vormgeving te maken heeft. Meer informatie over mij.
RSS Feed TheHotSeatLaatste blog posts
- Upgraden naar ExpressionEngine 2.0
- Hoe het ontwerp van Transistor tot stand kwam
- Transistor: radio op de iPhone
- Over HTML5
- Scrollen in het oneindige
Laatste reacties
- Hendrik op Upgraden naar ExpressionEngine…
- Thomas Byttebier op Hoe het ontwerp van Transistor…
- Thomas Byttebier op Upgraden naar ExpressionEngine…
- Kevin op Upgraden naar ExpressionEngine…
- Frederik Severijns op Hoe het ontwerp van Transistor…
Categorieën
Alle • ExpressionEngine • iPhone • Transistor • Marketing • SEO • Ontwerp • Typografie • Ontwikkeling • jQuery • PHP • Zend Framework • Opinies • Overige • Photoshop • Webomgeving