mappen opsplitsen?
PSR-0 en PSR-4 gaan over autoloading, maar er is ook nog een PSR-1, -2 en -3. PSR-3 heeft interfaces voor loggers, alle OSS PHP logger libraries hebben deze PSR interfaces (en dus ook de PSR package) nodig om te werken.
>> [...] zijn er ook situaties waarin je een hoofdmap hebt, waar ook submappen in staan?
Genoeg:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
src/
Ozzie/
Controller/
FooController.php
Model/
FooModel.php
...
Ozzie/
Controller/
FooController.php
Model/
FooModel.php
...
En voor heel veel voorbeelden: kijk eens op http://github.com/symfony/symfony (of van mij part op http://github.com/laravel/framework of http://github.com/zendframework/zf2) en blader eens door die mappen.
Wat zijn OSS libraries? :(
Waar haal ik zo'n package eigenlijk vandaan? Dus zonder de psr package werken sommige libraries niet? En hoe krijg je zo'n package dan werkend? Is dat een kwestie van de autoloader requiren?
>> >> [...] zijn er ook situaties waarin je een hoofdmap hebt, waar ook submappen in staan?
Ja, oke... maar dan praat je over het MVC principe waarbij je onderscheid maakt op basis van het type class (controller, model, view). Ik doelde meer op een library. Dus in het voorbeeld hebben we een hoofdmap "request". In het voorbeeld van Ward, staan alle bestanden in die hoofdmap. Zijn er ook situaties waarin je bepaalde bestanden in een submap zou zetten?
Open Source Software
>> Waar haal ik zo'n package eigenlijk vandaan? Dus zonder de psr package werken sommige libraries niet? En hoe krijg je zo'n package dan werkend? Is dat een kwestie van de autoloader requiren?
Leer met composer omgaan (die zorgt voor het hele autoloading gedoe) en dan kun je die packages vlekkeloos van packagist afhalen (de plek waar alle OSS libraries van PHP staan). Het is bloedsimpel. Stel ik wil de monolog logger gebruiken (http://github.com/Seldaek/monolog). Dan open ik mijn terminal (cmd) en doe:
Code (php)
1
composer require monolog/monolog
Wat composer nu voor je doet is monolog installeren en alles wat monolog nodig heeft (bijv. die PSR-3 interfaces). Die komen dan allemaal in je vendor map te staan (of in een andere map als je Composer anders hebt geconfigueerd). In die vendor map staat ook een class autoloader van Composer die correct is ingesteld voor alle packages (zo heten die libraries) die hij heeft geinstalleerd. Even die autoloader requiren in je bootstrap en je bent klaar!
Nog mooier, je kan ook composer configueren om jouw eigen library classen goed te autoloaden. Ben je helemaal van het autoload verhaal af!
>> Zijn er ook situaties waarin je bepaalde bestanden in een submap zou zetten?
Al op die 3 linkjes gekeken...? Ik kan je vertellen dat 99% van wat je daar vind een library is en geen MVC structuur.
Ah zo ja :)
Kan je zo'n package niet handmatig erop zetten? Dat is in feite toch gewoon 1 map met bestanden en (sib)directories?
>> Al op die 3 linkjes gekeken...? Ik kan je vertellen dat 99% van wat je daar vind een library is en geen MVC structuur.
Jawel, maar die hebben zo'n andere opzet dan hoe ik het zelf doe. Ik vind dat veels te ingewikkeld.
Maar wellicht kan ik mijn vraag anders stellen. Ward, en ik denk ook jij aangezien je er geen opmerking over hebt gemaakt, zou dit doen:
Code (php)
1
2
3
4
2
3
4
/Vendor/
Request/
ClientData.php
ServerData.php
Request/
ClientData.php
ServerData.php
Mijn vraag is, waarom zet je de data niet in een aparte map. Wat is daar de reden voor. Zou een van jullie dat nog kunnen proberen uit te leggen zodat dat wat duidelijker wordt voor mij? Alvast bedankt.
Je zou in jouw model bijvoorbeeld nog de clientdata kunnen preciseren:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
Vendor/
Request/
ClientData/
UserAgent.php
Cookie.php
CookieJar.php
Get.php
Post.php
Request/
ClientData/
UserAgent.php
Cookie.php
CookieJar.php
Get.php
Post.php
Ontwerpfouten maken we allemaal. De kunst is ze snel en elegant oplossen.
Je ontwerpt, denk ik, nog te veel vanuit een theoretisch ideaal. Daarom vind je tien theorieën die er op papier goed uitzien ook alle tien even goed.
Pas als je een concreet probleem aanpakt, merk je waar je theorie in de praktijk faalt. En dan los je dat gewoon op. Vergissen is menselijk en versienummers hebben we niet voor niets.
>> [...] versienummers hebben we niet voor niets.
Zorg wel dat je dit dan doet in de 0.* reeks van je library, anders krijg je veel problemen met SemVer...
Gewijzigd op 25/02/2014 20:32:39 door Wouter J
>> Alles wat tot het exclusieve domein van "Foo" behoort, staat in de /Foo/ namespace. Alles wat niet bij "Foo" hoort, hoort ook niet in de /Foo/ namespace.
Oké, maar laten we dan weer even het voorbeeld van de request erbij halen en voor het gemak doen alsof we 3 classes hebben. De basis request class, een class met daarin de client-data (get, files enz.) en een class met de server data.
Nu kunnen we alles in 1 map gooien:
Code (php)
1
2
3
4
2
3
4
/request/
clientdata.php
request.php
serverdata.php
clientdata.php
request.php
serverdata.php
Of we kunnen zeggen, de "basis" request class en de "data" zijn 2 verschillende "afdelingen" binnen het fenomeen request. Daarom zetten we de data in een aparte map.
Code (php)
1
2
3
4
5
2
3
4
5
/request/
data/
clientdata.php
serverdata.php
request.php
data/
clientdata.php
serverdata.php
request.php
En dan zou je als laatste ook nog de map data kunnen uitsplitsen naar een client map en een server map.
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
/request/
data/
client/
data.php
server/
data.php
request.php
data/
client/
data.php
server/
data.php
request.php
Jij gaf zelf aan dat je voor de 1e versie zou kiezen (weliswaar met hoofdletters), en nu wil ik graag weten waarom. Waarom zou jij alles in één hoofdmap zetten en geen submappen gebruiken?
Laat ik het anders andersom formuleren. Zodra je een namespace/subnamespace/class.php en een directory/subdirectory/bestand.php toevoegt, heb je niet slechts een beslissing over class.php en bestand.php genomen, maar ook over de namespace en de directorystructuur: klaarblijkelijk hoort de class c.q. het bestand ergens bij, dus dat moet je ook aan iedereen kunnen uitleggen.
Als je dan toch de tweedeling client/server in data wilt handhaven, is dit een betere oplossing:
Code (php)
1
2
3
4
2
3
4
/request/
data/
client.php
server.php
data/
client.php
server.php
Daarmee zeg je: (a) een request bevat data en (b) die data kennen we voor client en voor server.
>> Als je dan toch de tweedeling client/server in data wilt handhaven, is dit een betere oplossing:
Maar dit is dus ook echt waar mijn vraag om draait: het bepalen wanneer je een submap/subnamespace moet gebruiken.
Vind jij dat "data" een aparte subnamespace behoort te zijn? Want jouw oplossing werkt ook...
Code (php)
1
2
3
2
3
/request/
ClientData.php
ServerData.php
ClientData.php
ServerData.php
Hier zeg je dus... we hebben een request en onderdelen van dat request zijn de client data en de request data.
Wanneer en om welke reden zou je kunnen besluiten om de data in een aparte map te zetten. Mijn 1e gedachte was... "data" is een bepaald onderdeel binnen het request, en daarom moet het worden opgesplitst. Maar stel dat we alle data in 1 bestand zouden opslaan, zou je dan ook een submap data maken? Daar zou dan maar 1 bestand in staan. Ik vind het lastig... :(
Gewijzigd op 25/02/2014 21:41:11 door Ozzie PHP
Is dat zo...? Leg ons dan eens uit welk ander onderdeel van een request niet uit data bestaat? En hoe je onderdelen van een request wilt verwerken waarvan niets bekend is in data?