classes organiseren
Zeg nooit nooit, daar heeft Wouter echt een goed punt. Straks wil je bijvoorbeeld iets van PostNL en Mollie toevoegen en heb je /library/PostNL/ en /library/Mollie/ nodig. Om maar eens wat te noemen.
Als ik het goed begrijp dan zou jij dus dit doen:
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
/library/
Mollie/
...
Ozzie/
framework/
hier komen alle "technische bestanden te staan
modules/
hier komen de modules te staan
PostNL/
...
Mollie/
...
Ozzie/
framework/
hier komen alle "technische bestanden te staan
modules/
hier komen de modules te staan
PostNL/
...
Is dit wat je bedoelt? Op- of aanmerkingen? Dingen die beter kunnen?
Een paar vragen (zal ze even nummeren, is makkelijker)
1) wat versta jij onder een framework. Ik dacht dat het framework eigenlijk "alles" was. Dus alle libraries en modules bij elkaar. Afgaande op wat jij zegt, zie jij het framework als "de technische flow" zonder modules en 3rd party libraries. Begrijp ik je dan goed?
2) Het valt me op dat je kiest voor "library" en niet voor "libraries", terwijl er meerdere libraries in de directory staan. Heeft dat een reden? Of doe je dat omdat je /library/Ozzie logischer vindt dat /libraries/Ozzie? (en kan ik dan ook beter "module" gebruiken ipv "modules"?)
3) in mijn eerdere opzet had ik alle "technische" bestanden in het mapje "core" gezet, maar dat zijn dan eigenlijk dezelfde bestanden die nu in "framework" komen te staan?
Toevoeging op 07/10/2013 12:18:48:
4) gebruik jij eigenlijk hoofdletters bij mapnamen? Zou jij "PostNL" gebruiken of "postnl" (lowercase)?
Ozzie PHP op 07/10/2013 12:17:29:
1) wat versta jij onder een framework. Ik dacht dat het framework eigenlijk "alles" was. Dus alle libraries en modules bij elkaar. Afgaande op wat jij zegt, zie jij het framework als "de technische flow" zonder modules en 3rd party libraries. Begrijp ik je dan goed?
Letterlijk is het niets meer dan een raamwerk: vul het zelf dus in, het is jouw framework en jij bepaalt wat het moet kunnen. Bij sommige frameworks hebben de makers gekozen voor de totaaloplossing: je kunt er elk denkbaar type website of webapplicatie mee bouwen. Bij andere frameworks hadden de makers een ander doel voor ogen, bijvoorbeeld alleen webshops bouwen. Kies maar.
Ozzie PHP op 07/10/2013 12:17:29:
2) Het valt me op dat je kiest voor "library" en niet voor "libraries", terwijl er meerdere libraries in de directory staan. Heeft dat een reden? Of doe je dat omdat je /library/Ozzie logischer vindt dat /libraries/Ozzie? (en kan ik dan ook beter "module" gebruiken ipv "modules"?)
Kwestie van smaak. Wat je logischer of duidelijker vindt. Bij mij is de library enkelvoud omdat het één bibliotheek is die alles bevat. Maar alles voor betalen staat daaronder inderdaad wel weer ergens in /Payments/ in meervoud, omdat er soms betalingen worden verwerkt met verschillende betaalsystemen in plaats van één betaling.
Ozzie PHP op 07/10/2013 12:17:29:
3) in mijn eerdere opzet had ik alle "technische" bestanden in het mapje "core" gezet, maar dat zijn dan eigenlijk dezelfde bestanden die nu in "framework" komen te staan?
Ja, dat is weer het argument dat je niet te veel naar het "soort" bestanden moet kijken. Wat is immers een "technisch bestand"? En zijn niet alle PHP-bestanden technisch? Kijk vooral naar de plaats in het grotere geheel: reguleert zo'n bestand alles, dan staat het hoog, dicht bij de core of kernel. Reguleert het iets specifieks, dan hoort het ergens anders.
Keer het anders om: je moet liefst enkel uit de plaatsing van een bestand al kunnen afleiden waar het bijhoort, dus niet uit de bestandsnaam en liever ook niet uit de extensie. Met andere woorden, je hoeft niet te raden wat bijvoorbeeld een /library/Shop/Payments/iDEAL/config.php doet.
Ozzie PHP op 07/10/2013 12:17:29:
Toevoeging op 07/10/2013 12:18:48:
4) gebruik jij eigenlijk hoofdletters bij mapnamen? Zou jij "PostNL" gebruiken of "postnl" (lowercase)?
4) gebruik jij eigenlijk hoofdletters bij mapnamen? Zou jij "PostNL" gebruiken of "postnl" (lowercase)?
Dat is een lastigere. Als je streng bent, gebruik je enkel een beginhoofdletter: Paypal, Ideal en Postnl. Maar leesbare directory-, bestands-, namespace- en klassennamen zijn mij meer waard, dus verkies ik PayPal met twee hoofdletters, iDEAL met een kleine letter aan het begin en PostNL volgens de spelling van PostNL zelf...
Gewijzigd op 07/10/2013 12:47:19 door Ward van der Put
2) oké
3) Oké, ik denk dat ik je begrijp.
4) oh, echt? Gebruik jij voor iedere map dan een hoofdletter? Of alleen in dit geval omdat het om een library gaat? Ik maak altijd m'n mapnamen en bestandsnamen lowercase. Wat is gebruikelijk? Of is dat ook weer een kwestie van smaak?
Ozzie PHP op 07/10/2013 13:01:49:
1) Ik snap wat je bedoelt, maar ik bedoel te zeggen... In mijn beleving is het framework het "ding" wat de flow regelt, van request van de cliënt tot response terug naar de cliënt. Ik zou dus zeggen dat een "library" onderdeel is van het framework, maar jij (zie hierboven) zet het als onderdeel van de library. Dat begrijp ik niet zo heel goed.
Nee, de library is alles dat je niet met http:// opent. In de library ga je een kookboek ophalen als je wilt gaan koken. Of een SwiftMailer als je wilt gaan mailen.
Ozzie PHP op 07/10/2013 13:01:49:
4) oh, echt? Gebruik jij voor iedere map dan een hoofdletter? Of alleen in dit geval omdat het om een library gaat? Ik maak altijd m'n mapnamen en bestandsnamen lowercase. Wat is gebruikelijk? Of is dat ook weer een kwestie van smaak?
Het is gebruikelijk om klassennamen met een beginhoofdletter te schrijven en methodennamen te beginnen met een kleine letter. Wel zo duidelijk: Foo is altijd een klasse en foo is altijd een methode.
Als je dit consistent doorvoert, leidt new Foo_Bar() dus naar /Foo/Bar.php.
Bovendien kun je alles .php noemen en hoef je niet te rommelen met .class en .inc.
Ward van der Put op 07/10/2013 13:47:58:
Het voorkomt bijvoorbeeld dat de autoloader strtolower() nodig heeft ;)
Ja, dat klopt... maar als je dan consequent bent, dan moet je dus iedere map met een hoofdletter beginnen. Doe jij dat ook? Dus is bij jou "library" eigenlijk "Library"?
Ward van der Put op 07/10/2013 13:47:58:
Bovendien kun je alles .php noemen en hoef je niet te rommelen met .class en .inc.
Wat heeft het een met het ander te maken dan? .class gebruik ik nooit hoor :)
Je ziet wel eens constructies waarbij een widget.class met een configuratie in widget.inc en een template in widget.phtml wordt gecombineerd in widget.php. Dat vind ik onpraktisch. Laat dan liever in de directorystructuur en (lange) bestandnamen zien hoe die widget is opgebouwd, niet in de extensies.
Ik doelde op de hoofdletter :) Als je consequent zou zijn, zou je dan niet iedere map-naam met een hoofdletter schrijven, dus Lib ipv lib...
De extensie .class gebruik ik nooit. Daarentegen is phtml voor je views wel een goede om aan te tonen dat het om een combinatie van php en html gaat.
Je moet het ook niet té puristisch aanpakken. Vroeger heette PostNL nog TNT Post en straks hebben ze misschien weer een andere naam. Dat is alleen nog geen reden om de code meteen te herschrijven.
Rijst bij mij nu wel ineens de vraag... als die externe partijen met hoofdletters werken, terwijl ik dat zelf niet doe... en ik gebruik dus strtolower in de autoloader... dan heb ik dus een probleem als ik jou goed begrijp???
Quote:
Het 'zicht' van je autoloader beperk je daarom tot /library/Ozzie/.
In mijn huidige situatie voer ik in de autoloader echter strtolower uit op de gehele filename. Als mijn class-naam bijv. Ozzie_Foo_Bar is dan gooi ik er een strtolower overheen en het bestand dat wordt aangeroepen is dan: ozzie/foo/bar.php
Ik heb er niet bij stilgestaan dat 3rd party libraries hoofdletters gebruiken. Hoe los ik dat het handigst op? Zelf dan ook maar hoofdletters gaan gebruiken? Dus niet ozzie/foo/bar.php maar Ozzie/Foo/Bar.php? Van de ene kant wel raar, want ik gebruik nergens hoofdletters in m'n bestands-/mapnamen. Zie jij nog een andere oplossing?
Je eigen autoloader kan zich daarom beperken tot de naamgevingsconventies die gelden voor /library/Ozzie/.
