include, haakjes of niet?
De spl autoloader biedt voordelen als je meerdere autoloaders wilt of gaat gebruiken. Dit kan zijn bij het integreren van third-part software OF als er in je eigen applicatie meerdere autoloaders gewenst zijn. Want je zult je CMS denk ik opdelen in framework code en application code? Met twee autoloaders in dat geval, eentje voor de applicatie-code (models, controllers, application-helpers) en eentje voor de echte framework classes (frontcontroller, router, andere meuk) voorkom je dus een lelijke if elseif else constructie :)
Je registreert bijvoorbeeld eerst de autoloader voor je framework classes en daarna voor je application-code. Als PHP de class niet kan includen met je framework autoloader dan zal hij naar de volgende autoloader in de stack gaan om te kijken of het application-code is.
In bovenstaand voorbeeld zou je het nog redelijk makkelijk in een __autoload functie kunnen zetten, maar naarmate je applicatie groeit en je steeds meer uitzonderingen krijgt dan biedt het meer uitkomst en flexibiliteit.
En helemaal geen third-party software integreren is wel HEEL optimistisch vindt je niet ;-) ? Ga je dus zelf een eigen mailer class schrijven? (ipv PHPMailer, Swift oid te gebruiken) ga je ook zelf PDF classes bouwen (ipv FPDF, Zend_PDF, DomPdf, etc), etc. Dan ben je wel heel erg het wiel opnieuw aan het uitvinden.
Ik zou dan de volgende folder structuur voorstellen:
Hierin doe je eigen framework classes
library/frameworknaam
En hierin third-party
library/vendor
BV:
library/vendor/phpmailer.class.php
Dan heb je dus al 3 autoloaders nodig omdat de phpmailer class geen mooie PHP-PSR-0 naam heeft ;-)
Je registreert bijvoorbeeld eerst de autoloader voor je framework classes en daarna voor je application-code. Als PHP de class niet kan includen met je framework autoloader dan zal hij naar de volgende autoloader in de stack gaan om te kijken of het application-code is.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
spl_autoload_register(function($className) {
//explode etc
if(file_exists('application/code/..../')) {
include_once ...
}
});
spl_autoload_register(function($className) {
//explode etc
if(file_exists('lib/framework/..../')) {
include_once ...
}
});
?>
spl_autoload_register(function($className) {
//explode etc
if(file_exists('application/code/..../')) {
include_once ...
}
});
spl_autoload_register(function($className) {
//explode etc
if(file_exists('lib/framework/..../')) {
include_once ...
}
});
?>
In bovenstaand voorbeeld zou je het nog redelijk makkelijk in een __autoload functie kunnen zetten, maar naarmate je applicatie groeit en je steeds meer uitzonderingen krijgt dan biedt het meer uitkomst en flexibiliteit.
En helemaal geen third-party software integreren is wel HEEL optimistisch vindt je niet ;-) ? Ga je dus zelf een eigen mailer class schrijven? (ipv PHPMailer, Swift oid te gebruiken) ga je ook zelf PDF classes bouwen (ipv FPDF, Zend_PDF, DomPdf, etc), etc. Dan ben je wel heel erg het wiel opnieuw aan het uitvinden.
Ik zou dan de volgende folder structuur voorstellen:
Hierin doe je eigen framework classes
library/frameworknaam
En hierin third-party
library/vendor
BV:
library/vendor/phpmailer.class.php
Dan heb je dus al 3 autoloaders nodig omdat de phpmailer class geen mooie PHP-PSR-0 naam heeft ;-)
Gesponsorde koppelingen:
Dankjewel voor je toelichting. Oké, een PDF creators ga ik inderdaad niet zelf schrijven.
Maar wat ik dus dacht is om via de naam van de class duidelijk te maken waar ie moet zoeken.
Het onderscheid tussen Framework classes en applicatie code (zoals jij noemt) zou ik dus volgens onderstaande structuur doen.
$test_applicatie_class = new Test();
$test_applicatie_model = new Test_Model();
$test_framework_class = new Test_Framework();
$test_framework_model = new Test_Framework_Model();
Dit kan ik nu via __autoload keurig opvangen.
Ik doe nu zelf dit:
function __autoload($class_name) {
Autoload::loadClass($class_name);
}
In mijn Autoload class handel ik het dan verder af.
Maar kan ik dan het bovenstaande stukje gewoon vervangen door:
spl_autoload_register(function($className) {
Autoload::loadClass($class_name);
}
Is dat voldoende?
Maar wat ik dus dacht is om via de naam van de class duidelijk te maken waar ie moet zoeken.
Het onderscheid tussen Framework classes en applicatie code (zoals jij noemt) zou ik dus volgens onderstaande structuur doen.
$test_applicatie_class = new Test();
$test_applicatie_model = new Test_Model();
$test_framework_class = new Test_Framework();
$test_framework_model = new Test_Framework_Model();
Dit kan ik nu via __autoload keurig opvangen.
Ik doe nu zelf dit:
function __autoload($class_name) {
Autoload::loadClass($class_name);
}
In mijn Autoload class handel ik het dan verder af.
Maar kan ik dan het bovenstaande stukje gewoon vervangen door:
spl_autoload_register(function($className) {
Autoload::loadClass($class_name);
}
Is dat voldoende?
Ja dat is voldoende. Maar waarom zou je dat los ervan doen?
Ah oke, thanks :)
Dat zal ik zo gaan proberen. Gracias!
Dat zal ik zo gaan proberen. Gracias!



