[PHP] Extends - global of registry class?

[HollowGamer]

Goedemorgen Tweakers,

Ik ben bezig met een custom systeempje wat misschien in de toekomst gebruikt kan gaan worden voor een (simpel )CMS.

Ik heb gekozen voor Extends, zodat je een 'Core class' hebt, waar alle belangrijke functies instaan als dbconnect(), dbprefix(), etc. Maar ook queries voor het snel ophalen van settings.

Nu had ik het idee dus om Session te extenden met Core, zodat deze gegevens allemaal op te vragen zijn.
Na wat nalezen op Google sites, leek het misschien beter een registry class te gebruiken, maar waarom niet Extends? Global leek helemaal geen oplossing? (Security)

externe linkjes weg

Nu krijg ik niet getDbHandle() niet in de Session class ingeladen, deze blijft leeg.
Wanneer ik deze return $this->conn; verander in return 'dddd', zie ik wel met echo dddd, anders is deze leeg.
Dit zelfde heb ik ook met return $this->dbsettings['prefix']; maar doe ik return 'dddd', zie ik wel dddd.

Hopelijk kunnen jullie mij een stap verder helpen, ik ben al wat IRC's afgegaan, maar ook zij wisten niet het antwoord op mijn vragen.

Bedankt alvast!

[Voor 12% gewijzigd door Woy op 06-07-2011 12:44]

[CodeCaster]

Ik begrijp je vraag niet helemaal, maar je databaseverbinding kun je in ieder geval niet in je sessie opslaan, als je dat probeert. Iedere keer dat je php-script start, zul je opnieuw verbinding moeten maken. PDO regelt verder de connection pooling, dus daar hoef je je niet druk over te maken.

Daarnaast is je oplossing bijzonder creatief, maar niet bepaald netjes OO. In plaats van verantwoordelijkheden te scheiden, prop je alles wat je kan bedenken in één klasse en laat je die klasse vervolgens overerven door iedere andere klasse die je gebruikt.

Ik zou het een en ander juist opdelen (database/registry/session/cookies). Je databaseklasse heeft helemaal niks te maken met cookies, je wil helemaal geen SQL opbouwen in je sessieklasse, enzovoorts.

[ibmos2warp]

Je moet in objecten denken. Daarom 'kan' je niet het ene met het andere extenden. Als je bijvoorbeeld het object auto dan kan die wel extended worden door een Ferrari (want dat is ook een auto) maar niet door een fiets (want dat is geen auto).

[HollowGamer]

Bedankt voor jullie antwoorden. Wat ik begrijp je kunt alleen extenden als deze met elkaar te maken hebben, bijv.: Class AutoKleuren Extends Auto (?)

Maar hoe krijg ik nu bijvoorbeeld getDbHandle() naar mijn Session class zodat ik de gegevens in een database kan opslaan? Voorheen gebruikte ik global en dan de class naam, dus global $core.

Maar dat schijnt niet secure en snel te zijn, wat is een mogelijkheid om deze toch met elkaar te laten verbinden?
Ik heb iets gelezen over interface?

Is het ook geen probleem dat ik een class Core gebruikt, waar alle functies inzitten? Of kan ik dit ook beter splitsen?

Bedankt alvast!

[Voor 10% gewijzigd door HollowGamer op 06-07-2011 11:59]

[Joolee]

HollowGamer schreef op woensdag 06 juli 2011 @ 11:57:
Bedankt voor jullie antwoorden. Wat ik begrijp je kunt alleen extenden als deze met elkaar te maken hebben, bijv.: Class AutoKleuren Extends Auto (?)

Maar hoe krijg ik nu bijvoorbeeld getDbHandle() naar mijn Session class zodat ik de gegevens in een database kan opslaan? Voorheen gebruikte ik global en dan de class naam, dus global $core.

Maar dat schijnt niet secure en snel te zijn, wat is een mogelijkheid om deze toch met elkaar te laten verbinden?
Ik heb iets gelezen over interface?

Is het ook geen probleem dat ik een class Core gebruikt, waar alle functies inzitten? Of kan ik dit ook beter splitsen?

Bedankt alvast!

$dbHandle = new dbClass();
of
$dbhandle = dbClass::newHandle();

[CodeCaster]

Maak je niet druk over het veilig en snel zijn van variabelen, dat maakt echt geen sodeflikker uit. Het is alleen niet netjes om met globals te werken.

Je wil je databaseklasse blijkbaar aanspreken vanuit je sessieklasse. Dan kun je een instantie daarvan aan de constructor van de sessieklasse meegeven ($session = new Session($db)), of hem als property setten ($session->db = $db). Of je maakt bijvoorbeeld een singleton, waarbij je in je sessie-klasse dus Database::GetInstance() aanroept.

[Voor 5% gewijzigd door CodeCaster op 06-07-2011 12:04]

[ibmos2warp]

HollowGamer schreef op woensdag 06 juli 2011 @ 11:57:
Bedankt voor jullie antwoorden. Wat ik begrijp je kunt alleen extenden als deze met elkaar te maken hebben, bijv.: Class AutoKleuren Extends Auto (?)
[....]

Dat is het ook niet helemaal.
Een klasse AutoKleuren kan bijvoorbeeld wel de klasse Kleuren extenden (overerven).
Hoe bekend ben je met OOP?
Zie ook Wikipedia: Overerving (informatica)

[Janoz]

HollowGamer schreef op woensdag 06 juli 2011 @ 11:57:
Bedankt voor jullie antwoorden. Wat ik begrijp je kunt alleen extenden als deze met elkaar te maken hebben, bijv.: Class AutoKleuren Extends Auto (?)

Nee, extenden doe je wanneer iets iets is. Het moet allebei hetzelfde zijn waarbij de ene iets specifieker is. Bij object georienteerd ontwikkelen bepaald je de relaties tussen onderdelen door je af te vragen of de koppeling een 'is een' of een 'heeft een' is. Bij de eerste gebruik je extends en bij de tweede neem je het op als een property.

Dit alles gezegd hebbende wil ik nog wel even benadrukken dat het extenden van classes eigenlijk iets is dat lang zo veel niet gebruikt wordt als veel mensen denken. Als je begint kun je dat beter eerst nog links laten liggen. De grootste fout die vaak (en nu ook door jou) gemaakt wordt is te denken dat extenden een manier is om gegevens te delen. Dit is fout. Als je ene object iets nodig heeft van een ander object dan zul je meoten zorgen dat dat andere object het ene object kent, en niet is.

[HollowGamer]

ibmos2warp schreef op woensdag 06 juli 2011 @ 12:01:
[...]

Dat is het ook niet helemaal.
Een klasse AutoKleuren kan bijvoorbeeld wel de klasse Kleuren extenden (overerven).
Hoe bekend ben je met OOP?
Zie ook Wikipedia: Overerving (informatica)

Ik ben redelijk bekend met Classes, ik ken de __construct, __get, __set, __isset enz.
Maar hoe ik deze combineer met andere classes op een goede manier heb ik eigenlijk nooit geweten.

Maar wat ik nu begrijp is het beste om dit te gebruiken:
$db = Core::getDbHandle(); (?)

Oke Extenden is dus geen optie, ik begrijp nu voor wat het gebruik wordt.
Ik had het gewoon in een ander framework gezien, waarbij class Controllor extends Session werd gebruikt.

----------------------------------------------------
Maar nog steeds krijg ik niks terug:
http://pastebin.com/NLaBbawt
http://pastebin.com/NLaBbawt

M.a.w. hij haalt nog steeds mijn Class leeg?

[Voor 14% gewijzigd door HollowGamer op 06-07-2011 12:17]

[Barleone]

ibmos2warp schreef op woensdag 06 juli 2011 @ 11:54:
Je moet in objecten denken. Daarom 'kan' je niet het ene met het andere extenden. Als je bijvoorbeeld het object auto dan kan die wel extended worden door een Ferrari (want dat is ook een auto) maar niet door een fiets (want dat is geen auto).

offtopic:
No offence maar:
Huh? Als developer bepaal je toch hoe de 'wereld' van je programma in elkaar steekt?
Ik kan prima class Fiets extends Auto doen.
En vervolgens $fiets->raamOpendoen();

MAAR: het slaat nergens op EN het is hardstikke fout. Het hele idee is dus dat Fiets en Auto bijna niets met elkaar te maken hebben, dus je hebt er geen drol aan om het één met het andere te extenden.
Een correct voorbeeld zou zijn:

PHP:

class Fiets extends Vervoermiddel{}

PHP:

class Auto extends Vervoermiddel{}

PHP:

class Vervoermiddel
{
    function versnel(){ $this->snelheid++; }
    function stop(){ while($this->snelheid >0){ $this->remAf();} }
    function remAf(){ $this->snelheid--; }
    ...
}

[Voor 30% gewijzigd door Barleone op 06-07-2011 16:42]

[ibmos2warp]

Barleone schreef op woensdag 06 juli 2011 @ 12:14:
[...]

offtopic:
No offence maar:
Huh? Als developer bepaal je toch hoe de 'wereld' van je programma in elkaar steekt?
Ik kan prima class Fiets extends Auto doen.
En vervolgens $fiets->raamOpendoen();

offtopic:
Daarom had ik kan natuurlijk ook tussen apostrofs staan. Al laat je fiets weer overerven door jeGroteTeen, dat boeit die taal niet

[Janoz]

[miereneukmodus]
Wat jij nu als vervoermiddel gebruikt zou ik eerder als een interface dan als een superclass definieren .

[HollowGamer]

Maar wat doe ik nu fout? Gebruik ik de static verkeerd?
Sorry voor deze vragen, ik probeer de code nog een keer door te spitten..

[Barleone]

Janoz schreef op woensdag 06 juli 2011 @ 12:25:
[miereneukmodus]
Wat jij nu als vervoermiddel gebruikt zou ik eerder als een interface dan als een superclass definieren .

offtopic:
So true, my bad. (ff verbeteren) ^^ Woy zeurt teveel. FF wat gras voor de voeten weggemaaid.

[Voor 15% gewijzigd door Barleone op 06-07-2011 16:45]

[Woy]

Barleone schreef op woensdag 06 juli 2011 @ 12:30:
[...]

So true, my bad. (ff verbeteren) ^^

Een interface heeft geen ( lege ) implementatie

Verder wil ik de TS vragen om een wat concretere vraag te stellen. Op deze manier hoort het in ieder geval niet in PRG thuis. Het is niet de bedoeling om je complete code ergens extern neer te zetten en maar van ons te verwachten dat we dat gaan lezen. We zien hier graag kleine relevante stukjes code opgenomen in de post zelf.

Lees De Quickstart nog even door, en vul de benodigde informatie even aan. Daarmee bedoel ik dat je een klein concreet voorbeeld geeft, en daarbij aangeeft wat er niet wil lukken, en wat je al geprobeerd hebt om het op te lossen. Anders zal dit topic niet lang open blijven.

[Voor 62% gewijzigd door Woy op 06-07-2011 12:43]

[HollowGamer]

Woy schreef op woensdag 06 juli 2011 @ 12:40:
[...]

Een interface heeft geen ( lege ) implementatie

Verder wil ik de TS vragen om een wat concretere vraag te stellen. Op deze manier hoort het in ieder geval niet in PRG thuis. Het is niet de bedoeling om je complete code ergens extern neer te zetten en maar van ons te verwachten dat we dat gaan lezen. We zien hier graag kleine relevante stukjes code opgenomen in de post zelf.

Lees De Quickstart nog even door, en vul de benodigde informatie even aan. Daarmee bedoel ik dat je een klein concreet voorbeeld geeft, en daarbij aangeeft wat er niet wil lukken, en wat je al geprobeerd hebt om het op te lossen. Anders zal dit topic niet lang open blijven.

Beste Woy,

Ik verwacht niet dat de code wordt doorlezen, gewoon om het voorbeeld wat duidelijker te maken.
Excuses als dit wel zo was overgekomen.

Dit is dus eigenlijk wat ik wil, functies en instances ophalen vanuit een andere Class bijvoorbeeld Session.

Zo dus:

PHP:

$sql = 'INSERT INTO '[b].Core::getDbPrefix().[/b]'sessions ('.$sql_columns.') VALUES ('.$sql_values.')';
        
        $stmt = [b]Core::getDbHandle()->prepare($sql);[/b]
        if (!$stmt->execute($sessionData))
        {
            throw new Exception('Could not insert the new session');
        }

Maar dit wil mij niet lukken, hij leegt steeds de connectie.

Dus ik wil deze gewoon kunnen ophalen, that's it.

Dit geld dus niet alleen voor de database connectie maar ook voor andere functies.

[Voor 0% gewijzigd door RobIII op 06-07-2011 15:12. Reden: Code tags toegevoegd]

[Cartman!]

Wat lukt er niet? Wat krijg je terug uit die functies?

Ennuh... uit execute() en prepare() maak ik op dat je gebruik maakt van PDO maar als ik je dan gebruik zie maken van $sql_columns en $sql_values heb ik t idee dat je het nut van PDO niet helemaal begrijpt. Het is de bedoeling om die params te binden zodat PDO ze netjes voor je kan escapen.

[HollowGamer]

Dit is de hele code:

code:

protected function newSession()
    {
        $this->SessionId = $this->generateUniqueId();
        $this->SessionAgent = $_SERVER['HTTP_USER_AGENT'];
        
        $sessionData = array(
            'session_id' => $this->getSessionId(),
            'session_agent' => $this->getSessionAgent(),
            'session_start' => time(),
            'session_last_update' => time(),
            'session_ip' => '0',
            'session_location' => '0',
            'user_id' => -1,
            'session_logged_in' => '0'
        );
        
        $sql_columns = '';
        $sql_values = '';
        foreach($sessionData as $key => $value)
        {
            $sql_columns .= $key.', ';
            $sql_values .= ':'.$key.', ';
        }
        
        $sql_columns = substr($sql_columns, 0, -2);
        $sql_values = substr($sql_values, 0, -2);
        
        $sql = 'INSERT INTO '.$this->getDbPrefix().'sessions ('.$sql_columns.') VALUES ('.$sql_values.')';
        
        $stmt = $this->getDbHandle()->prepare($sql);
        if (!$stmt->execute($sessionData))
        {
            throw new Exception('Could not insert the new session');
        }

        $_SESSION[$this->sid_name] = $this->getSessionId();

        return $this->getSession();
    }

Ze worden als het goed is wel gebind, maar er is natuurlijk altijd ruimte voor verbetering.
Maar ik wil dus gewoon PDO gebruiken, en ik haal deze op via de class Core, onder de functie getDbPrefix();.

[Zeebonk]

Voor zover ik je begrijp wil je allerlei zaken tussen objecten delen zonder ze expliciet te hoeven delen.

Als je aan de functie newSession gewoon mee geeft wat deze functie nodig heeft is je probleem opgelost en is het veel duidelijker te zien wat voor resources de functie gebruikt.

Elke functie die jouw Core klasse instantie nodig heeft, krijgt deze mee als functie parameter:

PHP:

class Core
{
    function __construct() { /* db connectie hier aanmaken */ }

    function prefix() { /* prefix code */ }
    
    function getHandle() { /* get handle code */ }  
}

function newSession($core)
{
    /* knip */
    
    $sql = 'INSERT INTO '.$core->prefix().'sessions ('.$sql_columns.') VALUES ('.$sql_values.')';
    $stmt = $core->getHandle()->prepare($sql);
    
    /* knip */
}

$core = new Core();

newSession($core);

ietsAnderMetCore($core);

Niet moeilijker maken dan het is

[Cartman!]

HollowGamer schreef op woensdag 06 juli 2011 @ 15:00:
Dit is de hele code:

code:

// code

Ze worden als het goed is wel gebind, maar er is natuurlijk altijd ruimte voor verbetering.
Maar ik wil dus gewoon PDO gebruiken, en ik haal deze op via de class Core, onder de functie getDbPrefix();.

Ok, die worden wel gebind ja (allemaal als string alleen, maargoed) Ik zou het zelf iets anders aanpakken maar da's een kwestie van smaak misschien.

[HollowGamer]

Bedankt voor jullie antwoorden!

Ik heb het nu anders gedaan, even controleren, het werkt wel goed.

Ook heb ik besloten om alle queries in de class.db te zetten, zo staat dit allemaal goed bij elkaar, goed idee?

index.php

code:

<?php
$db = new Db($settings['db']);
$db->dbconnect();

$userSystem = new UserSystem($db, $settings);
?>

class.db:

code:

<?php
class Db
{
    private $_conn = null;
    private $_dbsettings = null;

    function __construct($db)
    {
        $this->_dbsettings = $db;
    }
    
    function dbconnect()
    {
        try
        {
            $this->_conn = new PDO('mysql:host='.$this->_dbsettings['host'].';port='.$this->_dbsettings['port'].';dbname='.$this->_dbsettings['dbname'].';', $this->_dbsettings['user'], $this->_dbsettings['pass'], array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));
            if ($this->_conn->getAttribute(PDO::ATTR_DRIVER_NAME) == 'mysql')
            {
                $this->_conn->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
                $this->_conn->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);
            }

            $this->_conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }

        catch(PDOException $e)
        {
            die('<strong>Database connection error:</strong> please try again in a few minutes.');
        }
    }

function getAllSettings()
    {
        $dbSettings = $this->_conn->query('SELECT name, value, serialized FROM settings');
        $tmpSettings = array();
        foreach($dbSettings as $item)
        {
            $tmpSettings[$item['name']] = $item['value'];
        }
        
        return $tmpSettings;
    }
}
?>

class.usersystem.php:

code:

class UserSystem
{
    private $_db;
    private $_settings;

    function __construct(Db $db, Settings $settings)
    {
        $this->_db = $db;
        $this->_settings = $settings;

        echo $this->_settings->get('cookie_expires');
    }
}
?>

Bedankt voor de reacties, ik begrijp nu gelukkig wel hoe je global kunt vervangen.

[MueR]

Alle queries in 1 file? Dat is behoorlijk onhandig.

[HollowGamer]

Why? Als ik een meerdere queries nodig zou hebben, dan zou ik deze toch makkelijker kunnen ophalen?
Of zorgt dit voor erge overkill?

(Gewoon een vraag, geen verwijt. ).

[Freeaqingme]

Zou wel kunnen, totdat je 15000 queries hebt die je constant in 1 bestand moet gaan opzoeken.

Lang, lang geleden gebruikte ik ook php om websites te maken, en dat noemde ik programmeren. Het werkte, en mijn classes zaten netjes vol functions (wat niet het idee van OOP is). Toen ben ik op een gegeven moment het Zend Framework (ZF) gaan gebruiken en toen ging er een wereld voor me open - juist omdat dit vol met best-practices zit, en relatief netjes geprogrammeerd is.

Mijn advies is dan ook om een degelijk framework te gebruiken (ZF of Symfony), en hier vooral goed te kijken hoe men in het framework met methods & objects & classes om gaat. Daar leer je uiteindelijk veel meer van door zelf het wiel proberen opnieuw uit te vinden.

[kwaakvaak_v2]

Daar leer je uiteindelijk veel meer van door zelf het wiel proberen opnieuw uit te vinden.

Daar ben ik het niet mee eens, je leert namelijk meer van het maken van fouten en begrijpen waarom het fout was, dan van het lezen van code die door iemand gemaakt is, die diezelfde fouten ongetwijfeld ooit ook een keer gemaakt heeft, maar niet in de code uitlegt waarom die persoon een keuze gemaakt heeft om het te doen zoals nu. En omdat iets in een framework zit, wil dat nog niet zeggen dat het per direct een best practice is.

[YopY]

kwaakvaak_v2 schreef op zaterdag 09 juli 2011 @ 11:13:
[...]
Daar ben ik het niet mee eens, je leert namelijk meer van het maken van fouten en begrijpen waarom het fout was, dan van het lezen van code die door iemand gemaakt is, die diezelfde fouten ongetwijfeld ooit ook een keer gemaakt heeft, maar niet in de code uitlegt waarom die persoon een keuze gemaakt heeft om het te doen zoals nu. En omdat iets in een framework zit, wil dat nog niet zeggen dat het per direct een best practice is.

Uiteindelijk is het wel zo (imho) dat de belangrijkste les die je moet leren uit het opnieuw uitvinden van het wiel is dat je het niet moet doen.

[kwaakvaak_v2]

Weet ik niet... Als Fabien Potencier zijn wiel niet opnieuw had uitgevonden omdat de techniek (PHP 5.3, closures etc) ook vooruit gegaan was, was symfony2 nooit ontwikkeld. Hetzelfde geld ook voor ZF2, Drupal7 en eigenlijk alle andere systemen. De makers van die frameworks hebben ook geleerd van de fouten die ze in een eerdere versie gemaakt hebben, en zichzelf verbeterd door tussentijds wielen uit te vinden, met nieuwe features spelen, gewoon een idee hebben en uitwerken, met risico op falen. Waarom zou dat voor een individuele ontwikkelaar anders zijn dan, je leert immers ook geen piano te spelen door het boek over piano's te lezen en te begrijpen waarom een piano geluid maakt als je op toets drukt. Je leert het door te doen, fouten te maken en verder te gaan.

[Voor 27% gewijzigd door kwaakvaak_v2 op 09-07-2011 13:03. Reden: extra stroofke..]

[Freeaqingme]

Als je piano gaat spelen doe je dat ook op een piano die al door experts gebouwd is, op een model wat zich door de eeuwen heen ontwikkeld heeft tot wat het nu is. Als iedere beginnende pianospeler eerst z'n eigen piano moet gaan ontwikkelen naar eigen inzicht dan blijft het ook crap (no offense). Waarom? Omdat je niet eeuwen de tijd hebt om jezelf door te ontwikkelen.

Daarnaast zijn ZF, SF en Drupal team efforts. Ieder ontwikkeld door een groep van doorwinterde programmeurs die allemaal hun eigen stukje kennis inbrengen. Die cumulatieve wijsheid heb je als individu niet, laat staan als je wat dit betreft nog maar net begonnen bent.

[johnkeates]

Ik sluit me hier bij aan. Hoewel dingen leren en wielen opnieuw uitvinden ook zijn voordelen heeft, moet je soms gewoon schone code kloppen en gebruiken wat er in de wereld te krijgen is. Als je een project aan het verwerken bent waarbij het uiteindelijke doel het verwerken van gebruikersgegevens is, dan kan je maar beter niet met knutselwerkjes aan komen zetten Niet om dat het automatisch 'slecht' is, maar om dat je behalve dingen leren ook nog een compleet product klaar moet zetten. Naast opdrachten en projecten kan je altijd nog voor jezelf dingen leren en verzinnen, maar voor iets wat massaal ingezet wordt, of in een commerciele omgeving toegepast gaat worden, (of gewoon 'de wereld') is inderdaad cumulatieve wijsheid van een team met jaren ervaring toch meer wat je op zal moeten zoeken.

[Ventieldopje]

Mocht nog je niet aan ZF willen beginnen omdat het voor veel mensen die ik spreek toch vrij overwelmend is, kun je overwegen om je zelf in te lezen in:

- Object Oriented Programming (OOP)
- Model View Controller (MVC) technieken zoals Zend Framework die gebruikt.

Zoiets is voor een kleinschalig of hobby project best leuk om te maken en daar leer je heel veel van, mocht je het door hebben hoe dat allemaal in elkaar steekt zou ik toch wel aanraden om over te gaan op Zend Framework of ander volwassen framework (no flame intended)

[kwaakvaak_v2]

Freeaqingme schreef op zaterdag 09 juli 2011 @ 13:11:
Als je piano gaat spelen doe je dat ook op een piano die al door experts gebouwd is, op een model wat zich door de eeuwen heen ontwikkeld heeft tot wat het nu is. Als iedere beginnende pianospeler eerst z'n eigen piano moet gaan ontwikkelen naar eigen inzicht dan blijft het ook crap (no offense). Waarom? Omdat je niet eeuwen de tijd hebt om jezelf door te ontwikkelen.

Waarom had ik deze opmerking verwacht op de piano metafoor Maar goed, als jullie liever niet begrijpen waarom ZF/SF doen wat ze doen, en het maar klakkeloos overnemen van het is door de community gemaakt dus goed principe. Maakt mij niet uit, ik moedig mensen liever aan om zelf na te denken waarom een bepaalde aanpak beter is, en daar kom je nu eenmaal nooit achter door maar klakkeloos over te nemen wat iemand anders voor je bedacht heeft.

En natuurlijk zit er een verschil tussen een enterprise applicatie, en gewoon een thuis hobby project gewoon omdat het kan. En ik heb het over de laatste. Voor een enterprise applicatie gelden andere regels, en ik ken ook maar weinig mensen die enterprise dingen in hun eentje schrijven

[Voor 12% gewijzigd door kwaakvaak_v2 op 09-07-2011 14:04]

[Freeaqingme]

Maar goed, als jullie liever niet begrijpen waarom ZF/SF doen wat ze doen, en het maar klakkeloos overnemen van het is door de community gemaakt dus goed principe

Waarom klakkeloos overnemen? Een dergelijk framework biedt gewoon handvatten, nieuwe inzichten & best practices. Zeker bij ZF (SF ken ik niet zo goed) kan je er vervolgens voor kiezen op een per-component basis of je die wel/niet wil gebruiken. Daarnaast hoef je 't niet klakkeloos aan te nemen dat iets op een bepaalde manier gedaan is, je kan altijd kijken in de proposal page waarom iets op een bepaalde manier gedaan is, of op IRC of een mailinglist vragen.

Toen ik met ZF begon had ik nog nooit van MVC gehoord, en toen ik dat wel had vond ik dat models nergens voor nodig waren ("immers, je kan je queries prima in je controllers zetten" ). Echter, doordat je het wel heel vaak tegen komt ga je er dan toch meer over lezen, meer over vragen, praten, en uiteindelijk toch zelf ook gebruiken.