Ik vroeg me ineens iets af. Een van de $_SERVER variabelen bevat een string met de encoding-types die de client ondersteunt.
Nu heb ik in mijn request\client object een method getEncodingTypes() gemaakt waarmee je die string kunt opvragen. Nu is mijn vraag... (ik heb namelijk echt geen idee of hier een "stelregel" voor geldt...) of je het beste kunt programmeren naar data of naar behaviour. Daarmee bedoel ik het volgende:
Hoe ik het nu doe, programmeer ik naar data. Namelijk:
<?php
$client = $request->getClient();
$encoding_types = $client->getEncodingTypes();
if (strpos($encoding_types, 'gzip')) {
// doe iets
}
?>
Wat er dus gebeurt, is dat ik data ophaal (de string met encoding-types) waarmee ik vervolgens iets ga doen (namelijk controleren of het type "gzip" aanwezig is).
Wat ik ook kan doen, is programmeren naar behaviour (gedrag/functionaliteit).
Voorbeeld:
<?php
$client = $request->getClient();
if ($client->hasEncoding('gzip')) {
// doe iets
}
?>
Hier haal ik dus geen data op, maar "vraag" ik aan de client of hij het encoding-type "gzip" heeft.
Heeft van deze 2 methodes eentje de voorkeur? Is daar een "stelregel" voor, of maakt het niks uit en is het net wat je zelf leuk vindt?
Klopt, ik heb je een link gegeven waar staat uitgelegd hoe je de accept-encoding header moet parsen. Dus als je wilt kun je het veiliger maken. De vraag is of het nodig is.
Ik snap het principe niet. In het voorbeeld wordt gezegd dat je iets opvraagt, wat even later weg kan zijn. Echter, in dit geval haal je verder niks op. Je vraagt of de client iets ondersteunt. Het is niet zo dat de client dat het ene moment wel ondersteunt, en even later ineens niet meer. Vandaar dat ik niet begrijp op welke manier het "tell, don't ask" principe hier van toepassing is.
En wat als je ergens anders die zelfde "$client->hasEncoding()" gebruikt om vervolgens wél $client->getEncondigStrcuture()" oid aan te roepen? Dat weet je van te voren toch nooit. Wellicht heb je die methode nu niet, maar misschien wil je dat in de toekomst wel.
Het gaat hier ook om het "principe", vadaar de naam "Tell, don't ask principle". Het legt uit wat het idee er achter is, welke gevaren er achter kunnen schuilen etc. Als je die ideeën gewoon eens door lees, dan krijg je vanzelf antwoord op al die vragen.
Dan kun je uiteindelijk ook voor jezelf bepalen of je het wel of niet wilt toepassen. Het enige wat ik er mee wil zeggen is, dat mensen hier al over negedacht hebben en dat je daar meer over kan lezen als je wilt.
@Dos: ik geloof dat ik niet helemaal begrijp wat je bedoelt :-/
@D Vivendi:
>> En wat als je ergens anders die zelfde "$client->hasEncoding()" gebruikt om vervolgens wél $client->getEncondigStrcuture()" oid aan te roepen? Dat weet je van te voren toch nooit. Wellicht heb je die methode nu niet, maar misschien wil je dat in de toekomst wel.
Sorry, ik doe echt m'n best om te begrijpen wat je bedoelt. Stel dat ik het voorbeeld iets wijzig, misschien kan ik dan beter overbrengen wat ik bedoel, en misschien kan jij dan uitleggen wat jij bedoelt en valt bij mij het kwartje.
Laten we de encoding types vergeten, maar laten we hetzelfde voorbeeld gebruiken om de browser te checken.
We zouden dat weer op deze 2 manieren kunnen doen:
<?php
$browser = $client->getBrowser();
if ($browser === 'internet explorer') {
// doe iets
}
?>
Of...
<?php
if ($client->hasBrowser('internet explorer')) {
// doe iets
}
?>
Jij zou kiezen voor de 1e optie, maar ik begrijp de redenering erachter niet.
Ik wil alleen weten of ie een bepaalde browser gebruikt. Zijn browser zal gedurende het request niet ineens veranderen, en als ik weet dat de browser bestaat, dan hoef ik die niet via een get method te getten. Het kwartje valt bij mij nog niet.
>> Als je nu wil kijken of in die string de waarde "bar" aanwezig is, dan zou dat met strpos resulteren in een positief resultaat omdat barbarapappa een match oplevert. Echter, er is helemaal geen waarde "bar". Mijn idee is dan ook dat strpos geen veilige manier is om waardes in een string te controleren.
Dan schrijf je een kleine parser voor dit specifieke type string. Zoals Dos ook aangaf. Daarin zul je vervolgens moeten vastleggen wat een acceptabel "woord" is waarop gecontroleerd kan worden (denk aan spaties, komma's of komma's gevolgd door een spatie en kleine letters, hoofdletters of mengvormen). Tot slot controleer je of het gezochte woord voorkomt in de string.
In wezen doe je iets vergelijkbaar ook bij een regexp: die voer je een instructie met verschillende regels in een pattern, waarna die regels achter de schermen worden geëvalueerd. En als het met een regexp kan, dan hoef je zelf geen parser te schrijven. Misschien een idee?
En dan is het een stuk makkelijker, want dan kun je in_array gebruiken. Maar nu moet ik dus wel eerst die string ombouwen naar een array. En ik vraag me af of dat niet een beetje over de top is.
Of je dat kunt doen met een regexp? Vast wel, maar daar ben ik nog niet zo goed in.
Thanks Dos. Ik had dat zien staan, maar begreep niet hoe het te interpreteren. En nu ik er naar kijk nog niet echt. Die q waardes die horen toch bij een type? Bijv. bij gzip?
>> Weet je nog wat ik zei over meer maar goed te volgen kleine stapjes versus weinig complexe stappen (regex in dit geval)?
Ja, beter kleinere stapjes en het overzicht bewaren.
