Door
Ozzie PHP
op 30-12-2010 16:10
gewijzigd op 06-01-2011 13:17
50.694 views
Hmmm, laat ik de vraag toch maar eens stellen. Ik wil graag een eigen framework / beheersysteem maken. De bedoeling is dat ik als het systeem klaar is heel makkelijk een website kan maken waar meteen al een standaard cms gedeelte in zit.
Ik ben al begonnen met een framework en ik maak daarbij gebruik van Zend Framework, maar nu vraag ik me het volgende af. Ik heb behoorlijk wat PHP kennis en ervaring inmiddels, maar ik heb hier geen opleiding voor gehad. Ik wil het mezelf dan ook altijd zo makkelijk mogelijk maken als ik aan het programmeren ben. Voorbeeld, als ik een databasequery wil uitvoeren dan wil ik niet een hele query in te hoeven typen, maar wil ik simpele functies kunnen gebruiken, bijvoorbeeld: $database->setTable('tabel') en $row = $database->select('naam') etc.
Ook vind ik het handig dat ik in Zend Framework een route makkelijk kan koppelen aan een controller en een actie. Daarnaast gebruik ik de MVC structuur (modules), de Zend_Registry functie om iets op te slaan en gebruik ik de caching functie voor het cachen van gegevens.
Ik gebruik Zend Framework dus voornamelijk voor:
- maken van mooie routes
- routes koppelen aan controller en actie
- MVC structuur (modules)
- Zend_Registry om variabelen op te slaan
- Caching
Voor de rest gebruik in Zend Framework eigenlijk niet. Ik weet dat er heeeel veel mogelijkheden in Zend Framework zitten, maar ik ben niet iemand die dat allemaal wil uitvogelen, en ik wil toch altijd graag mijn eigen code schrijven zodat ik precies weet wat de code doet en hoe deze in elkaar zit (zodat het voor mijzelf logisch is en makkelijk te gebruiken).
Nu vraag ik me 2 dingen af:
1) is het voor mij eigenlijk wel zinvol om Zend Framework te gebruiken aagezien ik er niet heel veel mogelijkheden van benut.
2) zijn de 5 functies waar ik gebruik van maak (makkelijk) ook zelf te maken of is dat heel erg ingewikkeld?
Wat raden jullie aan? Zend Framework blijven gebruiken ook al gebruik ik er maar weinig van? Of toch zelf mijn eigen functies maken en Zend Framework niet meer gebruiken? Ik stel deze vraag ook omdat Zend Framework zo'n 23mb aan serverruimte in beslag neemt.
Thanks voor je toelichting.
[quote="Bas Cost Budde op 03/01/2011 13:57:37"]
__autoload() gaat bij elke niet-gevonden klasse af, of dat nu jouw 'classe' of 'model' is. Je moet dan dus op een of andere manier uitvinden waar je het bestand vandaan kunt includen; en dan is include_path zowel sneller als eleganter.
Dit begrijp ik nog niet helemaal. Het 1e stukje snap ik, dat ie af gaat bij iedere niet gevonden class. Maar wat daarna komt snap ik niet helemaal.
Stel $bla = new ModelBla().
Ervan uitgaande dat het model pad geinclude is, zegt autoload nu:
include('bla.php') // alleen de bestandsnaam wordt geinclude.
Klopt dat? Zo ja, dan zou je toch ook het model pad niet als include pad kunnen instellen en er voor zorgen dat autoload dit doet:
include('pad/naar/models/bla.php')
Nu weet PHP direct waar het bestand gevonden kan worden en hoeven niet eerst alle include paden te worden afgespeurd.
Of zie ik het nu verkeerd?
[/quote]
Vaak is het handig om niet __autoload te gebruiken, maar spl_autoload_register() waarmee je een autoload klasse registreert. Hier kan je dan bijvoorbeeld een prefix (Zend_) en een map meegeven. Dit is veel handiger dan handmatig te includen, omdat je dan maar 1 string hoeft aan te passen wanneer je de lib verplaatst.
pffff... nu raak ik helemaal de weg kwijt. Weet je hier toevallig ergens een voorbeeld van te staan? Of kun je wellicht zelf een stukje code tonen zodat ik begrijp wat je bedoelt?
Ik heb gekozen voor een interface omdat je er op gewezen wordt als je de methode load niet hebt geprogrammeerd. (Moet je wel de interface implementeren dat wel:)) En voor later is het handig voor als je bepaalde functies verplicht wilt maken. En uiteraard had je die eerst moeten bedenken maar goed je weet natuurlijk nooit op wat voor ideeën je later nog eens opkomt. Maar is misschien ook wat persoonlijke keuze.
Het aangekondigde Symfony Reloaded lijkt veelbelovend, vooral de ideeën achter de Kernel en Dependency Injection zijn indrukwekkend
Zeker zeker zeker:) En laat ik nu net op verzoek van ozzie en jasper een tutorial over Dependency Injection aan het schrijven zijn..
wat is overigens dat "lazy registreren van een object" waar Niels het eerder over had?
Precies, zoals pim en the force zeggen. Hier op PHPhulp is wel eens zo'n registry klasse in de script library toegevoegd: klik. Het wordt overigens overal voor gebruikt. Google eens op die term dan zal je genoeg informatie tegenkomen.
Een leuke tutorialreeks daarover
Dat bedoelde ik niet echt maar goed ;)
Of kun je wellicht zelf een stukje code tonen zodat ik begrijp wat je bedoelt?
Die heb ik je toch gegeven een paar berichten terug? Of is dat niet wat je bedoeld?
Hehe... inderdaad :)
Met die code bedoel ik dat spl_register_autoload ding....
Zo'n lazy object is wel mooi :) Maar wat is nu bijvoorbeeld het verschil of je een instantie van een object via een class ophaalt of via de class zelf? Waarom dus Registry::get('Database') en niet gewoon Database::get() ?
Anyhow... om maar weer eens helemaal naar het begin terug te gaan... Mijn vraag was dus of ik een eigen framework / cms systeem zou gaan bouwen... en het antwoord is... JA! Ik ga het gewoon doen :)
Wat ik nou in ieder geval heel handig zou vinden is om een soort genummerd lijstje te maken met wat er allemaal in moet. En dan ook met links er bij die ik kan gebruiken om dat specifiele onderdeel te bouwen. De bedoeling is dan dat ik uiteindelijk voldoende input heb om een frameworkje te bouwen. Het hoeft niet superingewikkeld te zijn, uiteindelijk is het de bedoeling dat ik een mooi systeempje heb waarmee ik makkelijk uit de voeten kan.
Wat ik tot nu gezien heb en wat ik zelf als heel handig ervaar zijn de onderstaande punten. Maar ik hoop dat jullie het lijstje dus aanvullen met handige (niet al te ingewikkelde)programmeertrucs die niet in mijn framework mogen ontbreken eventueel voorzien van links naar tutorials.
Tot nu toe:
1) MVC framework link
2) Router vervangen door betere versielink
3) Database active record link
4) method chaining $this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);
5) Lazy registreren objecten link
Zo'n lazy object is wel mooi :) Maar wat is nu bijvoorbeeld het verschil of je een instantie van een object via een class ophaalt of via de class zelf? Waarom dus Registry::get('Database') en niet gewoon Database::get() ?
Ik snap je niet helemaal. maar je wilt dus elke keer new Database doen? Of van alles een singleton maken? Ik snap ik je nu verkeerd?
Het principe van een registry is dat je objecten registreert en ze overal weer kunt opvragen.
Zo'n lazy object is wel mooi :) Maar wat is nu bijvoorbeeld het verschil of je een instantie van een object via een class ophaalt of via de class zelf? Waarom dus Registry::get('Database') en niet gewoon Database::get() ?
Ik snap je niet helemaal. maar je wilt dus elke keer new Database doen? Of van alles een singleton maken? Ik snap ik je nu verkeerd?
Het principe van een registry is dat je objecten registreert en ze overal weer kunt opvragen.
Ik snap het hele autoload principe nog niet goed... wel dat magische __autoload, maar ik begrijp niet wat spl_register_autoload precies doet en wanneer je dat moet gebruiken.
Zoals ik al eerder meldde heb ik geen IT opleiding gehad en ben dus niet zo heel bekend met design patterns, maar die Database is dan volgens mij een singleton. Met get roep ik dan telkens dezelfde instantie van de database aan. Dus daarom mijn vraag waarom je dan een registry gebruikt. Wat is precies het verschil?
Ik snap het hele autoload principe nog niet goed... wel dat magische __autoload, maar ik begrijp niet wat spl_register_autoload precies doet en wanneer je dat moet gebruiken.
In het kort, moet je een auto loader registreren. Dit houd in dat als er een klasse / interface wordt aangeroepen dan kijkt de autoloader of die gevonden wordt. zo niet dan wordt een methode die je hebt opgegeven als parameter aangeroepen met de klasse/interface als parameter en kun je het corresponderende bestand importeren.
Het gebruik is als volgt:
<?php
spl_autoload_register(array('AutoLoader', 'loader'));
?>
Snap je?
Zoals ik al eerder meldde heb ik geen IT opleiding gehad en ben dus niet zo heel bekend met design patterns.
Die heb ik ook niet gehad in mijn opleiding. Verder dan or die + hoe werk ik SQL injections in de hand ben ik ook niet gekomen. Totdat ik hier op phphulp kwam en werd afgekraakt tot Jericho. Daarna was het gewoon veel vragen stellen en veel googlen en lezen lezen lezen.
maar die Database is dan volgens mij een singleton.
Die van dat MVC framework? Ja dat klopt. Maar dat is nergens voor nodig. Daar zijn singletons helemaal niet voor bedoeld.
Singleton is bedacht voor het oplossen van een ander probleem: klik op te lossen: klik en die zul je in PHP bijna nooit tegenkomen.
Met get roep ik dan telkens dezelfde instantie van de database aan. Dus daarom mijn vraag waarom je dan een registry gebruikt. Wat is precies het verschil?
- Je houdt alles op 1 plaats
- Je kan er altijd bij
- enz
Ik bedoel dan heb je bijvoorbeeld in je script het volgende:
Dat kan je beter op 1 plaats beheerbaar houden. Als jij bijvoorbeeld de methode get toch wilt veranderen naar getDatabase() dan moet je eerst heel je applicatie doorlopen en alles gaan veranderen.
Begrijp ik nu goed dat je spl_autoload_register(array('AutoLoader', 'loader'));
gebruikt in plaats van de __autoload functie?
Framework_Database::get();
Dit geeft een instantie terug van de database? En altijd dezelfde instantie? Wat is dan het verschil met Regisrty::get('Database'), of komt dat op hetzelfde neer?
Framework_Database::get();
Dit geeft een instantie terug van de database? En altijd dezelfde instantie? Wat is dan het verschil met Regisrty::get('Database'), of komt dat op hetzelfde neer?
Volgens mij wil je hier juist een Registery gebruiken om juist niet aan singletons vast te zitten. Als je overal in je code Framework_Database::get() doet, kan je je database-class niet even gemakkelijk meer vervangen met een andere die dezelfde public interface* heeft. (waarom zou je dat willen? Omdat dat heel gemakkelijk debugt, en het theoretisch mooier is)
Ander probleem met singletons: hoe ga je je database de logingegevens meegeven voor de eerste keer verbinden? Nog een static method? En hoe ga je dan twee database-verbindingen naast elkaar maken? Framework_Database net niet helemaal singleton maken, zodat je en de default instantie hebt, en je nog eigen instanties kan maken? Dat wordt heel rommelig, en het is heel simpel op te lossen met een registery of een andere container.
* public interface van een class is alle publieke methods en hun argumenten. Als die voor twee classen hetzelfde zijn, of deels hetzelfde zijn en alleen die methods die hetzelfde zijn gebruikt, dan kan je die twee classes zonder problemen uitwisselen. Interfaces in PHP zijn een manier om dat af te dwingen (dat twee classes dezelfde public interface hebben, en dat je kan controleren of je een class hebt die inderdaad die interface heeft, via instanceof. Maar dat is allemaal detail.)
