[php] goede indeling template parser?

[Pete]

Ik ben bezig met het maken van een template systeem voor een website die ik onderhoud. Nu heb ik een indeling gemaakt met classen, echter ik weet niet zeker of ik op de goede manier bezig ben.

Welke classen heb ik:

Templatepicker

Haalt een template uit een file en cached deze.

SingleTemplate

De eigenlijke template class. Hiervan heb ik hieronder de sourcecode weergegeven.

Dataobject

Een klasse die in ieder geval 4 methoden heeft, nl. getData, getVariable, getTemplate en getLang

Uitleg: Een template bestaat uit een htmlfile met daarin bbcode achtige blokken. Deze blokken hebben de volgende indeling: [typeblok=blokindentifier] (bijv. [var=datum] of [tem=guestbookitem]). Zodra een template geparsed wordt worden deze blokken uitgelezen en opgevraagd via de goede functie van het DataObject. De verschillende type blokken zijn:

• var (waar een constante geplaatst word zoals datum)
• dat (waar paginadat neergezet word)
• tem (op deze plek kunnen 1 of meerdere templates ingevoegd worden)
• lang (voor taalspecifieke woorden zoals vorige volgende en home)

Nu mijn vragen:

• Is deze opbouw van classen verstandig? Of kan ik het beter anders indelen?
• Is de templateparser op deze manier een beetje snel? Of kan het beter met preg_replace() of ereg_replace()?
• In regel 39 en 41 zet ik de haken in de data om in entities om te voorkomen dat data meevervangen word. Is dit op deze manier handig of kan ik dit beter anders doen?

PHP:

<?
class SingleTemplate {
    var $template;
    var $dataob;
    
    //constructor (for initiating template). Dataobject has to be a class implementing the dataobject functions
    function SingleTemplate($templatepartname, $dataobject) {
        $this->template = $GLOBALS['now']['templpicker']->getTemplate($templatepartname);
        $this->dataob = $dataobject;
        $this->parse();
    }
    
    function parse() {
        preg_match_all("@\\[[a-zA-z]+=[a-zA-Z]+\]@",$this->template,$outputarr);
        $outarr = array();
        print_r($outputarr);
        foreach ($outputarr[0] as $j=>$k) {
            $posis = strpos($k,'=');
            $foris = substr($k,1,$posis-1);
            $afteris = substr($k, $posis+1, strlen($k)-$posis-2);
            switch ($foris)  {
            case "dat":
                $outarr[$j] = $this->dataob->getData($afteris);
                break;
            case "lang":
                $outarr[$j] = $this->dataob->getLang($afteris);
                break;
            case "var":
                $outarr[$j] = $this->dataob->getVariable($afteris);
                break;
            case "tem":
                $outarr[$j] = $this->dataob->getTemplate($afteris);
                break;
            default:
                $outarr[$j] = "";
            }
        }

        $outarr = str_replace("[","[",$outarr);
        $this->template = str_replace($outputarr[0],$outarr,$this->template);
        $this->template = str_replace("[","[",$this->template);

    }
}
?>

[NMe]

phsmit schreef op vrijdag 17 maart 2006 @ 19:34:
• Is deze opbouw van classen verstandig? Of kan ik het beter anders indelen?

Los van het feit dat ik zelf geen templateparser zou schrijven (wat een discussie is die ik hier verder niet wil voeren, aangezien dat al vaak genoeg gebeurd is ) ziet dit ontwerp er wel netjes uit. Ik denk dat ik het ook ongeveer zo zou aanpakken als caching een eis is. De enige opmerking die ik heb is een esthetische: kies liever een andere naam voor je dataobject. De toevoeging "object" is overbodig omdat elke instantie van een klasse een object is, en alleen "data" is nietszeggend. In feite is het dit object dat de daadwerkelijke "vertaling" van code naar output doet, dus wat dat betreft zou ik de klasse eerder TemplateTranslator noemen (TemplateParser kan ook, maar dat is verwarrend omdat je hele project zo al heet ).

• Is de templateparser op deze manier een beetje snel? Of kan het beter met preg_replace() of ereg_replace()?

Ik denk dat je dat beter zelf even kan testen met een simpele testcase. Ik denk dat het snelheidsverschil marginaal zal zijn.

• In regel 39 en 41 zet ik de haken in de data om in entities om te voorkomen dat data meevervangen word. Is dit op deze manier handig of kan ik dit beter anders doen?

Ik denk niet dat je echt alternatieven hebt.

[NoepZor]

Templates kun je toch gewoon in HTML maken die dan een control klasse aanroept, die weer met de functionele klasses communiceert? Dus gewoon een laag maken tussen een HTML template(eventueel met een klein beetje PHP) en de klassen.

[Wim Leers]

NoepZor schreef op vrijdag 17 maart 2006 @ 22:31:
Templates kun je toch gewoon in HTML maken die dan een control klasse aanroept, die weer met de functionele klasses communiceert? Dus gewoon een laag maken tussen een HTML template(eventueel met een klein beetje PHP) en de klassen.

Dit is gewoon een andere aanpak, die dieper gaat.

[MisterData]

Je zou ook je template naar PHP kunnen compileren (uit mijn tests daarmee ooit blijkt dat dat het snelst is) of XSLT kunnen gebruiken (nóg sneller, wel lastiger voor beginners), maar dat lijkt me hier helemaal niet aan de orde. Wat ik zou doen is iets van een Tree-class maken, met daarin een verzameling tokens die in je template voorkomen. Eerst bouw je die tree (of lijst, wat je wil) op aan de hand van de bron van de template en zet je allerlei tokens in die lijst, en 'at runtime' ga je daar doorheen loopen. Dat werkt erg goed als je later ook nog constructies als if/else wil gebruiken Zo heb ik het in een stackbased-template parser van een tijd terug ook gedaan (tegenwoordig ben ik helemaal verliefd op XSLT)

[aex351]

Gewoon php bestanden zelf gebruiken als template bestanden. Dat omzetten van zelf verzonnen tags is echt zonde van je tijd en bovendien dubbel werk.

[NMe]

aex351 schreef op zaterdag 18 maart 2006 @ 00:26:
Gewoon php bestanden zelf gebruiken als template bestanden. Dat omzetten van zelf verzonnen tags is echt zonde van je tijd en bovendien dubbel werk.

-NMe- schreef op vrijdag 17 maart 2006 @ 22:28:
Los van het feit dat ik zelf geen templateparser zou schrijven (wat een discussie is die ik hier verder niet wil voeren, aangezien dat al vaak genoeg gebeurd is )....

[T-MOB]

-NMe- schreef op zaterdag 18 maart 2006 @ 01:31:

Sorry voor de OT, als het echt dwars zit open ik wel een apart topic. Maar het stoort me dat er zo'n "je maakt een template engine dus je bent overbodig bezig"-mentaliteit heerst op GoT. Natuurlijk kun je met een TE nooit meer dan je zou kunnen in de programmeertaal waarin je hem schrijft. Desalniettemin kun je met een TE zorgen dat een fout in het template niet direct leidt tor een dikke parse error op je frontpage. Daarnaast kun je zorgen dat de boel voor een designer die niets van de programmeertaal snapt overzichtelijk blijft, bijvoorbeeld door de template-parser instructies als HTML comments te verpakken. Beide zijn imho argumenten om voor template-parsing te kiezen, zelfs al zou dat uit een sec programmeurstandpunt alleen maar overhead betekenen.

[ Voor 4% gewijzigd door T-MOB op 18-03-2006 03:13 ]

[Sybr_E-N]

T-MOB schreef op zaterdag 18 maart 2006 @ 03:12:
[...]

.

offtopic:
Jij hebt helemaal gelijk, alles wat je nu zegt is inderdaad een goede reden om een goede TE op te zetten. NME probeert alleen deze discussie, waar ik nu ook even aan me doe, die kiem in de smoren omdat er oude uit de sloot worden haalt. Desalnietemin heb je imho wel gewoon gelijk.

[Jurgle]

Sybr_E-N schreef op zaterdag 18 maart 2006 @ 10:16:

offtopic:
Zullen we nu dan toch stiekem in dit 'off-topic' de discussie WEER voeren?

[ Voor 49% gewijzigd door Jurgle op 18-03-2006 14:29 ]

[Pete]

Bedankt voor de reacties!

-NMe- schreef op vrijdag 17 maart 2006 @ 22:28:
De enige opmerking die ik heb is een esthetische: kies liever een andere naam voor je dataobject. De toevoeging "object" is overbodig omdat elke instantie van een klasse een object is, en alleen "data" is nietszeggend. In feite is het dit object dat de daadwerkelijke "vertaling" van code naar output doet, dus wat dat betreft zou ik de klasse eerder TemplateTranslator noemen (TemplateParser kan ook, maar dat is verwarrend omdat je hele project zo al heet ).

Ben ik volledig met je eens. Ik had nl. die class nog niet (echt) geschreven, alleen nog maar een testclass. Het is de bedoeling dat voor ieder type pagina een ander 'dataobject' gebruikt word. Vandaar dat ik die naam tijdelijk gebruik.

T-MOB schreef op zaterdag 18 maart 2006 @ 03:12:
[...]

Sorry voor de OT, als het echt dwars zit open ik wel een apart topic. Maar het stoort me dat er zo'n "je maakt een template engine dus je bent overbodig bezig"-mentaliteit heerst op GoT. Natuurlijk kun je met een TE nooit meer dan je zou kunnen in de programmeertaal waarin je hem schrijft. Desalniettemin kun je met een TE zorgen dat een fout in het template niet direct leidt tor een dikke parse error op je frontpage. Daarnaast kun je zorgen dat de boel voor een designer die niets van de programmeertaal snapt overzichtelijk blijft, bijvoorbeeld door de template-parser instructies als HTML comments te verpakken. Beide zijn imho argumenten om voor template-parsing te kiezen, zelfs al zou dat uit een sec programmeurstandpunt alleen maar overhead betekenen.

Dit zegt gedeeltelijk waarom ik een templateparser maak. Ik heb met de templatebouwer (bijna) geen contact en ik heb er geen behoefte aan dat hij zelf php-scriptjes gaat invoegen in mijn pagina's. De reden dat ik dus een templateparser maak is omdat ik de template en de datafuncties echt strict gescheiden wil houden.
Daarnaast denk ik dat voor de templatebouwer dit systeem makkelijker te begrijpen is (ook door de functionele scheiding van variabelen, data en templates)

[ Voor 8% gewijzigd door Pete op 18-03-2006 17:46 ]

[djluc]

Ik raad je aan om eens naar het principe te kijken van templatevoila van Typo3. ( http://typo3.org ) Hiermee kan je al klikkend je template vullen.

[aex351]

Mocht je toch je webdesigners willen opzadelen met zelf bedachte php (template tags) dan is smarty wel een goede keus.