CSS sprites in de praktijk: Plan België titels

Aan de hand van CSS sprites kan je het aantal requests op een website beperken, door verschillende afbeeldingen in 1 of meerdere afbeeldingen te combineren. Dit heeft een grote impact op de performantie van je website. Als de sprites dan ook nog eens gecached worden, kan dit de rendering van de pagina’s drastisch optimaliseren.

Plan België

Zo hebben we ondermeer gezorgd voor een grondige frontend optimalisatie bij de uitwerking van de Plan België website. Het doel daar, was om het aantal requests tot een minimum beperken, omwille van het grafische karakter van de site. Daarom leek het ons wel een uitdaging om creatief aan de slag te gaan met PNG afbeeldingen en trachten 1 sprite te maken voor alle titels over heel de website.

Flexibele en herbruikbare PNG’s

Doorheen de Plan België website vind je dit soort titels:

Zoals je kan zien: verschillende kleuren en variabele breedtes zijn mogelijk.

Analyse en aanpak

Het idee dat we hadden, was om een transparante afbeelding te gebruiken, waarbij we hetgene dat wit moet zijn, wit houden en hetgene ingekleurd moet worden, transparant. Daardoor kunnen we via CSS een achtergrondafbeelding + achtergrondkleur specifiëren.

Om het gewenste effect te krijgen, maken we gebruik van een 24-bit PNG file. De afbeelding omvat tevens een semi-transparant gedeelte, waar een lichtere variant van de kleur doorschijnt (opacity 85%).

Omdat transparante 24-bit PNG files niet ondersteund worden in Internet Explorer 6, opteren we ervoor om in die browser een 8-bit PNG versie te voorzien. Het resultaat in deze browser is een iets ruwere versie, maar omdat bij Plan België het toch ging om een grunge look, vormde dat geen probleem.

De code

HTML

1. <h2>
2. <span class="border">Steun Plan</span>
3. <span class="bg"></span>
4. </h2>

Er zijn twee extra spans nodig om de styling naar behoren uit te voeren.

CSS

1. h2 {
2. position: relative;
3. font-size: 15px;
4. height: 32px;
5. }

Position wordt op relative geplaatst, om een span absoluut te kunnen positioneren t.o.v. de h2. Verder wordt een vaste hoogte bepaald, omdat de children ofwel absoluut gepositioneerd zullen zijn, ofwel een float zullen krijgen.

1. .bg {
2. position: absolute;
3. left: 0;
4. height: 18px;
5. padding: 7px 10px 3px;
6. color: #fff;
7. background: #0D5F99 url(img/sprite.png) no-repeat 0 0;
8. }

De .bg class is het gekleurde vlak achter de tekst. Het wordt absoluut gepositioneerd, krijgt een witte tekstkleur, als achtergrond een kleur én een afbeelding (het bovenste deel van de sprite).

De totale hoogte is 18px + 7px (padding-top) + 3px (padding-bottom) = 28px.

1. .border {
2. float: left;
3. margin: 2px 0 0;
4. height: 28px;
5. width: 100%;
6. background: #0D5F99 url(img/sprite.png) no-repeat 0 100%;
7. }

De .border class krijgt een float: left, alsook de achtergrondkleur en afbeelding (het onderste deel van de sprite). De hoogte wordt ook ingesteld op 28px, maar met een margin-top van 2px, zodat de lijn net onder het tekstvlak wordt getoond.

De breedte van de .border krijgt een waarde van 100%. Hij neemt dus de hele breedte van zijn parent in (dus de h2). Hierdoor zal de titel steeds even breed zijn als de container waarin hij zich bevindt (bvb smalle kolom, volledige pagina breedte, …)

Om een gelijkaardig resultaat te krijgen in IE6 waren nog enkele aanpassingen nodig in de conditional stylesheet.

1. .bg, .border {
2. background-image: url(img/sprite_8bit.png);
3. z-index: 20;
4. }
5. .example .border {
6. position: absolute;
7. margin-top: 0;
8. height: 30px;
9. z-index: 10;
10. }

Varianten

Op de Plan België website wordt ook een vereenvoudigde versie van deze titels gebruikt, waarbij een grunge lijntje onder de titel staat. Ook hier hanteren we dezelfde techniek.

Demo

Voor het gemak heb ik een demo klaargezet.

Voordelen van deze techniek

• Slechts 1 HTTP request voor de afbeelding
• Alle kleuren van titels (voor- en achtergrond alsook het semi-transparante gedeelte) kunnen eenvoudig via CSS aangepast worden
• Geen image replacement technieken nodig
• Titel zijn horizontaal schaalbaar
• Je moet geen afzonderlijke images maken voor de verschillende titels of kleuren

• Toegevoegd op: 27 May 2009
• Geschreven door: davy
• Tags: code, CSS, CSS sprites, frontend, optimalisatie, PNG, technieken

• Reageer
• Permanente link
• Reacties (2)
• Links naar dit artikel

Online betalen voor e-commerce sites voor dummies

Iedereen die een e-commerce website wil opstarten heeft dezelfde vragen. Hoe beheer ik producten? Hoe beheer ik klanten en bestellingen? Hoe gaat mijn site er uit zien? Hoe krijg ik klanten naar mijn webshop? Hoe zorg ik ervoor dat klanten terugkeren? Welke prijszetting moet ik hanteren?

Er zijn echter twee zaken waar niemand vragen over stelt: stock en online betalen. Omdat ze beiden evident lijken. Die heb je nodig, als je een webwinkel lanceert, toch? Gewoon. Online betalen. Gewoon toevoegen. Toch?

Over dat online betalen (met VISA, MasterCard, PC Banking, etc) weet dus niemand wat het exact inhoudt. Moet je gewoon een bankrekening hebben? En als je al een winkel hebt en daar staat zo’n Banksys bakje, dat is toch voldoende? En wat zal het kosten?

We proberen aan antwoord te bieden op deze vragen:

• Wie en wat heb ik nodig
• Met wie moet ik een contract aangaan
• Wat is een acquirer
• Wat is een betaaldienst

Wie en wat heb ik nodig

Het komt hierop neer: de bezoeker van uw webshop betaalt, en dat geld moet bij u terechtkomen. In deze ketting zijn er 3 schakels: de website, de aanbieder van de betaaldiensten (een tussenpartij, wordt soms ook gateway genoemd) en een transactieverwerkende instelling, wat een mondvol is voor een bank of acquirer.

En eigenlijk kan je dit perfect vergelijken met de offline wereld. Stel, je gaat uit eten in een restaurant. Betaal je met je credit card, dan zijn er daar ook 3 schakels: het restaurant (is hetzelfde als jouw website, de plek waar er gekocht wordt), het creditcardapparaat (is hetzelfde als de betaaldienst) en – laten we nog éénmaal die term gebruiken – de transactieverwerkende instelling (uw bank of uw acquirer). Het creditcardapparaat maakt een verbinding met de bank/acquirer van het restaurant, die dan de creditcard controleert en het geld overmaakt van jouw rekening naar die van het restaurant.

Bij een webshop is het dus net zo:

1. je zal in je website een soort creditcardapparaat moeten integreren, dat is de betaaldienst, de tussenpartij die de verbinding zal leggen met de bank/acquirer.
2. om het geld te kunnen laten overmaken van de rekening van de betaler naar de rekening van je e-commerce site, moet je ook een contract hebben met een bank/acquirer, je weet wel, die van die transactiever…dinges.

Met wie moet ik dan een contract aangaan?

Om te beschikken over de betaaldienst – het creditcardapparaat van je website – ga je een contract aangaan met iemand die zo’n dienst aanbiedt. Dat is één. Hieronder vind je wat meer uitleg.

En het geld moet nog op je rekening komen, en vooral, je moet het betaalmiddel (kaart, pc-banking) waarmee je klant betaalt kunnen controleren. En dat kan alleen een bank of acquirer. Dus: wil je mensen laten betalen met VISA, dan moet je een contract aangaan met een acquirer die VISA aanbiedt. Wil je mensen laten betalen via de KBC knop, dan moet je een contract aangaan met KBC. Wil je beide, dan moet je een contract aangaan met beide.

Voor elk betaalmiddel dat je aanbiedt moet je een contract aangaan met een acquirer of bank. Sommige banken of acquirers bieden wel meer dan één betaalmiddel aan. Hieronder vind je meer uitleg.

Dat is dus minimum een contract aangaan met twee partijen.

Wat is eigenlijk een acquirer, en is dat niet mijn bank?

Een acquirer is een financiële instelling die jou als webwinkel de toestemming geeft betalingen te aanvaarden van een welbepaalde kaart of pc-banking. De acquirer vraagt het geld aan de bank (of kaartuitgever) van de persoon die koopt en zorgt dat het geld op jouw bankrekening terechtkomt.

Moet een acquirer dezelfde bank zijn als de bank waar mijn klant zijn creditcard van heeft gekregen? Neen, absoluut niet. Ik zit zelf bij Argenta. Ik heb een VISA kaart van Argenta (mijn kaartuitgever dus). Dat betekent niet dat ik enkel kan winkelen bij websites die met Argenta samenwerken (als acquirer). Argenta is zelfs helemaal geen acquirer.

Welke acquirer helpt me bij welk betaalmiddel?

Er zijn verschillende acquirers of banken waar je mee kan samenwerken.

Wil je Visa en/of MasterCard aanbieden (beiden gaan meestal samen), dan kan je o.a. terecht bij Elavon (de acquirer van Monsters with an Attitude), Europabank, Atos Worldline (eigenaar van Banksys en Bank Card Company (BCC)), PaySquare, EMS card, etc.

Voor Maestro vind je een paar van dezelfde spelers terug: Europabank, Atos Worldonline, PaySquare, EMS card, etc.

Bancontact/Mister Cash wordt enkel door Atos Worldonline aangeboden. Zie hier voor meer info over Bancontact/Mister Cash. Vergeet niet dat dit betaalmiddel hoort te verdwijnen in de nabije toekomst.

Daarnaast heb je ook nog 4 banken die hun eigen betaalmiddel aanbieden. Zo kan een bezoeker van je website bij jou kopen, en betalen via zijn eigen pc-banking. Zo biedt KBC/CBC betalingen aan via KBC online/CBC online; Dexia voor haar Dexia Direct Net; ING voor ING’HomePay; en Centea voor Centea Online. Ook ping.ping (het vroegere Tunz) is een acquirer voor zijn eigen betaalmiddel.

Er zijn natuurlijk nog tal van andere betaalmiddelen waarvoor je met andere acquirers een contract moet aangaan. We hebben hier enkel de betaalmiddelen opgelijst die het meest in gebruik zijn.

Wat kost dat?

Dit hangt volledig af van de acquirer of bank, welk type contract je hebt, en hoe goed je kan onderhandelen. Acquirers en banken vragen meestal een transactiekost, dit in de vorm van een percentage (het meest voorkomend, en vaak 3%) of een vast bedrag.

De betaaldienst (tussenpartij of gateway)

De betaaldienst is dus het equivalent van het creditcardapparaat in het restaurant. Belangrijk is dat je een betaaldienst kiest die jouw betaalmiddel aanbiedt. De betaaldienst moet namelijk in staat zijn de nummers en gegevens die je ingeeft naar de correcte acquirer te sturen, en die daar te laten controleren, en in staat zijn daar een antwoord van te ontvangen. Een betaaldienst is puur een doorgeefluik. Vandaar dat soms de naam gateway valt.

Waarom heb ik die nodig als ik al een contract heb met mijn bank?

Wel de reden is eenvoudig: de betaaldienst, een goeie betaaldienst althans, biedt veel betaalmiddelen aan. Stel dat je rechtstreeks zou werken met een acquirer.

Je beslists pc-banking van KBC aan te bieden, en VISA. Jouw website bouwer moet dan jouw website zodanig programmeren dat die met twee compleet verschillende systemen kan communiceren. En telkens als je een nieuw betaalmiddel zou kiezen, moet je opnieuw de programmatie laten aanpassen.

Een betaaldienst is dus een noodzaak. Deze dienst is het centrale doorgeefluik dat voor verschillende betaalmiddelen werkt. Je moet enkel je website met die ene betaaldienst laten communiceren. De betaaldienst zorgt voor de communicatie met de acquirer/bank.

En eenmaal een goede betaaldienst gekozen, is het een eenvoudig om extra betaalmiddelen toe te voegen, wanneer je dat wil. Telkens moet je dan enkel nog een nieuwe acquirer zoeken en bij de betaaldienst de nodige instellingen bepalen.

Welke betaaldienst kan me helpen?

In België is de meest bekende Ogone. Ogone is het bedrijf waar ook Monsters with an Attitude, Poncha, Codima en Tele Atlas mee samenwerken. Ze zijn marktleider in België, zijn actief in heel wat andere Europese landen, en bieden naast de hierboven genoemde klassieke betaalmiddelen ook meer exotische betaalmiddelen aan.

Je hebt ook Neos Solutions, van Fortis. Maar eigenlijk is dit Ogone met een ander kleurtje. De technologie, het platform, de servers, alles is van Ogone, maar dus met een andere merknaam. Wie klant is bij Fortis kan bij Neos Solutions aankloppen, en in sommige gevallen daar zelfs een goede deal mee afsluiten.

Wat kost dat?

Ook hier weer hangt alles af van het type product en contract je aangaat. Meestal betaal je naast een eenmalige setup-kost en een maandelijkse vaste kost ook nog eens een transactiekost. Ook hier weer in de vorm van een percentage of vaste kost per transactie.

Is er een link tussen de betaaldienst en de acquirer?

Eigenlijk niet, maar ook weer wel. Er zijn weinig betaaldiensten die ook acquirer zijn, en ook omgekeerd komt dit zelden voor. Nu, banken ruiken altijd geld en daarom starten sommige banken hun eigen betaaldienst op.

Je hebt onder andere het eerder vermelde Neos Solutions, opgericht door Fortis. Maar zoals gezegd, dit is eigenlijk Ogone met een ander kleurtje.

Zijn er nog andere manieren om online te betalen?

iDEAL is in Nederland stilaan het standaard betaalmiddel geworden. iDEAL, onder andere beschikbaar bij De Kleine Zebra, is een initiatief van ING, ABN Amro, Rabobank en Postbank. iDEAL is geen bankkaart, maar is op zich een doorgeefluik naar de pc-banking omgeving van de klant.

iDEAL is een betaalmiddel, en wordt ook aangeboden door Ogone.

Je hebt natuurlijk ook PayPal, een online betaaldienst die je kan integreren om via die weg alle betalingen te verzorgen en te ontvangen. PayPal is eigenlijk acquirer en betaaldienst tegelijk. Je kan via PayPal betalen met je PayPal rekening, maar ook met Visa, etc.

En Ogone biedt zelfs de mogelijkheid aan om via hun betaaldienst te betalen met je virtuele PayPal rekening.

Conclusie

• je gaat een contract aan met een acquirer of bank, en dat voor elk betaalmiddel dat je wil aanbieden (sommige acquirers beiden verschillende betaalmiddelen aan)
• je gaat een contract aan met een betaaldienst
• je integreert je website met die betaaldienst (er is natuurlijk nog ietwat programmeer werk om alles mooi te doen samenwerken)

• Toegevoegd op: 26 May 2009
• Geschreven door: vincent
• Tags: betaaldienst, betalen, e-commerce, e-commerce website, howto, online betalen, visa, webshop, webwinkel

• Reageer
• Permanente link
• Reacties (5)
• Links naar dit artikel

Herbruikbare kruimelpaden of breadcrumbs: de HTML en CSS opmaak

Broodkruimelnavigatie (breadcrumb of kruimelpad) is een handige en visuele manier om de bezoeker duidelijk te maken waar hij zich precies bevindt op een hiërarchisch ingedeelde website.

Ons doel is, om de broodkruimel zo semantisch mogelijk in HTML op te maken. Er is alleszins al genoeg over gediscussieerd, lees er maar SimpleQuiz part XII eens op na. De algemene conclusie daar was dat je semantisch gezien het best opteert voor geneste ongenummerde lijsten. In de praktijk leek dat echter minder haalbaar vanwege de vrij complexe HTML structuur.

Het is dus zoeken naar een evenwicht tussen semantiek, praktische eenvoud en de toegankelijkheid van de gebruikte HTML.

Daarom hanteren wij voor breadcrumbs steeds volgende HTML opmaak:

<div id="breadcrumb">
   <strong>Je bent hier<span class="hide">:</span></strong>

   <span class="hide"> van </span>
   <a href="#">Startpagina</a>

   <span>naar</span>
   <a href="#">Kinderboeken</a>

   <span>naar</span>
   <a href="#">Prinses</a>

   <span>naar</span>
   <em>De avonturen van prinses</em>
</div>

Wanneer je de CSS styling uitzet, lees je dit:

Je bent hier: van startpagina naar kinderboeken naar prinses naar de avonturen van prinses

Met die HTML markup heb je trouwens voldoende ankerpunten om het via CSS bijvoorbeeld op volgende manieren te stylen:

De CSS ziet er in het geval van Poncha zo uit:

#breadcrumb {
   margin: 0 0 20px 0;
   padding: 27px 0 0 20px;
}

#breadcrumb strong {
   float: left;
   padding-right: 25px;
   color: #6589a5;
   background: url(/img/sprite.png) no-repeat 100% -280px;
}

#breadcrumb a {
   float: left;
   text-decoration: none;
}

#breadcrumb a:hover { text-decoration: underline; }

#breadcrumb span {
   float: left;
   width: 25px;
   text-indent: -999em;
   background: url(/img/sprite.png) no-repeat 100% -280px;
}

#breadcrumb em {
   float: left;
   font-style: normal;
   color: #e2007a;
}

/* Generic hide */
.hide {
	position: absolute;
	display: block;
	padding: 0 !important;
	text-indent: -999em ;
	font-size: 0px;
	height: 0px !important;
	line-height: 0px !important;
	background: none !important;
}

De class=”hide” kan je hangen aan die onderdelen die niet moeten getoond worden, bijvoorbeeld het U bent hier gedeelte, of het :-teken.

Concreet is de HTML voor alle voorbeelden steeds dezelfde (op de hide class na) en is het gewoon de CSS die, zij het lichtjes, varieert naargelang het design van de website.

• Toegevoegd op: 25 May 2009
• Geschreven door: davy
• Tags: breadcrumbs, CSS, html, kruimelpad, opmaak, semantiek, technieken

• Reageer
• Permanente link
• Reacties (3)
• Links naar dit artikel

Future Of Web Design 2009

Designing effective mobile interfaces

Met enkele cijfers toonde Megan Fischer (SimpleBits) aan dat mobiel internet aan een sterke opmars bezig is. Globaal is er een groei van 15 tot 20 % per maand, wat 8 X zo snel is als desktop internet toegang. De kans is dus groot dat je in de nabije toekomst geconfronteerd wordt met mobiel internet. Op het eerste moment lijkt ontwikkeling voor de mobiele markt een echte uitdaging. Er zijn enorm veel verschillende toestellen elk met hun eigen niveau van css ondersteuning en schermresolutie. Gelukkig zijn er al voldoende bronnen die je op weg kunnen helpen: bijvoorbeeld het boek Mobile Web Design door Cameron Moll.

niveau van ondersteuning

• Naked: Gebruiker doorverwijzen naar een mobiele versie waarvan de css en beelden verwijderd zijn. Dit zorgt voor snelle laadtijden. Door het ontbreken van extra bestanden is deze versie zeer onderhoudsvriendelijk. Pure html zorgt natuurlijk wel voor een saaie gebruikerservaring.

• Some style: Mobiel stylesheet zorgt voor een minimum aan stijl. Een header met logo en een basis pallet aan kleuren versterken in dit geval de branding van de site. Hierbij is het wel aan te raden om de grootte van beelden te beperken.

• Deck it out: Afzonderlijke website specifiek voor mobiel gebruik. Herschreven mark-up die aangepast is aan de noden van een mobiel gebruiker.

Typography on the web

opening the floodgates with @fontface

Het beperkte gamma aan fonts bij webdesign lijkt op het eerste moment een beperking. Met de komst van @fontface zou een einde komen aan dit tijdperk. Mark Bolton had hierbij enkele bedenkingen. Op technisch vlak zijn er nog problemen, browsers zijn het nog niet eens over de implementatie en rendering. Ontwerpers van lettertypes maken zich ernstig zorgen over licenties en copyrights. Maar er zijn nog enkele andere knelpunten:

• Meeste lettertypes zijn niet ontworpen voor schermweergave. “Times New Roman” werd bijvoorbeeld ontworpen voor krantendruk. De smalle schreven zetten uit tijdens het drukken door de snelheid van het drukprocédé en de lage kwaliteit van het papier. Op het scherm daarintegen werkt dit niet, bij kleine fontgrootte zijn de schreven amper zichtbaar.
• lettertypes zijn ontworpen voor een bepaald doel of sfeer. “Comic Sans” is technisch en estetisch gezien geen slecht lettertype, maar het is wel 9 op de 10 keer het verkeerde lettertype voor de opdracht.

making good design decisions

Studies hebben uitgewezen dat de verkoop van een product daalt naarmate het aantal varianten toeneemt. Mark Bolton gaf het voorbeeld van een experiment in een warenhuis. Klanten kregen een waardebon om een pot confituur af te halen. Wanneer 24 verschillende soorten tentoongesteld stonden ging slechts 3% over tot een aankoop. Toen het aanbod naar 6 soorten werd teruggebracht liep 30 % van de klanten met een pot confituur de winkel buiten. Hiermee werd aangegeven dat teveel keuze hinderlijk is voor een beslissingsproces.

Hetzelfde principe is van toepassing op webdesign. Een mooi voorbeeld hiervan is de interface van een rich text editor zoals TinyMCE. De gebruiker wordt een arsenaal aan verschillende opmaak mogelijkheden aangeboden waarvan niet alle combinaties even estetisch verantwoord zijn. Misschien is het beter om het aantal keuzes te beperken, bijvoorbeeld enkel fonten en kleuren aanbieden die binnen de branding vallen. De term “cascading style decisions” werd gebruik als een mogelijke oplossing. In plaats van alle mogelijkheden op een dienblad aan te bieden kan je stapsgewijs werken. Het lettertype kan je laten kiezen op basis van de sfeer die uitgestraald moet worden. Zakelijk, modern, speels zijn termen die meer aanspreken dan “Georgia”, “Arial”, “Comic Sans”. Kleuren kunnen op dezelfde wijze aangeboden worden.

Keuze is belangrijk, maar begeleiding in het proces is dus cruciaal om tot goede (design) beslissingen te komen.

Future Of Webstandards

Een fragment uit de TV-serie “the big bang theory” legde de basis van Molly Holzschlag haar presentatie.

Rock

Rock staat voor de basisprincipe van standaarden. Voor iedereen, overal beschikbaar, sociaal, gebruiksvriendelijk, … Dit hadden Tim Berners-Lee en zijn collega’s voor ogen toen ze de aanzet gaven voor het World Wide Web. Klinkt goed, maar dit is niet het internet dat we vandaag hebben. Net zoals de Amerikaanse grondwet zijn de beginselen idealistisch, maar de manier waarop ze toegepast worden minder mooi.

Paper

Het woord “markup” of opmaaktaal komt oorspronkelijk uit de uitgeverswereld, waar boeken met instructies voor de drukker werden voorzien. Het is geen nieuwe technologie, enkel gedigitaliseerd.
Momenteel zijn verschillende versies in gebruik: HTML 4.01, XHTML 1.0, XHTML 1.1, XHTML 2 en HTML 5. Aangezien XML niet ondersteund wordt in de MIME type van een belangrijke browser. XHTML heeft dus momenteel geen meerwaarde buiten de strengheid bij het schrijven van code (hoofdletters, onderkast,…). Rond HTML 5 is een misverstand dat het pas tegen 2020 zou afgewerkt zijn. Neem het voorbeeld van CSS 2.1 waar het voorstel in 1998 werd uitgewerkt en tot op vandaag nog geen definitieve versie beschikbaar is. De geïmplementeerde standaard wordt dus de “echte” standaard. Het wordt dus echt de moeite waard om de evolutie en mogelijkheden van HTML 5 te volgen.

Scissors (cut it out)

Er is een enorme evolutie in browsers, Internet Explorer inbegrepen. IE8 in standard mode is een goede browser met uitstekende css ondersteuning. Maar het loopt mis door de verschillende versies, IE8 kan een webpagina op verschillende manieren verwerken (Quirks Mode, Standards Mode, IE7 Compatibility Mode) wat voor webdevelopers die nog steeds met IE6 geconfronteerd worden een hindernis is. Versionering staat loodrecht tegenover de beginselen van standaarden.

Lizzard (get on with it)

Technologieën zoals SVG, SMIL en bijvoorbeeld Microformats zijn al jaren beschikbaar en worden nog te weinig toegepast.

Spock (futureproof)

Het uiteindelijke doel is “Open Web Stack”, open source op alle levels.

• Toegevoegd op: 20 May 2009
• Geschreven door: gert
• Tags: conference, conferentie, design, fowd, fowd 2009, webdesign

• Reageer
• Permanente link
• Geen reacties
• Links naar dit artikel

$client = new Zend_Rest_Client('http://localhost:5984');

// compose document
$document = array();
$document['title'] = 'document title';
$document['content'] = 'document content';

// JSON-ize document
$document = Zend_Json::encode($document);

// add document (use POST here)
$response = $client->restPost('test', $document);

// print response
Zend_Debug::dump($response);

object(Zend_Http_Response)#6 (5) {
  ["version:protected"] => string(3) "1.1"
  ["code:protected"] => int(201)
  ["message:protected"] => string(7) "Created"
  ["headers:protected"] => array(6) {
    ["Server"] => string(39) "CouchDB/0.10.0a773105 (Erlang OTP/R12B)"
    ["Location"] => string(59) "http://localhost:5984/test/c447a8366d74d880f35720d92d68419e"
    ["Date"] => string(29) "Tue, 19 May 2009 18:23:59 GMT"
    ["Content-type"] => string(24) "text/plain;charset=utf-8"
    ["Content-length"] => string(2) "73"
    ["Cache-control"] => string(15) "must-revalidate"
  }
  ["body:protected"] => string(73) "{"ok":true,"id":"c447a8366d74d880f35720d92d68419e","rev":"1-3753022840"}
"
}

// get document
$response = $client->restGet('test/c447a8366d74d880f35720d92d68419e');

// un-Json-ize document
$document = Zend_Json::decode($response->getBody());

// print document
Zend_Debug::dump($document);

// get document
$response = $client->restGet('test/c447a8366d74d880f35720d92d68419e');

// un-Json-ize document
$document = Zend_Json::decode($response->getBody());

// change values
$document['title'] = '"updated title!"';

// update document
$response = $client->restPut('test/c447a8366d74d880f35720d92d68419e', Zend_Json::encode($document));

// print response
Zend_Debug::dump($response);

object(Zend_Http_Response)#7 (5) {
  ["version:protected"] => string(3) "1.1"
  ["code:protected"] => int(201)
  ["message:protected"] => string(7) "Created"
  ["headers:protected"] => array(7) {
    ["Server"] => string(39) "CouchDB/0.10.0a773105 (Erlang OTP/R12B)"
    ["Location"] => string(59) "http://localhost:5984/test/c447a8366d74d880f35720d92d68419e"
    ["Etag"] => string(13) ""2-114293395""
    ["Date"] => string(29) "Tue, 19 May 2009 18:41:10 GMT"
    ["Content-type"] => string(24) "text/plain;charset=utf-8"
    ["Content-length"] => string(2) "72"
    ["Cache-control"] => string(15) "must-revalidate"
  }
  ["body:protected"] => string(72) "{"ok":true,"id":"c447a8366d74d880f35720d92d68419e","rev":"2-114293395"}
"
}