Door
Ozzie PHP
op 25-02-2014 00:42
gewijzigd op 25-02-2014 01:05
4.491 views
Ola,
Korte vraag. Ik zit me af te vragen... Stel ik heb 2 classes waarin ik de data van een request wil opslaan. In de ene class wil ik client data opslaan en in de andere server data. Voor welke mappenstructuur zouden jullie dan kiezen? A, B of C? (Ik snap dat er nog meer mogelijkheden zijn, maar ik zou graag weten welke van deze 3 jullie voorkeur heeft en waarom.)
A)
/request/
clientdata.php
serverdata.php
Of voor deze manier:
B)
/request/
data/
clientdata.php
serverdata.php
Of...
C)
/request/
data/
client/
data.php
server/
data.php
Het gaat me er vooral om wanneer je überhaupt over moet gaan tot het aanmaken van nieuwe directories. Je kunt zeggen dat beide classes onderdeel van het request zijn, en ze dus gewoon in de request map zetten (A). Je kunt ook zeggen dat het fenomeen "data" weliswaar tot het request behoort, maar een apart onderdeel daarvan is (B). En je kunt vervolgens binnen die data ook weer aparte mappen maken omdat het om verschillende typen, client en server, data gaat (C). Ben benieuwd naar jullie reacties en vooral hoe jullie daar mee omgaan en waar jullie je keuzes op baseren.
Het kán zo wel, maar dan krijg je bijvoorbeeld een ander hoofdlettergebruik:
Vendor/
Request/
ClientData.php
Een PSR-autoloader is "van PSR" en hoort daarom in een eigen namespace:
/Psr/
Psr4AutoloaderClass.php
Kijk, zo zie je meteen wat je aan het doen bent. Dit is niet zomaar een autoloader, maar een PSR-autoloader. En niet een voor PSR-0, maar een die we hebben geleend uit PSR-4.
Vergelijkbare logica vind je in bijvoorbeeld PSR-3:
>> En niet een voor PSR-0, maar een die we hebben geleend uit PSR-4.
Wat is het verschil tussen de 0 versie en de 4 versie?
>> Een PSR-autoloader is "van PSR" en hoort daarom in een eigen namespace
Is dit jouw eigen mening.. vind jij dat het zo hoort, of zijn daar "regels" voor? Ik zou zelf een (psr)autoloader namelijk eerder zoeken in mijn autoloader map, dan in een aparte psr namespace. En als ik een psr logger zou hebben, dan zou ik die ook eerder zoeken in mijn logger map. Is dat dan fout? Ik snap jouw redenatie ook, maar "mijn" manier kan toch ook?
>> Daarom zou ik bij jouw voorbeeld ook zoiets verwachten:
Ah oké, duidelijk. Ik ben zelf niet zo'n heel erg voorstander van hoofdletters in map- en bestandsnamen. Ik zat net even te experimenteren, en het gebruik van underscores vind ik eigenlijk ook wel heel duidelijk:
>> Is dit jouw eigen mening.. vind jij dat het zo hoort, of zijn daar "regels" voor?
Dat is een kip-en-ei-probleem: het zijn de richtlijnen uit PSR-0 en PSR-4, dus als je de PSR-standaarden wilt aanhouden, moet je de PSR-standaarden aanhouden :-)
>> Wat is het verschil tussen de 0 versie en de 4 versie?
PSR-4 is aan aanvulling op andere autoloading-specificaties, waaronder PSR-0. Daarnaast beschrijft PSR-4 wáár je bestanden moet opslaan (PSR-0 niet) en is het daarmee een antwoord op je vraag.
>> PSR-4 is aan aanvulling op andere autoloading-specificaties, waaronder PSR-0. Daarnaast beschrijft PSR-4 wáár je bestanden moet opslaan (PSR-0 niet) en is het daarmee een antwoord op je vraag.
In mijn psr autoloader kan ik zeggen dat de namespace "Foo" moet worden gezocht in de map "bar", dus new Foo\FooBar verwijst dan naar /bar/foobar.php. Is dat dan psr-4?
>> Dat is een kip-en-ei-probleem: het zijn de richtlijnen uit PSR-0 en PSR-4, dus als je de PSR-standaarden wilt aanhouden, moet je de PSR-standaarden aanhouden :-)
Haha, ja ik hou de richtlijnen ook aan, maar ik bedoel... is het jouw eigen mening dat een psr autoloader thuishoort in een psr mapje? Je zou ook kunnen zeggen, het is een autoloader van het "type" psr en ik stop 'm gewoon in de autoloader map.
Als ik dus bijv. gebruik wil maken van een psr autoloader of logger, dan zou ik zeggen:
$autoloader = new Ozzie\Autoloader\PsrAutoloader;
$logger = new Ozzie\Logger\PsrLogger;
>> is het jouw eigen mening dat een psr autoloader thuishoort in een psr mapje? Je zou ook kunnen zeggen, het is een autoloader van het "type" psr en ik stop 'm gewoon in de autoloader map.
Eerlijk gezegd, smokkel ik wel eens. Ik heb bijvoorbeeld een PSR-0-autoloader (geen class maar een functie) in de library staan, dus op het niveau /lib/ bóven alle vendor-mappen /lib/Psr/ en /lib/Google/ enzovoort.
Verder smokkel ik ook wel eens door binnen een package op het niveau /Vendor/Package/ een config.php met een doodgewoon rijtje require-statements op te nemen. Niet netjes, maar soms is require 'config.php' wel praktisch als je toch uitsluitend iets uit één package nodig hebt.
Verder houd ik er niet zo van om rigide alles met alleen een beginhoofdletter te schrijven, bijvoorbeeld Ideal en Postnl in plaats van iDEAL en PostNL.
>> Verder houd ik er niet zo van om rigide alles met alleen een beginhoofdletter te schrijven, bijvoorbeeld Ideal en Postnl in plaats van iDEAL en PostNL.
Ik denk dat ik alles met kleine letters ga schrijven.. tenzij het een externe library is, maar voor de rest, alles voortaan met kleine letters. Hoef ik er nooit meer over na te denken, en kan ik me ook nooit meer vergissen. Ideal, of was het nu iDEAL of IDEAL? Gewoon ideal :)
Wat betreft het psr gebeuren. Dat zijn toch gewoon richtlijnen hoe je iets kunt aanpakken? Het is toch geen library?
Weet je nog het antwoord op mijn vorige vraag?
"In mijn psr autoloader kan ik zeggen dat de namespace "Foo" moet worden gezocht in de map "bar", dus new Foo\FooBar verwijst dan naar /bar/foobar.php. Is dat dan psr-4?"
PSR draait nu inderdaad vooral nog om API's, dus de interfaces waarmee je uiteenlopende PHP-projecten aan elkaar kunt koppelen. Daar begint standaardiseren immers mee: de interne werking van een klasse is niet interessant, zolang de interface maar is gestandaardiseerd.
In de PSR-recommendations vind je echter wel bruikbare klassen. Officieel zijn dat vaak maar voorbeelden, maar ze zijn goed te gebruiken als library.
Maar het is toch niet zo dat bijv. een externe library een psr "library" nodig heeft om te kunnen werken? Een externe library kan bijv. een autoloader nodig hebben "op basis van de psr" richtlijnen, maar dat is het toch wel?
Alle bestanden staan nu in de request map. Ik ben benieuwd of jij een voorbeeld kan geven wanneer je gebruik zou maken van een of meerdere submappen. Dus je hebt zeg maar eerst de vendor, en dan de hoofdmap. In die hoofdmap (in dit geval "request") staan nu alle bestanden, maar zijn er ook situaties waarin je een hoofdmap hebt, waar ook submappen in staan?
