[PHP] Graag feedback op structuur/pattern in framework

zaterdag 24 juli 2010 15:37

Acties:

0 Henk 'm!

Topicstarter

Hoi,

Naar aanleiding van reacties in een vorig topic heb ik mij eens verdiept in programmeer-patterns. Vooral de factory- en singleton-aanpak vond ik reuze interessant, veel dank aan iedereen die me erop gewezen heeft.

Echter, ik kon met geen van de bekende aanpakken lekker werken. Ik heb daarom zelf maar wat in mekaar geknutseld, en bij de verschillende patterns hier en daar wat geleend (vooral factory en singleton). Tot nu toe heeft dat voor mij een prima werkbare aanpak opgeleverd, maar omdat ik het in mijn framework gebruik wil ik een beetje proberen vooruit te kijken of deze aanpak nu echt zo handig is.

Daarom ben ik benieuwd naar jullie mening over mijn (sterk vereenvoudigd weergegeven) aanpak:

index.php parsed een config.ini, en leidt daaruit oa af welke versie van het framework moet worden geladen.
het framework definieert een drietal global vars: de $debugger, $paths (met daarin enkele paths die vaak in de code terugkomen) en $incl, een soort backbone, zie hieronder.
het framework bepaalt vervolgens welk type file er wordt opgevraagd, en roept een docbuilder aan.
de docbuilder handelt een aantal standaard dingen af zoals bijv logging, voert evt custom code voor het bestand uit, kijkt vervolgens of het bestand in cache staat en zoniet compiled ie het bestand.
docbuilder output de content
framework report eventuele errors etc

Tot zover niks spannends, denk ik. Maar dan mijn $incl class.

PHP:

#--------------------------------------------------------------------------------------------------
#
#
# Notes:        Cascade:
#               [1] site theme / pagedir
#               [2] core theme / pagedir
#               [3] site pagedir
#               [4] core pagedir
#               [5] site theme
#               [6] core theme
#               [7] web root
#               [8] core
#
#--------------------------------------------------------------------------------------------------

class Path {



    #declarations----------------------------------------------------------------------------------
    private $public_objects = array();
    private $private_objects = array();



    #check if file is readable---------------------------------------------------------------------
    public function readable($file, $include_adds=true) {

        #include adds if needed
        if ( $include_adds ) { $include_adds = $this->readable(str_replace(strrchr($file, "."), "_add" . strrchr($file, "."), $file), false); }

        #lookup
        $cascade = $this->cascade($file);
        foreach ( $cascade as $vcasc ) { if ( is_readable($vcasc) ) { return true; }}

        #return false if not found
        return false;

    }



    #check if file is readable---------------------------------------------------------------------
    public function incl($file, $include_adds=true, $is_add=false) {

        #init
        global $_debug;
        $found = false;

        #include adds if needed
        if ( $include_adds ) { $this->incl(str_replace(strrchr($file, "."), "_add" . strrchr($file, "."), $file), false, true); }

        #lookup
        $cascade = $this->cascade($file);
        foreach ( $cascade as $vcasc ) {
            if ( is_readable($vcasc) ) {
                include($vcasc);
                $_debug->file[$vcasc] = true;
                $_debug->add_debuglog("Including " . $vcasc);
                if ( !$is_add ) { return true; }
                else { $found = true; }
            }
        }

        #return
        if ( !$found ) { return false; }
        else { return true; }

    }



    #check if file is readable---------------------------------------------------------------------
    public function incl_once($file) {

        #init
        global $_debug;

        #lookup
        foreach ( $this->cascade($file) as $vcasc ) {
            if ( is_readable($vcasc) ) {
                include_once($vcasc);
                $_debug->files[$vcasc] = true;
                $_debug->add_debuglog("Including " . $vcasc);
                return true;
            }
        }

        #return false if not found
        return false;

    }



    #lookup first file in cascade------------------------------------------------------------------
    public function lookup($filename, $include_adds=false) {

        #lookup
        foreach ( $this->cascade($filename) as $vcasc ) {
            if ( is_readable($vcasc) ) {
                if ( !$include_adds ) { return $vcasc; }
                else {
                    $return['self'] = $vcasc;
                    break;
                }
            }
        }

        #lookup
        if ( $include_adds ) {
            foreach ( array_reverse($this->cascade(str_replace(strrchr($filename, "."), "_add" . strrchr($filename, "."), $filename))) as $vcasc ) {
                if ( is_readable($vcasc) ) { $return['add'][] = $vcasc . $filename; }
            }
        }

        #return false if not found
        if ( isset($return) ) { return $return; }
        else { return false; }

    }



    #parse ini using the cascade-------------------------------------------------------------------
    public function parse_ini($file, $include_adds=true, $is_add=false) {

        #init
        global $_debug, $_file;
        $temp = false;
        $array = array();

        #add filehandler if needed
        $_file = $this->obj("_functions/file_handler/file_handler.php");

        #set cascade
        if ( $is_add ) { $cascade = array_reverse($this->cascade($file)); }
        else { $cascade = $this->cascade($file); }

        #lookup
        foreach ( $cascade as $vcasc ) {
            if ( is_readable($vcasc) ) {
                $temp = $_file->read_ini($vcasc);
                $_debug->files[$vcasc] = true;
                $_debug->add_debuglog("Including " . $vcasc);
                if ( !$is_add ) {
                    if ( $include_adds ) {
                        $include_adds = $this->parse_ini(str_replace(strrchr($file, "."), "_add" . strrchr($file, "."), $file), false, true);
                        if ( $include_adds ) { foreach ( $include_adds as $kadd=>$vadd ) { foreach ( $vadd as $kkadd=>$vvadd ) { $temp[$kadd][$kkadd] = $vvadd; }}}
                    }
                    return $temp;
                }
                else { foreach ( $temp as $kadd=>$vadd ) { foreach ( $vadd as $kkadd=>$vvadd ) { $finaltemp[$kadd][$kkadd] = $vvadd; }}}

            }
        }

        #return
        if ( isset($finaltemp) ) { return $finaltemp; }
        else { return false; }

    }



    #load objects----------------------------------------------------------------------------------
    public function obj($path, $public=true, $update=false ) {

        #if only one instance allowed and in cache
        if ( $public && isset($this->public_objects[$path]) ) {

            if ( $newsettings ) { foreach ( $newsettings as $kset=>$vset ) { $this->public_objects[$path]->change_setting($kset, $vset); }}
            return $this->public_objects[$path];

        }

        #if in cache
        elseif ( isset($this->public_objects[$path]) ) {

            #make new instance
            global $_settings;
            $classname = ucfirst(str_replace(".php", "", basename($path)));
            if ( !isset($_settings[strtolower($path)]) ) { $temp = new $classname(false); }
            else { $temp = new $classname($_settings[strtolower($path)]); }

            #if updates on
            if ( $update ) { $this->private_objects[$path][] = $temp; }

            #return the instance
            return $temp;

        }

        #if not in cache but public
        elseif ( $public ) {

            #include
            $this->incl_once($path);

            #make new instance
            global $_settings, $_debug;
            $classname = ucfirst(str_replace(".php", "", basename($path)));
            $_debug->add_debuglog("Init " . $classname);
            if ( !isset($_settings[strtolower($path)]) ) { $this->public_objects[$path] = new $classname(false); }
            else { $this->public_objects[$path] = new $classname($_settings[strtolower($path)]); }

            #return the instance
            return $this->public_objects[$path];

        }

        #if not in cache, no public
        else {

            #include
            $this->incl_once($path);

            #make new instance
            global $_settings, $_debug;
            $classname = ucfirst(str_replace(".php", "", basename($path)));
            $_debug->add_debuglog("Init " . $classname);
            if ( !isset($_settings[strtolower($path)]) ) { $temp = new $classname(false); }
            else { $temp = new $classname($_settings[strtolower($path)]); }
            if ( $newsettings ) { foreach ( $newsettings as $kset=>$vset ) { $temp->change_setting($kset, $vset); }}

            #if updates on
            if ( $update ) { $this->private_objects[$path][] = $temp; }

            #return the instance
            return $temp;

        }

    }



    #global settings update------------------------------------------------------------------------
    public function update_setting($file, $var=false, $value=false) {

        if ( !$var && is_array($file) ) { foreach ( $file as $kvar=>$vvar ) { $this->update_setting($kvar, $vvar, false); }}
        elseif ( !$value && is_array($var) ) { foreach ( $var as $kvar=>$vvar ) { $this->update_setting($file, $kvar, $vvar); }}
        else {
            if ( isset($this->public_objects[$file]) ) {  $this->public_objects[$file]->change_setting($var, $value); }
            if ( isset($this->private_objects[$file]) ) {  foreach ( $this->private_objects[$file] as $vobj ) { $vobj->change_setting($var, $value); }}
        }

    }



    #parse cascade items---------------------------------------------------------------------------
    private function cascade($filename) {

        #init
        global $_paths;

        #lookup using cascade
        if ( isset($_paths['page']) && isset($_paths['theme']) ) { $return[] = $_paths['web_root'] . "_themes/" . $_paths['theme'] . "/_pages/" . $_paths['page'] . "/" . $filename; }
        if ( isset($_paths['page']) && isset($_paths['theme']) ) { $return[] = $_paths['core'] . "_themes/" . $_paths['theme'] . "/_pages/" . $_paths['page'] . "/" . $filename; }
        if ( isset($_paths['page']) ) { $return[] = $_paths['web_root'] . "_pages/" . $_paths['page'] . "/" . $filename; }
        if ( isset($_paths['page']) ) { $return[] = $_paths['core'] . "_pages/" . $_paths['page'] . "/" . $filename; }
        if ( isset($_paths['theme']) ) { $return[] = $_paths['web_root'] . "_themes/" . $_paths['theme'] . "/" . $filename; }
        if ( isset($_paths['theme']) ) { $return[] = $_paths['core'] . "_themes/" . $_paths['theme'] . "/" . $filename; }
        $return[] = $_paths['web_root'] . $filename;
        $return[] = $_paths['core'] . $filename;

        #return
        if ( isset($return) ) { return $return; }
        else { return false; }

    }
}

De class doet in feite drie dingen:

Alle includes verlopen via een cascade, waarbij de prio loopt van specifiek naar algemeen. Dus indien er een file wordt geinclude kijkt ie eerst naar de custom code voor de gekozen pagina in de gekozen template, als die er niet is de custom code voor de gekozen pagina voor de site, enz, tot ie uiteindelijk uitkomt bij de custom code in het framework. Deze cascade kan worden uitgebreid met zogen. "adds", bestanden met dezelfde naam, alleen dan "add" erachter. Deze worden automatisch toegevoegd onderaan de te laden code. Zo kun je je op specifiek niveau beperken tot aanpassingen of aanvullingen van de code op algemeen niveau.
Objecten worden factorymatig aangeroepen. Omdat de ini file sections heeft met dezelfde naam als het bestand waarvoor de settings gelden worden automatisch de settings die bij het bestand horen meegegeven. Bovendien zorgt de code ervoor dat, tenzij anders aangegeven, er altijd maar 1 instance van een object wordt aangemaakt. Alle bestanden die toegang hebben tot deze class kunnen hun objecten dus delen.
Het is mogelijk om settings te wijzigen en vervolgens door te geven aan alle objecten tegelijk. Deze class zorgt ervoor dat de juiste updates bij de juiste objecten uitkomt.

Deze aanpak betekent wel dat classnames vastliggen, en elk object dezelfde constructor, en een method "change_setting" moet hebben. En dat globals nog steeds niet helemaal uitgebannen zijn. En, ook onhandig, dat elke include in elke code via deze $_incl moet lopen.

Toch wegen naar mijn ervaring tot nu toe deze nadelen op tegen de voordelen: Je kunt lekker snel ontwikkelen, alles kan met alles praten, en objecten maak je lekker makkelijk aan met

PHP:

1	$newobject = $_incl->obj("path_naar_object");

Als er al een instance bestaat dan krijg je die, anders maakt ie em voor je aan.Natuurlijk is dit geen zuivere meting, maar na invoeren van dit systeem geeft mijn debugger/profiler een snelheidswinst van meer dan 20% aan.

Kortom, ik ben best enthousiast, maar ik kan niet helemaal overzien of dit systeem ook op de lange termijn (bij redelijk grote en complexe systemen) handig is en gaat werken. Daarom graag jullie feedback (liefst inhoudelijk op de aanpak, en niet vallen over de programmeerstijl van de code zelf, daar ga ik zelf nog wel een keer aan schaven!).

Alvast bedankt, sowieso voor het lezen van deze lap tekst

zaterdag 24 juli 2010 15:44

Acties:

0 Henk 'm!

Verwijderd

Nofi, maar misschien moet je ook eens kijken naar code formatting. Dit is namelijk vrijwel onleesbaar zo.

Als je op termijn een goed te onderhouden systeem wil hebben zul je toch echt ervoor moeten zorgen dat de code bovenalles leesbaar is.

Staar je daarnaast niet dood op performance. Het is vaak veel goedkoper om een dikkere CPU in de server te prikken en daarmee gelijk een 20% winst te behalen dan het is om uren lang door de code heen te ploeteren op zoek naar snelheidswinst.

Probeer eerst gewoon te ontwikkelen wat je wil, goed leesbare en onderhoudbare code en een technisch solide systeem. Ga dan als je klaar bent kijken waar de grote bottlenecks zitten en probeer die aan te pakken.

Eventuele verdere optimalisatie komt pas als je uiteindelijk iets moet gaan deployen en in simulatie naar voren komt dat er mogelijk een performance issue is. Je kunt dan ook de juiste oplossing kiezen voor die situatie.

zaterdag 24 juli 2010 15:55

Acties:

0 Henk 'm!

xilent_xage

Topicstarter

Verwijderd schreef op zaterdag 24 juli 2010 @ 15:44:
Nofi, maar misschien moet je ook eens kijken naar code formatting. Dit is namelijk vrijwel onleesbaar zo.

None taken, maar zoals gezegd: dat fix ik wel een keer. Heb een 24" monitor, en bij mij ziet het er best netjes uit in mn editor

Verwijderd schreef op zaterdag 24 juli 2010 @ 15:44:
Probeer eerst gewoon te ontwikkelen wat je wil, goed leesbare en onderhoudbare code en een technisch solide systeem. Ga dan als je klaar bent kijken waar de grote bottlenecks zitten en probeer die aan te pakken. Eventuele verdere optimalisatie komt pas als je uiteindelijk iets moet gaan deployen en in simulatie naar voren komt dat er mogelijk een performance issue is. Je kunt dan ook de juiste oplossing kiezen voor die situatie.

Das een kwestie van smaak. In de praktijk heb je waarschijnlijk gelijk, maar de perfectionistische programmeur wil ook wat. En het kan natuurlijk nooit kwaad om voor je begint met het compleet herschrijven van je framework even goed na te denken over je opzet. Vandaar deze post

zaterdag 24 juli 2010 16:12

Acties:

0 Henk 'm!

X_lawl_X

Ik heb wat commentaar op je comments - Het is misschien beter om de PHPDoc syntax hiervoor te gebruiken. Voor jezelf maakt het misschien niet zo heel veel uit, alleen het maakt het wel makkelijker te begrijpen voor andere mensen die er eventueel later ook aan gaan werken.

Bovendien kunnen een aantal IDE's dit commentaar ook lezen, wat makkelijk voor jezelf kan zijn als je heel veel methods & classes hebt.

zaterdag 24 juli 2010 16:17

Acties:

0 Henk 'm!

Freeaqingme

Het gebruik van global; wordt over 't algemeen gezien als bad practice en anti-oop. Stel dat je nou nog van 10 andere vendors classes zou gebruiken, welke allemaal globals zouden gebruiken heb je in no-time conflicts van hier tot Tokyo.

Daarnaast; waarom zou je anno 2010 nog een eigen php framework gaan schrijven. Er zijn al enkele duizenden van dit soort fw's, en de kans is klein dat er geen eentje bij jou past

Ik zat 'vroeger' ook altijd aan te kloten met m'n eigen fw's die allemaal hun eigen beperkingen kenden, en op een gegeven moment ik 't Zend Framework gaan gebruiken: ik heb nog nooit zoveel in zo'n korte tijd geleerd, enkel door naar die code te kijken. Juist daarom zou ik als ik jou was eens naar een framework als 't Zend Framework of Symfony kijken.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.

zondag 25 juli 2010 15:21

Acties:

0 Henk 'm!

Cartman!

Met boven, je eigen framework maken gaat altijd enorm veel brakker zijn dan de bekende frameworks die daar al veel langer en veel beter (en met meerdere personen) over nagedacht hebben. Overigens gebruik ik niet klakkeloos alles in Zend Framework, sommige onderdelen zijn echt killing voor je performance.

maandag 26 juli 2010 11:09

Acties:

0 Henk 'm!

kwaakvaak_v2

Cartman! schreef op zondag 25 juli 2010 @ 15:21:
Met boven, je eigen framework maken gaat altijd enorm veel brakker zijn dan de bekende frameworks die daar al veel langer en veel beter (en met meerdere personen) over nagedacht hebben. Overigens gebruik ik niet klakkeloos alles in Zend Framework, sommige onderdelen zijn echt killing voor je performance.

maar wel leerzaam, door het maken van een eigen framework kun je wel leren hoe frameworks onder water kunnen werken, en ben je als ontwikkelaar wel instaat, mocht het project erom vragen, een eigen iets te maken. Of het voor een groot project verstandig is, dat is een andere vraag. Ik denk zelf van niet, om inderdaad de bovengenoemde reden van het onderhoud door één persoon vs een community. Aan de andere kant, als je kijkt naar het steeds logger wordende proces van updates binnen ZF1, en het feit dat het nu al een massieve 28Mb is geworden, is soms de keuze voor een simpele eigen router+db abstractie voor een klein project helemaal niet zo raar

Driving a cadillac in a fool's parade.

dinsdag 27 juli 2010 09:37

Acties:

0 Henk 'm!

dev10

kwaakvaak_v2 schreef op maandag 26 juli 2010 @ 11:09:
Aan de andere kant, als je kijkt naar het steeds logger wordende proces van updates binnen ZF1, en het feit dat het nu al een massieve 28Mb is geworden, is soms de keuze voor een simpele eigen router+db abstractie voor een klein project helemaal niet zo raar

Die Router en Database Abstractie kun je toch ook gewoon uit het Zend Framework halen? Dat is tenminste wat ik begrijp uit de documentatie. Zelf heb ik nog niks gedaan met ZF, maar ik ben wel van plan om er in de nabije toekomst iets mee te gaan doen.

dinsdag 27 juli 2010 10:08

Acties:

0 Henk 'm!

storeman

^^ Inderdaad, het hele framework is 28MB, maar daar zitten dan ook heel veel modules in die je niet elke request gebruikt. Deze kun je gewoon deleten als je dat wilt, maar ZF zal deze ook niet laden als je ze niet nodig hebt. De disk-size lijkt me niet erg relevant. (Er zitten ook vrij veel comments in!)

Ik heb zelf ook wel eens een FW geschreven, maar ben echt blij dat ik overgestapt ben naar ZF. Ik er heel veel van geleerd, patterns worden goed gebruikt. Ook abstractie en interfaces worden erg goed geimplementeerd. Sommig gedrag vond ik erg irritant, die overrule ik met eigen classes (die overerven van ZF classes). Zo kun je toch lekker customizen met een erg solide basis.

Voor performance van ZF kan ik iedereen overigens aanraden re require_once overal uit te slopen en een autoloader te gebruiken, dit scheelt behoorlijk in performance.

"Chaos kan niet uit de hand lopen"

dinsdag 27 juli 2010 10:36

Acties:

0 Henk 'm!

Tiemez

storeman schreef op dinsdag 27 juli 2010 @ 10:08:

Voor performance van ZF kan ik iedereen overigens aanraden re require_once overal uit te slopen en een autoloader te gebruiken, dit scheelt behoorlijk in performance.

behalve als je apc gebruikt, autoload kan apc niet cachen en require_once weer wel.

dinsdag 27 juli 2010 11:05

Acties:

0 Henk 'm!

kwaakvaak_v2

Tiemez schreef op dinsdag 27 juli 2010 @ 10:36:
[...]

behalve als je apc gebruikt, autoload kan apc niet cachen en require_once weer wel.

huh?? je kunt in je autoload toch ook gewoon een require_once doen? Autoload voorkomt imho alleen dat je alles in je bootstrap inlaad.

En ja je kunt een hoop uit ZF slopen, en dat is ook precies de reden waarom ik ooit het voorstel ondersteund heb, om voor ZF2 het model te kiezen wat symfony2 ook gebruikt. Een core, en dan mag je zelf de modules downloaden die je wilt gebruiken. Ik gebruik zelf namelijk liever zend_doctrine dan de zend_database extensie.

Maar vergis je niet, sommige dingen hangen in ZF1 alleen verder aan elkaar dan je zou verwachten. Als je Zend_mail wilt gebruiken moet je toch redelijk wat dingen includen die je voor het versturen van een mail eigenlijk niet nodig hebt. En dat is mijn persoonlijk grootste probleem wat ik met ZF1 heb, het is te gefragmenteerd. Kijk bijvoorbeeld eens naar de zend_bbcode en wat je daar voor moet includen. Alles opdelen in kleine files is leuk, maar op een VPS met een niet al te brede connectie naar een NAS is het dodelijk voor je performance. Teveel file_exist->require_once loops dat ik uiteindelijk maar een routine erin gehangen heb die bijhoudt wel includes er nodig waren, en die maar 1 in grote file heb gezet om de performance terug te krijgen

Driving a cadillac in a fool's parade.

dinsdag 27 juli 2010 11:39

Acties:

0 Henk 'm!

Tiemez

kwaakvaak_v2 schreef op dinsdag 27 juli 2010 @ 11:05:
[...]

huh?? je kunt in je autoload toch ook gewoon een require_once doen? Autoload voorkomt imho alleen dat je alles in je bootstrap inlaad.

apc genereert opcode voor je php files, bij autoload kan dat (bij de huidige implementatie) niet omdat het geen static code is. Apc gaat het vanaf php6 geloof ik wel ondersteunen.

[ Voor 3% gewijzigd door Tiemez op 27-07-2010 11:40 ]

dinsdag 27 juli 2010 12:00

Acties:

0 Henk 'm!

Cartman!

Zend Framework is wel groot maar daarvan heb je maar een fractie nodig, de meeste data komt uit een bak XML-files met allemaal vertalingen dus overdrijven is ook een vak

Overigens ben ik juist van autoloading afgestapt omdat het onnodig sloom is tov. een require_once uitvoeren op het moment dat je t nodig hebt. Icm. APC is het echt vlammend snel dan

dinsdag 27 juli 2010 12:22

Acties:

0 Henk 'm!

kwaakvaak_v2

Tiemez schreef op dinsdag 27 juli 2010 @ 11:39:
[...]

apc genereert opcode voor je php files, bij autoload kan dat (bij de huidige implementatie) niet omdat het geen static code is. Apc gaat het vanaf php6 geloof ik wel ondersteunen.

vanaf apc 3.1.1

apc.lazy_functions=On|Off
apc.lazy_classes=On|Off

enne php6?? Die komt er voorlopig echt niet meer hoor

Driving a cadillac in a fool's parade.

dinsdag 27 juli 2010 12:26

Acties:

0 Henk 'm!

Tiemez

kwaakvaak_v2 schreef op dinsdag 27 juli 2010 @ 12:22:
[...]

vanaf apc 3.1.1

apc.lazy_functions=On|Off
apc.lazy_classes=On|Off

enne php6?? Die komt er voorlopig echt niet meer hoor

Ah

ik gebruik een oudere (stable) versie, vandaar.

dinsdag 27 juli 2010 15:56

Acties:

0 Henk 'm!

Freeaqingme

kwaakvaak_v2 schreef op dinsdag 27 juli 2010 @ 11:05:
[...]

Maar vergis je niet, sommige dingen hangen in ZF1 alleen verder aan elkaar dan je zou verwachten. Als je Zend_mail wilt gebruiken moet je toch redelijk wat dingen includen die je voor het versturen van een mail eigenlijk niet nodig hebt.

Oh, zoals?