[php] classes, doe ik het goed?

[koffie-junk]

Ik heb gekozen voor het subforum 'programmeren', omdat ik al het een en ander geschreven heb, maar wat vragen heb over een aantal dingen. Ik zal bij het begin beginnen.

Inleiding
Ik mijzelf een aantal jaar geleden leren programmeren in PHP. Omdat ik zelf niet in de ict zit (een simpele student gymleraar, met een wat uit de hand gelopen hobby), heb ik er nooit veel behoefte aan gehad 'perfect' te coderen. Echter ben ik sinds een paar jaar webmaster van de vereniging hier in de buurt en ben ik begonnen met deze opnieuw opzetten. Ik heb alles dus zelf uit moeten vinden, waar ik veel van geleerd heb, maar ik zou graag willen weten of ik een beetje in de goede richting zit.

Waarom wil ik dat weten?
Ik ben bezig met een eigen CMS'je en werk vanuit wat classes en functies bouw ik de website op. De vereniging is nu zo blij dat ik de nieuwe website opzet, dat ze mij er een behoorlijke vrijwilligersvergoeding voor willen geven. Ik zit dan wel zo in elkaar, dat ik dan ook een goed product af wil leveren. Daarnaast ben ik benaderd door verschillende mensen die er ook interesse in hebben (voor een nieuwe website). Ik wil graag een goed systeem bouwen, waar ik makkelijk een nieuwe layout over kan zetten en zo kan aanleveren.

De website
Ik stuur alle aanvragen door naar de index van de website. Deze pagina haalt de opgevraagde url uit elkaar en laad de nodige functies en classes en met de gegevens maakt de class cms er met een template een pagina van.
Er zit echter een verschil in een aantal pagina's en classes. De standaard pagina's hebben 1 class 'dinamisch', welke er voor zorgt dat 'nieuws', 'fotos', 'uitslagen' en 'verslagen' getoond worden. De class 'database' handelt alles met de database af. Daarnaast blijven er nog pagina's over die niet door deze 'dinamische' class getoond kunnen worden. Deze include ik op de volgende manier:

PHP:

function __autoload($class) {
    switch ($class){
        case (in_array($class,array("webbeheer","administratie"))); $file = 'admin/'; break;
        case (in_array($class,array("cms","database","settings"))); $file = 'core/'; break;
        default; $file = 'modules/' . $class . '/'; break;
    }
    if(file_exists($file)) require_once $file . $class . '.php';
    else require_once 'modules/pagina/pages.php';
}

Zoals je ziet heb ik gekozen om de verschillende pagina's in verschillende directory's te plaatsen, om een duidelijk overzicht te behouden. Als de module niet bestaat krijg je een foutmelding via de class 'pagina'.

Elke module wordt standaard aangesproken met een $class->index($url). (de url is een array van de gevraagde url). De functie index van de class'en gaat met behulp van de url uitzoeken wat er precies getoond moet worden en returnd de inhoud van de pagina. De class 'cms' maakt van de template en de inhoud van de pagina één geheel en print deze uit.

Wat wil ik weten?
Ben ik op een goede manier aan het werk? Gebruik ik de classes waarvoor ze bedoelt zijn, of sla ik de plank helemaal mis?

Waarom gebruik ik geen bestaande frameworks?
Omdat ik graag het wiel zelf uitvind en daar de tijd voor heb en denk dat ik hier het meeste van leer. Daarnaast is het administratie gedeelte complex met rechten en heb ik zo niet het idee dat ik dat in een bestaande framework kan bouwen. Daarnaast heb ik me daar ook niet in verdiept, ik zie door de bomen dan ook het bos niet in wat nou een goede keuze is en hoe ik er direct mee aan de slag kan.

[muksie]

Ik denk dat het, vooral wanneer je nog maar weinig programmeerervaring hebt, wel verstandig is om een framework te gebruiken voornamelijk omdat object-georiënteerd nog nieuw is voor je. Maar dat is uiteindelijk je eigen keuze.

Wat betreft je class loading: Wat gebeurt er wanneer je zowel in je admin-deel als in je core-deel een klasse met de zelfde naam wilt hebben (bijv. settings)? Ik zou hier zelf gebruik maken van de pseudo-namespacing zoals onder andere het Zend Framework dat doet, met klasses als Core_Settings welke dan in het bestand Core/Settings.php staat. Op deze manier kun je direct vanuit de classname afleiden welk bestand je daarvoor moet hebben, en hoef je niet voor iedere klasse die je toevoegt weer de autoloader aan te passen.

Verder zijn je modules blijkbaar klasses met minstens een index methode. Je zou (misschien dat je dat ook al gedaan hebt) hier een interface of abstracte klasse voor kunnen maken, die vervolgens alle modules moeten implementeren.

Verder krijg ik een beetje het gevoel dat je een deel van de klasses (bijv. dinamisch, ik neem aan dat je dynamisch bedoelt?) handmatig included en de rest met autoload. Als dit zo is, lijkt me dit erg verwarrend, hooguit vanuit je index.php een pagina includen welke je autoload definieert / registreert, maar laat dan verder ook alles door je autoload doen.

Wat gebeurt er precies wanneer een pagina niet gevonden kan worden (wat doet modules/pagina/pages.php precies)? De autoloader moet in principe zorgen dat de opgevraagde klasse geladen wordt. Bestaat deze klasse niet, dan kun waarschijnlijk beter een exceptie gooien (tenzij pages.php dat al doet, maar dan nog vind ik het niet zo'n nette constructie).

Ook je database klasse moet je een beetje mee opletten. Ik weet niet precies wat deze klasse doet, maar ik vermoed dat het een laagje om je database connectie heen is, welke de verbinding legt en een methode heeft om een query uit te voeren. Ik weet niet welk databasesysteem je gebruikt maar het is aan te raden om iets van prepared statements te gebruiken, en let heel goed op het escapen van input, om sql injection te voorkomen.

[ Voor 0% gewijzigd door muksie op 20-07-2009 20:19 . Reden: Typo fixed ]

[MueR]

PHP:

if(file_exists($file))

Dit gaat niet werken. In ieder geval niet waar jij het voor wil laten werken. Je wil controleren of het te includen bestand bestaat, niet de map waar het toevallig in zou moeten staan.

Verder vraag ik me af waarom je kiest voor een autoload constructie, terwijl het gros van de classes (database, settings, cms) toch altijd wel geladen worden. Dan kan je ze beter direct opnemen, ipv de autoloader aan te spreken. Een autoloader moet je echt alleen gebruiken (en zelfs dan twijfelachtig) bij classes die je bijna nooit gebruikt en daarom niet interessant zijn om constant door de parser te halen.

[koffie-junk]

muksie schreef op maandag 20 juli 2009 @ 16:16:Wat betreft je class loading: Wat gebeurt er wanneer je zowel in je admin-deel als in je core-deel een klasse met de zelfde naam wilt hebben (bijv. settings)? Ik zou hier zelf gebruik maken van de pseudo-namespacing zoals onder andere het Zend Framework dat doet, met klasses als Core_Settings welke dan in het bestand Core/Settings.py staat. Op deze manier kun je direct vanuit de classname afleiden welk bestand je daarvoor moet hebben, en hoef je niet voor iedere klasse die je toevoegt weer de autoloader aan te passen.

Alle settings staan in het zelfde /core/settings.php bestand, verder gebruik ik in het administratieve gedeelte geen andere instellingen dan op de rest van de website. De instellingen roep ik aan door (voorbeeld):

PHP:

settings::table_rows;

Is dat een goede manier?

muksie schreef op maandag 20 juli 2009 @ 16:16:Verder zijn je modules blijkbaar klasses met minstens een index methode. Je zou (misschien dat je dat ook al gedaan hebt) hier een interface of abstracte klasse voor kunnen maken, die vervolgens alle modules moeten implementeren.

Elke class ziet er als volgt uit:

PHP:

class zoeken
{
    function index($url){
    }
}

Vanuit de index.php krijg je dan:

PHP:

// url = /zoeken/[search_string]
$class = new $url[0];
$inhoud = $class->index($url);

Daar voorafgaand word dus eerst de url ontleed en als array gemaakt. De 'url[0]' word in het database gezocht of deze bestaat.

Je bedoelt dat ik beter een keer de functie index schrijf, welk door elke class word gebruikt? Op deze manier: http://nl.php.net/manual/en/language.oop5.abstract.php

muksie schreef op maandag 20 juli 2009 @ 16:16:Verder krijg ik een beetje het gevoel dat je een deel van de klasses (bijv. dinamisch, ik neem aan dat je dynamisch bedoelt?) handmatig included en de rest met autoload. Als dit zo is, lijkt me dit erg verwarrend, hooguit vanuit je index.php een pagina includen welke je autoload definieert / registreert, maar laat dan verder ook alles door je autoload doen.

Excuses voor mijn typefouten. Ik bedoel dynamisch ja, maar in de code heet het dinamisch. Ik zal het veranderen. Ik had de code iets aangepast. Ook MueR merkte op dat hij niet zou werken. Dat klopt. Zo werkt hij wel en dit is de volledige:

PHP:

function __autoload($class) {
    switch ($class){
        case (in_array($class,array("webbeheer","user","administratie"))); $file = 'admin/'; break;
        case (in_array($class,array("cms","database","text","dinamisch","settings"))); $file = 'core/'; break;
        default; $file = 'modules/' . $class . '/'; break;
    }
    if(file_exists($file.$class.'.php')) require_once $file . $class . '.php';
    else require_once 'modules/pagina/pages.php';
}

Ik include dus niks handmatig.

MueR schreef op maandag 20 juli 2009 @ 16:19:
Verder vraag ik me af waarom je kiest voor een autoload constructie, terwijl het gros van de classes (database, settings, cms) toch altijd wel geladen worden. Dan kan je ze beter direct opnemen, ipv de autoloader aan te spreken. Een autoloader moet je echt alleen gebruiken (en zelfs dan twijfelachtig) bij classes die je bijna nooit gebruikt en daarom niet interessant zijn om constant door de parser te halen.

Hm, daar zeg je wat. Ik zou dan alles uit de 'core' kunnen laden, maar alles uit 'modulen' via de autoload. Hierin zitten namelijk nog best wat dingen die gebruikt worden ('kalender','forum','zoeken','records','leden'). Vandaar ook de autoload functie.

muksie schreef op maandag 20 juli 2009 @ 16:16:Wat gebeurt er precies wanneer een pagina niet gevonden kan worden (wat doet modules/pagina/pages.php precies)? De autoloader moet in principe zorgen dat de opgevraagde klasse geladen wordt. Bestaat deze klasse niet, dan kun waarschijnlijk beter een exceptie gooien (tenzij pages.php dat al doet, maar dan nog vind ik het niet zo'n nette constructie).

Alles wat niet gevonden wordt, word doorgestuurd naar de class pagina. Deze gaat kijken of er niet een pagina bestaat met deze naam in het database. Als die er niet is, krijgt de gebruiker een 404 pagina te zien.

muksie schreef op maandag 20 juli 2009 @ 16:16:Ook je database klasse moet je een beetje mee opletten. Ik weet niet precies wat deze klasse doet, maar ik vermoed dat het een laagje om je database connectie heen is, welke de verbinding legt en een methode heeft om een query uit te voeren. Ik weet niet welk databasesysteem je gebruikt maar het is aan te raden om iets van prepared statements te gebruiken, en let heel goed op het escapen van input, om sql injection te voorkomen.

Ik gebruik mysql, als je dat bedoelde?
De class database doet verder niet zoveel. Ik gebruik hem met de functie

PHP:

database::query('SELECT * FROM nieuws enzovoorts ');

Daarnaast heb ik een functie geschreven voor mezelf, die het invoeren van data wat makkelijker maakt (ik hou niet zo van de INSERT INTO en de UPDATE.

PHP:

$update = array(
    "table" =>  "new_media",
    "waarden"   =>  
    array   (   "media_id"  =>  $media_type["id"],
        "titel"     =>  trim(htmlspecialchars ($_REQUEST["titel"])),
        "idA"       =>  ($new_id["id"] + 1),
        "auteur"    =>  $_SESSION["user"]["name"],
        "timeA"     =>  mktime(),
        "plaats"    =>  htmlspecialchars ($_REQUEST["plaats"]),
        "vereniging"=>  htmlspecialchars ($_REQUEST["vereniging"]),
        "feedback"  =>  $reacties,
        "html"      =>  $html,
        "update"    =>  time(),
        "inhoud"    =>  trim(addslashes($_REQUEST["inhoud"])),
),
);
$id = database::insert($update);

Of is dit niet zo'n handige functie?

[--MeAngry--]

Theoretisch kan het wel met die manier van werken, maar dan ga je wel vlug tegen beperkingen aan lopen. Als je het echt perse zelf wilt doen, zou ik op z'n minst wel even kijken hoe andere frameworks zulke problemen oplossen.
Probeer bijvoorbeeld eens met een simpel ORM te werken, waardoor dat je een heleboel queries maar 1 keer hoeft te definiëren, en je vervolgens alleen maar met de objecten hoeft te spelen. Dan ben je mi goed bezig met OO.

Zoek ook eens op MVC trouwens, ik denk dat er een wereld voor je open gaat, zeker omdat je de layout wilt gaan scheiden van de werking.

Overigens zul je dit nu toch niet in een keer goed doen. Het is je eerste keer dat je serieus met OO aan de slag gaat, en je zult gaandeweg echt momenten tegen komen waarop je zoiets hebt van, 'waarom heb ik DAT nu weer gedaan???'. Maar dat hoort er allemaal bij.
Ik heb in ieder geval wel mensen gezien die een veel slechter begin hadden, maar probeer jezelf in ieder geval nog wat in te lezen in diverse patterns. Bijvoorbeeld hier.

[ Voor 42% gewijzigd door --MeAngry-- op 20-07-2009 17:23 ]

[Priet]

MueR schreef op maandag 20 juli 2009 @ 16:19:
Verder vraag ik me af waarom je kiest voor een autoload constructie, terwijl het gros van de classes (database, settings, cms) toch altijd wel geladen worden. Dan kan je ze beter direct opnemen, ipv de autoloader aan te spreken. Een autoloader moet je echt alleen gebruiken (en zelfs dan twijfelachtig) bij classes die je bijna nooit gebruikt en daarom niet interessant zijn om constant door de parser te halen.

Que Waar haal je deze wijsheid vandaan? Je voegt een kleine overhead toe, maar wel een hoop gemak (ook in onderhoud) voor de programmeur. Ik verwacht niet dat die overhead een dermate negatieve impact op de performance heeft dat je het moet mijden.

[muksie]

De instellingen roep ik aan door (voorbeeld):

PHP:

settings::table_rows;

Is dat een goede manier?

Voor de instellingen is dat een redelijk goede manier, al zou je kunnen overwegen om de instellingen niet static te maken, maar dat je bijvoorbeeld gewoon zoiets hebt:

PHP:

class Settings {
    public $table_rows;

    public function __construct() {
        $this->table_rows = ...
    }
}

$settings = new Settings();
$settings->table_rows;

Het voordeel hiervan is dat, mocht je bijvoorbeeld in de toekomst de instellingen vanuit een bestand in willen lezen, je eenvoudig een nieuwe klasse kunt maken, bijv. zoiets:

PHP:

class FileSettings extends Settings {
    public function __construct() {
        $file = fopen(...);
        $this->table_rows = $this->readSetting($file, 'table_rows');
        ....
        fclose($file);
    }

    protected function readSetting($file, $setting) {
         .....
         return $result;
    }
}

De rest van de code hoef je dan niet meer aan te passen, overal waar een Settings object verwacht wordt door je code, kan je ook een FileSettings object geven (technisch gezien is je FileSettings object nog steeds óók een Settings object).

Elke class ziet er als volgt uit:

PHP:

class zoeken
{
    function index($url){
    }
}

Je bedoelt dat ik beter een keer de functie index schrijf, welk door elke class word gebruikt? Op deze manier: http://nl.php.net/manual/en/language.oop5.abstract.php

Inderdaad. Het zou dan zoiets worden:

PHP:

interface Module {
    public function index($url);
}

class Zoeken implements Module {
    public function index($url) {
        ....
    }
}

of

PHP:

abstract class Module {
    public abstract function index($url);
}

class Zoeken extends Module {
    public function index($url) {
        ....
    }
}

Het voordeel van deze manier is, dat je hiermee op taalniveau afdwingt dat iedere module een index methode heeft. Van een interface of een abstracte klasse kun je geen objecten aanmaken, het is dus niet mogelijk om

PHP:

$class = new Module();

te doen, echter weet je wel zeker dat alle vereiste methodes geprogrammeerd zijn.

Ik gebruik mysql, als je dat bedoelde?
De class database doet verder niet zoveel. Ik gebruik hem met de functie

PHP:

database::query('SELECT * FROM nieuws enzovoorts ');

Daarnaast heb ik een functie geschreven voor mezelf, die het invoeren van data wat makkelijker maakt (ik hou niet zo van de INSERT INTO en de UPDATE.

Ook hier is query weer een statische methode, wat prima mogelijk is, maar waarschijnlijk de kracht van OO een beetje teniet doet. Waarschijnlijk heb je nog niet helemaal het verschil tussen klasses en objecten door, de manier waarop je het nu doet verschilt waarschijnlijk weinig van de manier waarop je het helemaal zonder klasses zou doen.

Priet schreef op maandag 20 juli 2009 @ 18:35:
[...]

Que Waar haal je deze wijsheid vandaan? Je voegt een kleine overhead toe, maar wel een hoop gemak (ook in onderhoud) voor de programmeur. Ik verwacht niet dat die overhead een dermate negatieve impact op de performance heeft dat je het moet mijden.

Inderdaad, laat iig tijdens ontwikkeling gewoon de autoload het werk doen, als je er later achter komt dat je webserver het niet meer af kan, en de autoload blijkt de oorzaak te zijn (wat me niet echt waarschijnlijk lijkt) kun je altijd nog wat include's toevoegen.

[tvdweij]

Waarom gebruik ik geen bestaande frameworks?
Omdat ik graag het wiel zelf uitvind en daar de tijd voor heb en denk dat ik hier het meeste van leer. Daarnaast is het administratie gedeelte complex met rechten en heb ik zo niet het idee dat ik dat in een bestaande framework kan bouwen. Daarnaast heb ik me daar ook niet in verdiept, ik zie door de bomen dan ook het bos niet in wat nou een goede keuze is en hoe ik er direct mee aan de slag kan.

Ik zou toch eens naar een aantal (h)mvc frameworks kijken, al is het alleen maar om te leren. Een (goed) framework zal je niet snel beperken in je mogelijkheden, het is een basis die je kunt uitbouwen. Een aantal frameworks hebben trouwens uitstekende mogelijheden m.b.t. authenticatie, authorisatie, acl, rbac etc. die wss niet snel tekort zullen schieten voor jouw cms.

Ik kan me touwens wel voorstellen dat je door de bomen het bos niet meer ziet. Er zijn er eigenlijk teveel maar dit zijn een aantal die mijns inziens zeker de moeite zeker waard zijn:

• http://www.yiiframework.com/ --> Vrij nieuw, met uitgebreide mogelijkheden
• http://www.phpfuse.net/ --> Veelbelovend
• http://kohanaphp.com/ --> lightweight, makkelijk mee te starten en toch krachtig (let op v3 in de nabije toekomst)
• http://www.symfony-project.org/ --> erg veel mogelijkheden, "enterprise" framework

Daarnaast natuurlijk bekende zoals Zend framework en CakePHP maar daar heb ik het persoonlijk niet zo mee.

[hostname]

Even buiten de rest van je vragen om is die autoload functie ook niet perfect. Die hele switch is zo overbodig en kan beter met if/elseif uitgeschreven worden. Daarnaast is werkt zoals gezegd de file_exists niet.

En bij de default: worden de classes uit modules/[classnaam]/[classnaam].php geincluded, lijkt me nogal dubbelop?

[ Voor 1% gewijzigd door hostname op 20-07-2009 22:35 . Reden: even opletten (zie hieronder) :z ]

[doeternietoe]

hostname schreef op maandag 20 juli 2009 @ 20:54:
Die hele switch is zo overbodig en kan gewoon met if/elseif uitgeschreven worden.

Dat kan elke switch, niet?

Maar je hebt gelijk dat die switch een vreemde constructie gebruikt. In de switch() staat een string, terwijl elk van de cases een boolean returned. Nu wordt een gevulde string automatisch naar true geëvalueerd, en werkt het in de praktijk dus wel, maar dat maakt het nog geen geldige code.

Gezien het gebruik van ';' ipv ':' in de switch, lijkt deze code overigens niet direct uit de applicatie geknipt en geplakt...

[ Voor 15% gewijzigd door doeternietoe op 20-07-2009 21:42 ]

[koffie-junk]

Allereerst, bedankt voor de reacties en het meedenken

--MeAngry-- schreef op maandag 20 juli 2009 @ 17:19:
Theoretisch kan het wel met die manier van werken, maar dan ga je wel vlug tegen beperkingen aan lopen. Als je het echt perse zelf wilt doen, zou ik op z'n minst wel even kijken hoe andere frameworks zulke problemen oplossen.
Probeer bijvoorbeeld eens met een simpel ORM te werken, waardoor dat je een heleboel queries maar 1 keer hoeft te definiëren, en je vervolgens alleen maar met de objecten hoeft te spelen. Dan ben je mi goed bezig met OO.

Hm, je hebt me zeker geprikkeld en begrijp wat je bedoelt (in theorie), maar hoe ik het in praktijk toe moet passen? (met betrekking op de querys)
Heb je hier zo makkelijk meer informatie van? Google vind op jou trefwoorden voornamelijk Engelse pagina's. Nou kan ik ze zeker lezen, alleen duurt het net even iets langer om het te begrijpen.

--MeAngry-- schreef op maandag 20 juli 2009 @ 17:19:Zoek ook eens op MVC trouwens, ik denk dat er een wereld voor je open gaat, zeker omdat je de layout wilt gaan scheiden van de werking.

Dat doe ik (volgens mij) ook al een klein beetje. Het kan zeker beter, maar ik maak gebruik van een .tp bestand waar de html staat. Waar ik zelf wel naar toe zou willen is:

code:

<html>
<head>
<title><?php echo $title;?></title>
</head>
<body>
<h1><?php echo $heading;?></h1>
    
<h3>My Todo List</h3>   

<ul>
<?php foreach($todo_list as $item):?>

<li><?php echo $item;?></li>

<?php endforeach;?>
</ul>
    
</body>
</html>

--MeAngry-- schreef op maandag 20 juli 2009 @ 17:19:
Overigens zul je dit nu toch niet in een keer goed doen. Het is je eerste keer dat je serieus met OO aan de slag gaat, en je zult gaandeweg echt momenten tegen komen waarop je zoiets hebt van, 'waarom heb ik DAT nu weer gedaan???'. Maar dat hoort er allemaal bij.
Ik heb in ieder geval wel mensen gezien die een veel slechter begin hadden, maar probeer jezelf in ieder geval nog wat in te lezen in diverse patterns. Bijvoorbeeld hier.

Dank je wel (voor 't compliment) en voor de link, ik ga er mee aan de slag

---

muksie schreef op maandag 20 juli 2009 @ 20:46:
[...]

Voor de instellingen is dat een redelijk goede manier, al zou je kunnen overwegen om de instellingen niet static te maken, maar dat je bijvoorbeeld gewoon zoiets hebt:

PHP:

class Settings {
    public $table_rows;

    public function __construct() {
        $this->table_rows = ...
    }
}

$settings = new Settings();
$settings->table_rows;

Het voordeel hiervan is dat, mocht je bijvoorbeeld in de toekomst de instellingen vanuit een bestand in willen lezen, je eenvoudig een nieuwe klasse kunt maken, bijv. zoiets:

PHP:

class FileSettings extends Settings {
    public function __construct() {
        $file = fopen(...);
        $this->table_rows = $this->readSetting($file, 'table_rows');
        ....
        fclose($file);
    }

    protected function readSetting($file, $setting) {
         .....
         return $result;
    }
}

De rest van de code hoef je dan niet meer aan te passen, overal waar een Settings object verwacht wordt door je code, kan je ook een FileSettings object geven (technisch gezien is je FileSettings object nog steeds óók een Settings object).

Hm, ik begrijp geloof ik niet helemaal wat je bedoelt (doel van je class).
Of is het beter om het met ini_set() te doen?
De class instellingen ziet er bij mij zo uit:

PHP:

    class settings
    {
        const table_rows = "20";
    }

Het was volgens mij zo het makkelijkst om snel iets te veranderen ofzo. Ik snap niet helemaal waar jou class naartoe gaat?

muksie schreef op maandag 20 juli 2009 @ 20:46:[...]

Inderdaad. Het zou dan zoiets worden:

PHP:

interface Module {
    public function index($url);
}

class Zoeken implements Module {
    public function index($url) {
        ....
    }
}

of

PHP:

abstract class Module {
    public abstract function index($url);
}

class Zoeken extends Module {
    public function index($url) {
        ....
    }
}

Het voordeel van deze manier is, dat je hiermee op taalniveau afdwingt dat iedere module een index methode heeft. Van een interface of een abstracte klasse kun je geen objecten aanmaken, het is dus niet mogelijk om

PHP:

$class = new Module();

te doen, echter weet je wel zeker dat alle vereiste methodes geprogrammeerd zijn.

Ja, ik begrijp je. Wat ik alleen bedenk is hoe ik het terug vertaal naar de class. Dan zou ik elke class dezelfde functies moeten geven die uitgevoerd worden. Ik heb de volgende mogelijkheden om te bezoeken:

code:

/nieuws
/nieuws/1253
/forum/2
/forum/topic/344
/zoeken/er-is-gezocht+nog-wat
/records/indoor/mannen/100-meter

Volgens mij moet dat dan met de volgende functies opgevangen kunnen worden (die ik bij elke class weer anders in kan vullen)?

PHP:

class forum($url) extends module
{
    function overzict(){
        // /forum
    }
    function sub_vieuw(){
        // /forum/12
    }
    function categorie(){
        // /forum/categorie/12
    }
    function topic(){
        // /forum/topic/2357
    }
    function add(){
        // /forum/topic/2357/nieuw || /forum/categorie/12/nieuw
    }
}

Of heb ik het mis?

muksie schreef op maandag 20 juli 2009 @ 20:46:
[...]

Ook hier is query weer een statische methode, wat prima mogelijk is, maar waarschijnlijk de kracht van OO een beetje teniet doet. Waarschijnlijk heb je nog niet helemaal het verschil tussen klasses en objecten door, de manier waarop je het nu doet verschilt waarschijnlijk weinig van de manier waarop je het helemaal zonder klasses zou doen.

Dat geloof ik graag ja. Zou ik dat makkelijk en snel bij kunnen spijkeren?

---

tvdweij schreef op maandag 20 juli 2009 @ 20:53:
[...]

Ik zou toch eens naar een aantal (h)mvc frameworks kijken, al is het alleen maar om te leren. Een (goed) framework zal je niet snel beperken in je mogelijkheden, het is een basis die je kunt uitbouwen. Een aantal frameworks hebben trouwens uitstekende mogelijheden m.b.t. authenticatie, authorisatie, acl, rbac etc. die wss niet snel tekort zullen schieten voor jouw cms.

Ik kan me touwens wel voorstellen dat je door de bomen het bos niet meer ziet. Er zijn er eigenlijk teveel maar dit zijn een aantal die mijns inziens zeker de moeite zeker waard zijn:

• http://www.yiiframework.com/ --> Vrij nieuw, met uitgebreide mogelijkheden
• http://www.phpfuse.net/ --> Veelbelovend
• http://kohanaphp.com/ --> lightweight, makkelijk mee te starten en toch krachtig (let op v3 in de nabije toekomst)
• http://www.symfony-project.org/ --> erg veel mogelijkheden, "enterprise" framework

Daarnaast natuurlijk bekende zoals Zend framework en CakePHP maar daar heb ik het persoonlijk niet zo mee.

Dank je wel! Ik kan je wel vertellen dat ik verschillende frameworks geprobeerd heb, maar er nooit duidelijk uit werd. Toch heb ik nu http://codeigniter.com/ gevonden (zie ook VideoTutorials), waar ik aardig van onder de indruk ben. Ik ben sinds een paar uurtjes aan het spelen ermee en zit er aan te denken om daar mee verder te ontwikkelen. Hoewel ik toch eerst het huidige project van mij op deze manier wil afronden, om te leren.

---

doeternietoe schreef op maandag 20 juli 2009 @ 21:39:
[...]

Dat kan elke switch, niet?

Maar je hebt gelijk dat die switch een vreemde constructie gebruikt. In de switch() staat een string, terwijl elk van de cases een boolean returned. Nu wordt een gevulde string automatisch naar true geëvalueerd, en werkt het in de praktijk dus wel, maar dat maakt het nog geen geldige code.

Gezien het gebruik van ';' ipv ':' in de switch, lijkt deze code overigens niet direct uit de applicatie geknipt en geplakt...

Helemaal zelf uitgevogeld hoe ik zo'n ding werkend kan krijgen ja. Ik heb hem dan ook eerst met ifs gehad en wilde kijken of het makkelijker kan. Ik kom aan die ';' via het laatste voorbeeld van http://us.php.net/manual/en/control-structures.switch.php. Ik was zelf verbaasd dat het werkte. Daarbij was ik opzoek naar de mogelijkheid om hem zo klein mogelijk te maken en had zelf ongeveer in mijn hoofd (zoals ik het eruit wilde laten zien). Waarom? Om er weer van te leren.

PHP:

switch ($class){
    case ('optieA' || 'optieB'): $file = 'blabla.php';
    case ('optieC' || 'optieD'): $file = 'lala.php';
    default: $file = 'baba.php';
}

Bovenstaande heb ik niet uitgeprobeerd (ik kon een switch die er zo uitzag niet vinden, dus zou niet weten of het werkt).
Ik heb hem dan ook gepost voor reactie's, aangezien ik (zoals al twee keer vermeld) geen opleiding hierin gehad heb, maar het wel heel interessant vindt en graag wil weten of het stukje programmeren wat ik doe complete onzin is of nog wel een beetje ergens op lijkt. Als je het eerste vindt, mag je dat ook best (opbouwend) aangeven.

[Cartman!]

In tegenstelling tot tvdweij kan ik Zend Framework juist erg aanraden. De opbouw is erg logisch en je gebruikt alleen wat je wilt hebben (opbouw dmv. componenten) en je bent vrij de structuur te gebruiken die jij prettig vind wat veel andere frameworks niet toestaan. De support is ook erg goed.

[doeternietoe]

Of het mooi is, kan je over van mening verschillen, maar het kan ook zo:

PHP:

switch( true ){
  case conditieA: //conditie evalueerd naar boolean
    #codeA
    break;
  case conditieB: //idem
    #codeB
    break;
  #etc
}

@Sebazzz: Ik gebruik het zelf ook

@TS:
Deze code:

PHP:

<?php
switch ($class){
    case ('optieA' || 'optieB'): $file = 'blabla.php';
    case ('optieC' || 'optieD'): $file = 'lala.php';
    default: $file = 'baba.php';
}
?>

Kan natuurlijk wel zo:

PHP:

switch ($class){
  case 'optieA':
  case 'optieB': 
    $file = 'blabla.php';
    break;
  case 'optieC':
  case 'optieD':
    $file = 'lala.php';
    break;
  default: 
    $file = 'baba.php';
}

[ Voor 51% gewijzigd door doeternietoe op 21-07-2009 16:13 ]

[Sebazzz]

doeternietoe schreef op dinsdag 21 juli 2009 @ 13:44:
Of het mooi is, kan je over van mening verschillen, maar het kan ook zo:

Ik vind dat soort dingen wel handiger en mooier bijvoorbeeld veel calls naar hetzelfde object, dan bedoel ik dit:

C#:

if (command.StartWith("blaat")) {
    //...
} else if (command.StartWith("blut")) {
    //...
} else if (command.StartWith("zoem")) {
    //...
} else if (command.StartWith("blet")) {
    //...
}

Het zou geweldig zijn als je dat op die manier kon oplossen, dit gaat echter in C# en C++ niet.