juiste plek...
Stel je hebt een bootstrap, je stelt je autoloader in en jr roept je core/kernel class aan. Nu zit ik me wat af te vragen. Ik wil een aantal "eigen" functies inladen. Om die functies te kunnen gebruiken, moet ik ze natuurlijk zo vroeg mogelijk, dus aan het begin van het request, inladen. Wat is hier de juiste plaats voor: in de bootstrap file, nog voordat ik de core/kernel class aanroep? Of doe je dit juist in de constructor van de core/kernel class? Of maakt het niks uit? Wie kan me uitleggen wat de beste plaats is (als die er is) en waarom?
Mocht je dat niet willen zou ik het als eerste, voor de autoloader in je bootstrap zetten.
Merk trouwens op dat ik het totaal niet fijn vindt klinken dat je eigen functies hebt in je oo project..
Je hebt het over een aantal "eigen" functies, zijn die in eerste opzicht onderdeel van je framework?
Zo ja, dan zou je die dus in je core moeten plaatsen.
Zo nee, dan pas op het moment dat je het nodig hebt.
Noem even wat geks: stel je functie handelt email af, dan kan dit een onderdeel zijn van je framework.
Maar heb je hem meteen nodig? nee niet perse. Immers is een email functie pas nodig als men zich registreerd of als men contact met je zoekt. Dus dan hoeft hij niet perse in de core geladen te worden..
"Ik zou het een optie maken van je autoloader, het automatisch laden van ingestelde bestanden."
Ik snap niet wat je hiermee bedoelt. Het zijn geen class functies, dus ik kan ze ook niet inladen via de autoloader.
"Je hebt het over een aantal "eigen" functies, zijn die in eerste opzicht onderdeel van je framework?"
Je, ze horen gewoon bij het framework, want ik wil ze overal in het framework kunnen gebruiken. Maar de vraag is, laad je ze in in de bootstrap file en roep je daarna je core aan, of roep je je core aan en laat je je core in de constructor de functies inladen.
Hetzelfde zou je ook kunnen zeggen voor (algemene) defines. Laad je die in de bootstrap in, of doe je dat vanuit de constructor van de core.
Kijk, beide opties zullen gewoon prima werken... alleen vraag ik me af wat de meest "geschikte" plaats is.
Quote:
bijvoorbeeld het aanmaken van een directory met standaardrechten, of juist het verwijderen van een directory, of een eigen soort var_dump functie. Functies die mijn leven wat makkelijker maken zeg maar.
Aanmaken/verwijderen directory hoort in een FileSystem class.
Eigen var_dump hoort in Debug::dump oid
>> Ik snap niet wat je hiermee bedoelt. Het zijn geen class functies, dus ik kan ze ook niet inladen via de autoloader.
Je kan in de register method bestanden laden met require.
"Aanmaken/verwijderen directory hoort in een FileSystem class."
Waarom stop je functies die php standaard aan boord heeft eigenlijk in een aparte class? Het mag natuurlijk, maar als jij bijv. een bestand wil laden gebruik jij dan ook geen require maar bijv. File::load of iets dergelijks?
Quote:
Ik zal even het begrip "functies" uitleggen. Het gaat echt om algemene functies, bijvoorbeeld het aanmaken van een directory met standaardrechten, of juist het verwijderen van een directory, of een eigen soort var_dump functie. Functies die mijn leven wat makkelijker maken zeg maar.
Oke, even terug naar de tekentafel zodat we het snappen wat je aan het bouwen bent. ;)
Zoals Wouter dit mooi omschijft dirs is toch een class opzich?
Ik denk dat je nog niet helemaal door hebt wat je precies aan het bouwen bent.
Aan de ene kant wil je een framework bouwen, een ding wat je leven als programmeur makkelijker maakt, aan de andere kant ben je al een applicatie aan het ontwikkelen waarmee je de functionaliteit aan het regelen bent.
Het is misschien voor je een goed plan om die twee dingen te scheiden van elkaar. Want je bent nu het jezelf heel lastig aan het maken. Een RAAMWERK moet een ding zijn dat voor jou met een paar regels code een oplossing bied.
Je moet het niet andersom doen. Want dan blijf je hangen in dit soort problemen die er niet zijn...
@Bart: "Aan de ene kant wil je een framework bouwen" Precies! Maar ik heb dus wat "native" functies. Het klinkt misschien spannender dan dat het is.
"Zoals Wouter dit mooi omschijft dirs is toch een class opzich?"
Bedoel je dat jij een aparte class hebt voor dirs? Dus om dirs aan te maken en verwijderen? Uiteraard kan dat, maar waarom zou je daar niet gewoon de native php functies voor gebruiken?
Quote:
Bedoel je dat jij een aparte class hebt voor dirs? Dus om dirs aan te maken en verwijderen? Uiteraard kan dat, maar waarom zou je daar niet gewoon de native php functies voor gebruiken?
Ik ga nu even een heel slecht voorbeeld aanhalen dus Wouter mag even niet meelezen. :)
We hebben Jquery. Een javascript framework.
Vooral een beginnend webdeveloper vergelijkt Jquery ala javascript.
Ergens klopt dat ook. Immers is het javascript.
Dus ik heb de keuze tussen om een AJAX request te doen met, laten we zeggen 10 regels code tegen 50 regels code, immers kan ik het ook met plain old school javascript. Dan is die keuze eenvoudig natuurlijk, met 10 regels code heb ik een probleem opgelost. En dat is nou juist de kracht van een framework.
Zo zou jij het ook moeten doen in jou framework.
Immers, als je zover bent dat je een applicatie gaat maken met je framework, dan pas kan je zeggen of het goed werkt.
Ik lees regelmatig jou topics mee, en valt me op dat jij die 2 dingen door elkaar haalt.
(althans, dat lees ik zo soms en dat bedoel ik echt niet negatief hoor)
Soms zie ik dat je met je applicatie bezig bent waarop je je framework aan het aanpassen bent.
En dat is nou net niet de bedoeling van een framework. Het moet simpel en dom gezegt de kortste route zijn naar een oplossing.
Ik ben geen framework aan het bouwen, maar om een antwoord te geven op je vraag of ik native php functies gebruik, dat ligt er maar net aan welke route het snelst is:
Is het een ding wat voor iemand die in zijn applicatie dirs aanmaken en verwijderen nodig heeft ja, dan gebruikt ik de native functions die php mij bied, misschien in een class, indien men dit wenst en als dat het eenvoudiger maakt.
Wil iemand het met een bestaand framework het hebben (hoewel het dan een framework moet zijn wat bekend is, dan kijk ik of daar die functionaliteit in zit. Immers, we gaan voor de kortste route. (time is money toch)
O ja, en dan heb je ook nog een categorie beginners, dan word het uiteraard gewoon just plain old school php zodat het een noob ook nog snapt. ;)
Gewijzigd op 09/10/2013 01:30:09 door Bart V B
Alleen er zijn natuurlijk meerdere wegen die naar Rome leiden. En soms wordt hier gesuggereerd dat er maar 1 waarheid is :)
Misschien moet ik inderdaad afstappen van functies en alles in classes gieten, maar de vraag is dan hoever je moet gaat. Moet je file functions of directory functions in een aparte class stoppen? Of gebruik je de native php functies. Of... waar ik het nu over heb, gebruik je voor file/dir handelingen de native php functies, en vervang je functies die te kort schieten met eigen "native" functies. Als je gaat werken met een aparte clas voor file handelingen, dan betekent dit dat je overal waar je normaal een require zou gebruiken, je nu ineens een File::load (of iets dergelijks) moet gaan gebruiken. Dan ben je dus als het ware de native php functies aan het nabouwen. Ik weet niet of dat good practice is.
Quote:
En soms wordt hier gesuggereerd dat er maar 1 waarheid is :)
Dat is niet zo, de waarheid is maar net waar JIJ genoegen mee neemt.
Daarom zei ik dus even een stapje terug doen en naar de tekentafel.
Quote:
Dan ben je dus als het ware de native php functies aan het nabouwen
Dat klopt, maar dat is nou juist het mooie van een framework bouwen, en heeft niets met de applicatie laag zelf te maken.
En daarom zei ik dus dat je een van de twee dingen even los van elkaar moest bekijken.
Een good praktice is, als het je probleem (nogmaals) oplost.
Dus als jij er in keer ervoor kunt zorgen met een paar regels code dat iets "slimmer/beter" werkt dan is het goed.
Het zou dus geen goed of fout vraag mogen zijn.
Aan de andere kant mag je natuurlijk wel "dromen" hoe zou dit werken in mijn applicatie, en dat is eigenlijk wat Wouter en andere hier zeggen. Nogmaals, programmeren is niet iets wat goed of fout is, alleen soms zijn die dingen misschien van input van andere net even wat slimmer. Je zou dat moeten meenemen of dat ook zo is in jou geval.
"Dat klopt, maar dat is nou juist het mooie van een framework bouwen, en heeft niets met de applicatie laag zelf te maken."
Kun je me uitleggen wat je met deze zin bedoelt, want ik snap niet helemaal wat je hiermee bedoelt.
Je applicatie laag weet totaal niets wat of welk framework gebruikt word.
Want, als ik jou theorie van je topics doorlees, dan gok ik zomaar dat je applicatie iets van functionaliteit gaat krijgen wat iets van een CMS-achtig ding zou moeten worden misschien wel een webhosting-achtig ding noem maar wat. ;)
En dat is nou juist het mooie daarvan, wat jij gaat maken met jou eigen code (framework) dat zou ik zomaar kunnen nabouwen met een framework die ikzelf gebruik.
Stel nou dat we het uber idee krijgen om een blog systeem te maken, dan kan jij dat bijvoorbeeld met OzziePhp framework inzetten en ik bijvoorbeeld met Codeigniter, of Laravel, misschien wel met BartPhp. Alleen jij doet het met de functionalitieit van Ozzie, en ik met Bart. Het uiteindelijke doel is dat we een blog applicatie hebben.
Echter, jou blog systeem doet iets van Ozzie::Blog en de mijne doet iets van $this->load->module->bart->blog.
Uiteindelijk zijn het beide blog systemen, alleen de look and feel zijn net even wat anders. Snap je?
Dat is precies wat ik bedoel.
Alleen zeg je het verkeerd om denk ik.(of lees het verkeerd) mag op dit tijdstip.
Of je gebruikt een "algemene" code, of die van jou eigen framework. Maar ga het niet mixen met elkaar of het moet heel goed verantwoord OO zijn.
Maar ik gaat naar bed, lees morgen wel de reakties. trusten iedereen. :)
Gewijzigd op 09/10/2013 02:56:03 door Ozzie PHP