[MVC] Verantwoordelijkheid Controller vs View
Al langere tijd vind ik het leuk om wat met OOP programmeren te proberen (en vooral het idee van OO). Om die reden heb ik recent een MVC-Framework geschreven.
Dit heb ik nu in gebruik in een andere applicatie en ik loop tegen wat problemen aan.
Ik vind het moeilijk/onduidelijk de verantwoordelijkheden van de View en de controller te scheiden.
Voorbeeldcase:
Er wordt een request gedaan, deze wordt door de froncontroller opgevangen en de router/dispatcher zorgt ervoor dat de goede controller wordt aangeroepen en de bijbehorende method. In dit voorbeeld betreft het een method om een gastenboek bericht toe te voegen.
Je begint met het controleren van de meegegeven POST-waardes. Deze zijn echter niet correct omdat de gebruiker vergeten is zijn naam in te vullen.
Het bericht wordt dus niet toegevoegd en er moet worden verteld dat je de naam in moet vullen omdat het een verplicht formulierveld is en daar onder het formulier laat zien.
De schematische code
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
<?php
//voorbeeld code, de naam message is natuurlijk niet heel veel zeggend
public function addMessage()
{
try
{
$oForm = new Form('index.php?c=Gastenboek&m=addMessage', 'nameofform');
$oNameField = new Text('name', new Label('Name:', 'class_no_error', 'class_error'));
$oNameField->addValidator(new Required, new NotEmpty);
$oMessageField = new Textarea('message', new Label('Your message:', 20, 10 'class_no_error', 'class_error_textarea'));
$oMessageField->addValidator(new Required, new NotEmpty, new MinLength(3));
$oForm->addElement($oNameField, $oMessageField);
}
catch(Exception $oException)
{
if(Framework::$DEBUG == true)
{
echo $oException->getMessage();
}
else
{
$this->setView(new Error('Formulier kon niet geladen worden'), abstractView::$Notoverridable);
}
}
if($oForm->isSubmitted() && $oForm->isValid())
{
$oMessage = new Message($oNameField->getValue(), $oMessageField->getValue());
$this->saveMessage($oMessage);
header('Location: index.php?c=Gastenboek&m=Done');
}
elseif($oForm->isSubmitted() && !$oForm->isValid())
{
$oView = new addMessageView($oForm);
$oErrorLog = $oForm->getErrorLog();
foreach($oErrorLog as $oError)
{
if($oError->getValidator instanceof NotEmpty)
{
$oView->addError('Je ziet toch wel dat je een naam in moet vullen eikel!');
}
// etc elseif($oError->getValidator instanceof MinLength){ }
}
}
else
{
$oView = new addMessageView($oForm);
}
$this->setView($oView);
}
[/code]
Alleen zoals deze voorbeeldcode nu is ben ik niet blij met de scheiding output/logica(/data):
Je zou willen dat als je iets aan de output van je applicatie wil veranderen dat je dan alleen de view in moet duiken, maar zoals het nu is geeft de controller de hardcoded data aan de view wanneer er wat fout gaat en moet je dus toch op meerdere plaatsen zoeken als je de output wilt veranderen.
Hoe lossen jullie dat op? Voor elke mogelijke foutmelding een view maken en die dan aan een andere view meegeven met een [i]setError(Errorview $oView) functie[/i]? Dat lijkt me redelijk omslachtig omdat je 10000e foutmeldingen kunt hebben.
De kern van mijn probleem is dus hoe je hardcode data opslaat: in de view?(bijvoorbeeld een array met errornummers en errormeldingen en dan een setErrorNumber() functie?), in de controller?, in een Model?
Alvast bedankt,
Freek
[quote]
[b]Edit[/b]
Veel typo's, leestekens
[quote]
//voorbeeld code, de naam message is natuurlijk niet heel veel zeggend
public function addMessage()
{
try
{
$oForm = new Form('index.php?c=Gastenboek&m=addMessage', 'nameofform');
$oNameField = new Text('name', new Label('Name:', 'class_no_error', 'class_error'));
$oNameField->addValidator(new Required, new NotEmpty);
$oMessageField = new Textarea('message', new Label('Your message:', 20, 10 'class_no_error', 'class_error_textarea'));
$oMessageField->addValidator(new Required, new NotEmpty, new MinLength(3));
$oForm->addElement($oNameField, $oMessageField);
}
catch(Exception $oException)
{
if(Framework::$DEBUG == true)
{
echo $oException->getMessage();
}
else
{
$this->setView(new Error('Formulier kon niet geladen worden'), abstractView::$Notoverridable);
}
}
if($oForm->isSubmitted() && $oForm->isValid())
{
$oMessage = new Message($oNameField->getValue(), $oMessageField->getValue());
$this->saveMessage($oMessage);
header('Location: index.php?c=Gastenboek&m=Done');
}
elseif($oForm->isSubmitted() && !$oForm->isValid())
{
$oView = new addMessageView($oForm);
$oErrorLog = $oForm->getErrorLog();
foreach($oErrorLog as $oError)
{
if($oError->getValidator instanceof NotEmpty)
{
$oView->addError('Je ziet toch wel dat je een naam in moet vullen eikel!');
}
// etc elseif($oError->getValidator instanceof MinLength){ }
}
}
else
{
$oView = new addMessageView($oForm);
}
$this->setView($oView);
}
[/code]
Alleen zoals deze voorbeeldcode nu is ben ik niet blij met de scheiding output/logica(/data):
Je zou willen dat als je iets aan de output van je applicatie wil veranderen dat je dan alleen de view in moet duiken, maar zoals het nu is geeft de controller de hardcoded data aan de view wanneer er wat fout gaat en moet je dus toch op meerdere plaatsen zoeken als je de output wilt veranderen.
Hoe lossen jullie dat op? Voor elke mogelijke foutmelding een view maken en die dan aan een andere view meegeven met een [i]setError(Errorview $oView) functie[/i]? Dat lijkt me redelijk omslachtig omdat je 10000e foutmeldingen kunt hebben.
De kern van mijn probleem is dus hoe je hardcode data opslaat: in de view?(bijvoorbeeld een array met errornummers en errormeldingen en dan een setErrorNumber() functie?), in de controller?, in een Model?
Alvast bedankt,
Freek
[quote]
[b]Edit[/b]
Veel typo's, leestekens
[quote]
Gewijzigd op 01/01/1970 01:00:00 door Citroen Anoniem Graag
Naar mijn idee horen deze errors op zichzelf niet thuis in een view, vandaar dat ze in de controller / model zelf gezet zijn. Vervolgens is er uiteraard wel een view nodig (HTML, PDF, etc.) om werkelijk te laten zien dat er wat mis is gegaan.
... of het praktisch handig is vraag ik me af. Net als exceptions. Ik gebruik ze zelf erg graag, maar alleen voor de gevallen waar ik in de normale loop van de applicatie geen fouten verwacht. Dat iemand fout een formuliertje invult verwacht ik eigenlijk wel, en ik wil meerdere van deze fouten tegelijkertijd kunnen weergeven, en al dan niet hints geven over hoe het wel moet, welke tekens wel toegestaan zijn. (iets wat niet noodzakelijk in een exception zelf zit)
Midas schreef op 08.06.2009 18:14:
Hmm.. je kan het natuurlijk gewoon in je template zetten.. ik weet niet wat voor/of je een template engine gebruikt, maar je kan bijvoorbeeld bij Smarty ook gewoon if/else gebruiken. Ook is het een optie om met errornummers in combinatie met een bestand met talen erin te werken.
Een view is in mijn ogen niet bedoelt als data opslag, dus ook niet voor errorcodes, daar gebruiken we de models voor. (Models = data, Views = presentatie)
Tim schreef op 08.06.2009 21:13:
Iedere error gooit bij mij uiteraard een exception als dat nodig is. De tekst in deze exception is hardcoded gezet in de controller / model. Vervolgens wordt er één 'exception'-view geladen die overzichtelijk laat zien wat er is gebeurt.
Naar mijn idee horen deze errors op zichzelf niet thuis in een view, vandaar dat ze in de controller / model zelf gezet zijn. Vervolgens is er uiteraard wel een view nodig (HTML, PDF, etc.) om werkelijk te laten zien dat er wat mis is gegaan.
Naar mijn idee horen deze errors op zichzelf niet thuis in een view, vandaar dat ze in de controller / model zelf gezet zijn. Vervolgens is er uiteraard wel een view nodig (HTML, PDF, etc.) om werkelijk te laten zien dat er wat mis is gegaan.
Dat de tekst in de exception hardcoded in de controller/het model gezet is lijkt mij logisch. Maar vaak is deze boodschap niet bedoel om de bezoeker te tonen. Daarom moet de foutmelding die de bezoeker voor zijn neus krijgt ergens vandaan komen. En waar die van daan moet komen was juist mijn vraag ;).
'Vervolgens is er uiteraard wel een view nodig om werkelijk te laten zien dat er wat mis is gegaan.' I Agree
Jelmer schreef op 08.06.2009 21:19:
Je kan bij exceptions ook een foutcode opgeven (als 2e argument) Je zou aan je view nog een soort vertaal-class kunnen hangen die op basis van die errorcode dan de juiste melding geeft. Je kan dat in de view rechtvaardigen.
Dat zou ik inderdaad kunnen doen, ik heb er vannacht even over na gedacht en ik heb besloten de error codes hardcoded in een model te plaatsen (het is tenslotte data van de applicatie).
Door de data in een model te plaatsen is het mogelijk om later vrij makkelijk een meertalig systeem in te bouwen (aanpassing model zodat hij het uit een db op haalt). En je hoeft je tekst aanpassingen alleen maar in een model te doen, en de opmaak slechts in de views. Precies zoals dat in mijn ogen zou moeten.
Ik zit alleen nog met 1 probleem. Hoe kent de view het model? Het lijkt mij onhandig om deze steeds mee te moeten geven aan elke view. Want als je dan een ander model wilt moet je dat op veel plaatsen veranderen. En tegelijkertijd wil ik het ook niet abstraheren naar een parrent class want dan maak je een harde koppeling en verlies je dus de dynamiciteit (dat is geen woord, misschien dynamiek)
Jelmer schreef op 08.06.2009 21:19:
... of het praktisch handig is vraag ik me af. Net als exceptions. Ik gebruik ze zelf erg graag, maar alleen voor de gevallen waar ik in de normale loop van de applicatie geen fouten verwacht. Dat iemand fout een formuliertje invult verwacht ik eigenlijk wel, en ik wil meerdere van deze fouten tegelijkertijd kunnen weergeven, en al dan niet hints geven over hoe het wel moet, welke tekens wel toegestaan zijn. (iets wat niet noodzakelijk in een exception zelf zit)
Het gebruik van exceptions is in mijn ogen duidelijk. Die worden alleen gegooid als er een uitzonderlijke situatie optreed. Dus niet als er een formulier fout ingevuld wordt. Dit is immers standaard functionaliteit van een applicatie, geen uitzondering.
De exception die ik in het voorbeeld opvang is om te kijken of het formulier gegeneerd kan worden (niet 2x dezelfde elementnaam).
Conclusie so far:
foutmeldingen sla ik op in een model. In praktijk komen deze niet uit een db maar staan ze hardcoded getyped. Dit wordt een array met keys als identifier.
De message van een exception blijft voor debuggen, maar aan de hand van de error code die ik mee ga geven valt de 'mooie' errorcode te achterhalen.
2 problemen:
- Hoe kent de view het model?
- mooie manier om dubbele identifiers te voorkomen
Gewijzigd op 01/01/1970 01:00:00 door Citroen Anoniem Graag
Sowieso is het handig om vanuit de view bij je model-laag te kunnen komen. Het is zelfs verdomd handig, want zo hoef je niet de code om bijvoorbeeld recente topics te tonen in je footer in al je controllers op te nemen. Zend doet dat geloof ik door een "helper" te gebruiken, maar in weze is dat hetzelfde. De view kan de helper aanroepen, de helper heeft toegang tot het model (en nog veel meer, wat ik dan weer meer twijfelachtig vindt. Helper zou read-only moeten zijn)
Ik doe het zelf door een object waar alle instanties van de losse onderdelen van het model mee te geven bij het instantiëren van de view. Je kan ook singleton of registery gebruiken, maar dan heb je het nadeel dat jij noemt: je hebt je classnames hardcoded getypt. Daarnaast heb je minder controle over welke instantie (of beter: van welke class een instantie) je object gebruikt.
Mocht je door willen gaan voor dat foutmeldingen-in-model-idee, dan raadt ik een of andere vorm van namespaces aan. Classname-vd-exception+errorCode misschien?
Mijns inziens is een foutmelding die jij wilt weergeven niets anders dan een voor de gebruiker vriendelijke manier van melden dat je applicatie een probleem heeft.
Klopt met als aanvulling dat ik een usernotice geen applicatie error vind, maar dat het voor de gebruiker wél een error is.
Het is aan de presentatie-laag om te bepalen hoe die melding gaat worden gepresenteerd.
Klopt!
Waarom dan ook niet de presentatie-laag laten bepalen hoe de melding wordt gepresenteerd?
Wat is het verschil met de vorige zin?
Wat verschilt de kleur van de tekst van de gekozen woorden voor de tekst?
De kleur is slechts een weergave van de kennis maar niet de kennis zelf. De letterkleur van de foutmelding zou je in de printview misschien zwart willen hebben maar in de weblayout rood, terwijl de tekst onveranderd is. Daarmee is het in mijn ogen niet het zelfde.
Het is beiden onderdeel van de presentatie,
Klopt, echter is 1 deel van de presentatie de kennis (uit het model) en het andere deel de weergave van de kennis op een specifieke manier.
beiden van het vaste deel van de applicatie,
Dat is precies wat ik wil veranderen. Ik wil de meldingen niet in de controller hebben omdat het in mijn ogen niets anders is dan data en die daarom dus ook in die laag thuis hoort.
Sowieso is het handig om vanuit de view bij je model-laag te kunnen komen. Het is zelfs verdomd handig, want zo hoef je niet de code om bijvoorbeeld recente topics te tonen in je footer in al je controllers op te nemen. Zend doet dat geloof ik door een "helper" te gebruiken, maar in weze is dat hetzelfde. De view kan de helper aanroepen, de helper heeft toegang tot het model (en nog veel meer, wat ik dan weer meer twijfelachtig vindt. Helper zou read-only moeten zijn)
Daar heb ik inderdaad een loader voor, alleen moet je op die manier in elke view het model aanroepen. Iets wat flexibiliteit geeft maar ook veel dezelfde regels code.
Ik doe het zelf door een object waar alle instanties van de losse onderdelen van het model mee te geven bij het instantiëren van de view. Je kan ook singleton of registery gebruiken, maar dan heb je het nadeel dat jij noemt: je hebt je classnames hardcoded getypt. Daarnaast heb je minder controle over welke instantie (of beter: van welke class een instantie) je object gebruikt.
Ik heb die harde koppeling iets zachter gemaakt door aan een core class de optie mee te geven wat de Register class is (Framework::setAttribute(Framework::ATTR_REGISTER_CLASS, (Framework::ATRR_DEFAULT || callback)) Op die manier heb je echter nog steeds maar de mogelijkheid om 1 register te gebruiken, maar dat ter zijde.
De reden dat ik mij dit afvraag is puur flexibiliteit:
Na een tijd met mijn framework te hebben geëxperimenteerd vond ik het onbevredigend dat de presentatie niet puur uit .de view voortkwam in communucatie met een model (die door de controller geleverd wordt).* je moest toch in alle 3 de lagen rommelen als je net een iets andere zin wilde om te vertellen dat de inloggegevens niet juist waren/form niet ingevuld/je wel ingelogd moet zijn/je sessie is verlopen/javascript niet aan staat/.... .
*
Een View is een visuele representatie van zijn model(len). Het geeft bepaalde attributen van het model
weer en verbergt juist anderen. Je zou dus kunnen zeggen dat het fungeert als een presentatiefilter.
Een View is gekoppeld aan zijn model (of een gedeelte daarvan) en verkrijgt zijn informatie van het model
door hier vragen aan te stellen.
Waar ik nog wel mee zit is waar je precies je database instance, log instance, config instance, language instance etc. aanmaakt. Dit kan op verschillende manieren:
A - in je index.php en dan via een (soort) Registry doorgeven aan de FrontController. Deze zou het dan op zijn buurt kunnen injecteren in de controllers. Blijft het probleem dat je views en models ook toegang tot dit 'Registry' moeten hebben.
B - elke instance apart injecteren in je objecten. Op deze manier kan je bijvoorbeeld de view de toegang tot de database ontzeggen, wat me zeer logisch lijkt. Aan de andere kant leidt dit tot code die je liever kwijt bent dan rijk.
C - apart aanmaken in elk model / view / controller. Dit lijkt me sowieso geen goede oplossing. Zeker omdat je later ook alle instances wilt kunnen bereiken vanuit je plugins / widgets / libraries.
Momenteel is het bovenstaande waar ik nog mee zit. Ik vind geen van bovenstaande oplossingen echt ideaal, dus ik vraag me af wat de andere suggesties zijn.
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
Je zou je registery-dinges (het is bij mij niet helemaal registery, het is meer gewoon een dom object met properties, geen singleton, meer een soort context) deels kunnen kopiëren naar een wat afgeslankte versie voor de view.
Eigenlijk is deze manier niet eens zo heel vies, wanneer je je context/registery object volledig specificeert in een class die allemaal interfaces implementeert, waarbij iedere interface verteld dat er een bepaald object bij je registery opvraagbaar is. Dan heb je en het voordeel van één argument ipv een leger setters bij je controller en view, en het voordeel van de eisen die je aan classes kan stellen.
Je zegt dat je het model in je config opbouwt. Maar aangezien het vaak voorkomt dat je meerdere modellen binnen een controller gebruikt, hoe moet ik dit precies voor me zien?
Verder zie ik niet helemaal in hoe dat interface principe werkt. Ongeveer zo?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
<?php
class Context implements Database_Context, Cache_Context {
public function getDatabase();
public function setDatabase(Database $db);
public function getCache();
public function setCache(Cache $cache);
}
class MyController implements Database_Context {
//roept getDatabase() uit Context instance aan.
public function getDatabase();
}
?>
class Context implements Database_Context, Cache_Context {
public function getDatabase();
public function setDatabase(Database $db);
public function getCache();
public function setCache(Cache $cache);
}
class MyController implements Database_Context {
//roept getDatabase() uit Context instance aan.
public function getDatabase();
}
?>
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<?php
interface DatabaseProvider {
public function getDatabase();
}
interface CacheProvider {
public function getCache();
}
abstract Class Context {
}
Class ControllerContext extends Context implements DatabaseProvider, CacheProvider {
public function getDatabase() {}
public function getCache() {}
}
Class ViewContext extends Context implements CacheProvider {
public function getCache() {}
}
class Controller {
public function __construct(DatabaseProvider $context) {}
// of
public function __construct(Context $context)
{
if(!$context instanceof DatabaseProvider)
throw new InvalidArgumentException('Wrong context');
// doe iets met de db
if(!$context instanceof CacheProvider)
throw new CompleteFailure('Still wrong context...');
}
}
$x = new ViewContext();
$y = new Controller($x); // prrr! fout
?>
interface DatabaseProvider {
public function getDatabase();
}
interface CacheProvider {
public function getCache();
}
abstract Class Context {
}
Class ControllerContext extends Context implements DatabaseProvider, CacheProvider {
public function getDatabase() {}
public function getCache() {}
}
Class ViewContext extends Context implements CacheProvider {
public function getCache() {}
}
class Controller {
public function __construct(DatabaseProvider $context) {}
// of
public function __construct(Context $context)
{
if(!$context instanceof DatabaseProvider)
throw new InvalidArgumentException('Wrong context');
// doe iets met de db
if(!$context instanceof CacheProvider)
throw new CompleteFailure('Still wrong context...');
}
}
$x = new ViewContext();
$y = new Controller($x); // prrr! fout
?>
Het maakt op zich niet zoveel uit of je interfaces gebruikt of gewoon een method aan Context toevoegt die je kan vragen of de context een bepaalde instantie van iets kan leveren. Eigenlijk is het puur syntactic sugar. Nu kan je aan de buitenkant van het object zien of het het goeie object is, en anders moet je het vragen. (In talen als C++ had het wel uitgemaakt omdat het daar tijdens compilen berekend kan worden. PHP doet de controle altijd pas wanneer hij hem tegenkomt bij het uitvoeren)
Ik gebruik dit ook om m'n model in op te slaan, omdat m'n config scriptje zeg maar hier op neerkomt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
$context = new Context();
$pdo = new PDO('...');
$context->set_pdo($pdo);
// if memcache beschikbaar
$cache = new Cache_Memcache('...');
$context->set_cache($cache);
$topic_store = new Topic_Store($pdo, $cache);
$context->set_topics($topic_store);
// userstore gebruikt andere cache, niet beschikbaar voor de controllers
$slave_cache = new Cache_Memcache('...');
$user_store = new User_Store($pdo, $slave_cache);
$context->set_users($user_store);
return $context;
?>
$context = new Context();
$pdo = new PDO('...');
$context->set_pdo($pdo);
// if memcache beschikbaar
$cache = new Cache_Memcache('...');
$context->set_cache($cache);
$topic_store = new Topic_Store($pdo, $cache);
$context->set_topics($topic_store);
// userstore gebruikt andere cache, niet beschikbaar voor de controllers
$slave_cache = new Cache_Memcache('...');
$user_store = new User_Store($pdo, $slave_cache);
$context->set_users($user_store);
return $context;
?>
Maar je kan je context class ook zo schrijven dat hij pas objecten aanmaakt wanneer ze voor het eerst aangeroepen worden. Scheelt weer in opstarttijd van je script.
edit: maar soms wil je ook wel eens alle topics van een user hebben. Ik heb dat zo opgelost (door ze los te koppelen. Je kan beiden zonder de ander gebruiken in principe) (werkt wel alleen met 5.3 en wat trucjes)
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
User_Record::prototype()->topics = function(User_Record $user) use ($topic_store)
{
return $topic_store->find_topics_by_user($user);
};
?>
User_Record::prototype()->topics = function(User_Record $user) use ($topic_store)
{
return $topic_store->find_topics_by_user($user);
};
?>
Trucje met getters, closures en late static binding in PHP 5.3. Ik voeg tijdens runtime methods aan User objecten toe om gemakkelijk bij hun topics te komen. Maar ik kan ook nog $topic_store->find_by_user($User) aanroepen. Ook weer syntactic sugar, maar ik vind $user->topics() toch leuker staan. Dit gaat echter wel weer compleet in tegen dat wat ik hierboven schreef over aan de buitenkant kunnen zien of een class iets kan. User_Record::topics() bestaat namelijk helemaal niet echt :)
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Op deze manier de zaken aanpakken zit volgens mij wel muziek in. Enkel als je contexten wilt doorgeven bijvoorbeeld van de Controller naar de View wordt het wel een vager verhaal.
De view moet beschikken over bijvoorbeeld de language context, terwijl dit bij de controller niet in de context zit. Een oplossing zou zijn de view al in de frontController te setten, maar dat lijkt me niet de oplossing. En dan nog, dit probleem geldt ongetwijfeld niet alleen voor dit voorbeeld.
Verder wordt het tijd dat PHP5.3 uitkomt (sinds 11/6 RC3), namespaces bieden echt een groot voordeel (ten opzichte van o.a. de Poor Man's Namespace). Verder vind ik het dynamisch aanmaken van methoden bij objecten er veelbelovend uitzien.
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP