Template Class
Door Arian Stolwijk, 20 jaar geleden, 6.409x bekeken
Deze class maakt gebruik van de PHP parser, dus lekker snel en je hoeft geen 'extra taaltje' te leren net als bij smarty.
Ook is er de mogelijkheid om strings wat aan te passen met de modifier class en zijn methods: door simpel de modifier class aan een string te binden met $this->modifier('string'); in je template file.
De modifier methods zijn ook chainable, zodat je $this->modifier('string')->truncate()->entities(); kunt doen. De methods returnen dus hun eigen instantie...
Je kunt ook instellen of je de extract() functie in de fetch() method (van Awf_template class) wilt gebruiken (standaard doet hij dat wel) zodat je niet echo $this->var; hoeft te typen, maar ook gelijk echo $var; kunt gebruiken.
Helemaal onderaan staat een voorbeeldje hoe je het kunt gebruiken.
Naast alleen strings, kan je natuurlij ook gewoon arrays, objecten, boolean, gewoon elk soort variabele doorgeven. De modifier method werkt echter alleen op strings/integers (dus niet met arrays/objecten).
Gesponsorde koppelingen
PHP script bestanden
Er zijn 20 reacties op 'Template class'
0 
-0 
-0
Je gebruikt een __set en een assign, gebruik gewoon __set, is het altijd goed.
assign veranderen naar assign met arrays is nog leuker natuurlijk.
Dit zou je mooi kunnen ombouwen naar een view class.
assign veranderen naar assign met arrays is nog leuker natuurlijk.
Dit zou je mooi kunnen ombouwen naar een view class.
0 -0
-0
Dit staat toch als ergens in de script lib.. Tenminste, dat is wat ik dacht.. Zoiets iig.
Maar verder is het toch leuk.
Het idee achter een template gedoetje is dus dat de designer niets met PHP te maken heeft en dus geen PHP hoeft te kennen, dat idee haal jij nu weer weg ;)
Maar verder is het toch leuk.
Het idee achter een template gedoetje is dus dat de designer niets met PHP te maken heeft en dus geen PHP hoeft te kennen, dat idee haal jij nu weer weg ;)
0 -0
-0
@tommy:Maar het komt ook vaak genoeg voor dat jij alleen een applicatie ontwikkeld, zonder externe designer... dan is dit toch weer makkelijker en sneller ;)
0 -0
-0
@Tommy, wat voor template engine zou jij dan aanraden dat een designer niks extra's hoeft te leren?
0 -0
-0
Idk, maar dat is nou eenmaal het idee achter het template gedoe.
Ik geef je gelijk dat een designer voor een template engine wat moet leren.
Ik geef je gelijk dat een designer voor een template engine wat moet leren.
0 -0
-0
Een ideale template engine is er een waarbij totaal geen "template-engine-code" in de template hoeft voor te komen. En dat is nog relatief makkelijk te bereiken ook!
Je laat de designer een HTML template maken. Vervolgens laad je dit HTML template in je template engine via DOMDocument. Nu kun je dus de DOM van het document gaan manipuleren. Dit manipuleren doe je met je View object via bijvoorbeeld XPath queries (die je door je template engine laat uitvoeren).
Nu heb je dus én geen code in je templates én de mogelijkheid voor de designer om HTML prototypes te maken; er komt toch totaal geen PHP bij kijken. In een later stadium laat je je View object simpel de dummy data van de designer vervangen voor 'echte' content.
Je laat de designer een HTML template maken. Vervolgens laad je dit HTML template in je template engine via DOMDocument. Nu kun je dus de DOM van het document gaan manipuleren. Dit manipuleren doe je met je View object via bijvoorbeeld XPath queries (die je door je template engine laat uitvoeren).
Nu heb je dus én geen code in je templates én de mogelijkheid voor de designer om HTML prototypes te maken; er komt toch totaal geen PHP bij kijken. In een later stadium laat je je View object simpel de dummy data van de designer vervangen voor 'echte' content.
0 -0
-0
@Pim, tja, dat zou ook kunnen, maar dan ben je in je PHP code wel weer iets meer bezig met het uiterlijk... en het is net hoe de designer zijn template aanmaakt, om de juiste XPath queries op te bouwen...
Dus het heeft allemaal denk ik zo zijn haken en ogen...
En in principe is deze methode niet heel ingewikkeld, met if-else en foreach kom je al een heeel eind!
Dus het heeft allemaal denk ik zo zijn haken en ogen...
En in principe is deze methode niet heel ingewikkeld, met if-else en foreach kom je al een heeel eind!
0 -0
-0
@Arian
Je bent in je PHP helemaal niet bezig met het uiterlijk dan hoor. Lay-out technische dingen doe je niet in je PHP in het geval zoals Pim het schetst. Je kan het eigenlijk een beetje vergelijken met "INNERHTML" van Javascript. Je geeft aan in welke div (bijv via het ID of een Class) een bepaalde inhoud moet komen.
Je bent in je PHP helemaal niet bezig met het uiterlijk dan hoor. Lay-out technische dingen doe je niet in je PHP in het geval zoals Pim het schetst. Je kan het eigenlijk een beetje vergelijken met "INNERHTML" van Javascript. Je geeft aan in welke div (bijv via het ID of een Class) een bepaalde inhoud moet komen.
0 -0
-0
@Arian: daar heb je de W3c standaarden voor. Zorg evoor dat je designer volgens die standaard programmeert en er is helemaal geen probleem.
Robert dat is precies wat ik bedoel :) het is goed te vergelijken met de manier waarop je met javascript je layout manipuleert!
PHP gebruik je alleen maar om de content te 'injecteren' in je HTML. PHP heeft absoluut niets met de layout temaken. Dit geeft je gelijk een stuk vrijheid om verschillende type views te genereren met hetzelfde view object. Bijvoorbeeld XML en HTML of JSON via dezelfde view.
Robert dat is precies wat ik bedoel :) het is goed te vergelijken met de manier waarop je met javascript je layout manipuleert!
PHP gebruik je alleen maar om de content te 'injecteren' in je HTML. PHP heeft absoluut niets met de layout temaken. Dit geeft je gelijk een stuk vrijheid om verschillende type views te genereren met hetzelfde view object. Bijvoorbeeld XML en HTML of JSON via dezelfde view.
0 -0
-0
ja oke... maar als je XPath gebruikt, moet je wel iets als
div[@id=container]/element/item
ofzo doen, dus je moet in de meeste gevallen wel die opbouw van je HTML document weten...
Of is er een andere manier :O je zou natuurlijk iets kunnen bouwen dat de designer dat ergens invult... of is er nog een beter manier ?
div[@id=container]/element/item
ofzo doen, dus je moet in de meeste gevallen wel die opbouw van je HTML document weten...
Of is er een andere manier :O je zou natuurlijk iets kunnen bouwen dat de designer dat ergens invult... of is er nog een beter manier ?
0 -0
-0
Het is natuurlijk logisch dat je als php'er de HTML bekijkt... Dat is vrij normaal toch? Verder kan je er natuurlijk voor zorgen dat je XPath queries niet zo specifiek zijn, maar hoofdzakelijk ID's bevatten. Zo kan de designer eventueel ook nog dingen wijzigen in de HTML, zonder dat de template parser niet meer werkt.
0 -0
-0
Ja dat klopt. Maar het wil volgens mij ook vaak genoeg voorkomen dat de programmeur dus simpele html maakt, dat hij alle data die dus moet worden weergegeven dus 'verstuurd' naar de template file, en dat daarna de designer dus zijn layout erin zet. Wat dus hele andere ID's etc. KAN bevatten als het simpel opzetje van de programmeur. Als je het strict opzet, en goed documenteert dat het die id's MOET bevatten, is het natuurlijk een ideale methode om het DOMDocument i.c.m. xPath te gebruiken.
Jouw methode is dus natuurlijk het makkelijkst voor de designer, want die maakt enkel zijn layoutje in html, en de programmeur die past even de XPath queries aan aan de juiste ID's e.d. Ik vind het persoonlijk ook heel slim bedacht hoor;) Ik had er nog niet echt eerder van deze methode gehoord, maar is natuurlijk een prima oplossing.
Maar over het algemeen denk ik dat de 'ouderwetse' manier, net als mijn class, toch het meest dynamische is. Dit omdat je de volle kracht van PHP hebt (als je PHP in je templates gebruikt). (hoewel je natuurlijk niet meer dan if-else, wat simpele loops moet doen, en eventueel wat modifiers net als htmlentities etc.)
En zo ingewikkeld is dat stukje PHP of template code, net als bij smarty, toch ook weer niet;)
Ik denk dat de methode die ik gebruik in deze class, in de meeste gevallen gewoon prima te gebruiken is, vooral als je als programmeur zelfs zelf je design doet, maar toch een beetje de programmatuur en het design uit elkaar wilt houden, en/of volgens het MVC wilt doen.
Ik denk dat je niet zo kunt zeggen dat de een nou beter is dan de ander, ik denk dat je het per situatie moet bekijken wat voor jouw project het beste uit komt. Ik maak (meestal) gewoon alles zelf, dan is dit gewoon heel simpel voor mij en geeft heel veel flexabiliteit wat je soms toch echt nodig hebt met een minimaal aantal regels code (als je kijkt hoeveel regels de Awf_Template class nou eigenlijk is..).
Jouw methode is dus natuurlijk het makkelijkst voor de designer, want die maakt enkel zijn layoutje in html, en de programmeur die past even de XPath queries aan aan de juiste ID's e.d. Ik vind het persoonlijk ook heel slim bedacht hoor;) Ik had er nog niet echt eerder van deze methode gehoord, maar is natuurlijk een prima oplossing.
Maar over het algemeen denk ik dat de 'ouderwetse' manier, net als mijn class, toch het meest dynamische is. Dit omdat je de volle kracht van PHP hebt (als je PHP in je templates gebruikt). (hoewel je natuurlijk niet meer dan if-else, wat simpele loops moet doen, en eventueel wat modifiers net als htmlentities etc.)
En zo ingewikkeld is dat stukje PHP of template code, net als bij smarty, toch ook weer niet;)
Ik denk dat de methode die ik gebruik in deze class, in de meeste gevallen gewoon prima te gebruiken is, vooral als je als programmeur zelfs zelf je design doet, maar toch een beetje de programmatuur en het design uit elkaar wilt houden, en/of volgens het MVC wilt doen.
Ik denk dat je niet zo kunt zeggen dat de een nou beter is dan de ander, ik denk dat je het per situatie moet bekijken wat voor jouw project het beste uit komt. Ik maak (meestal) gewoon alles zelf, dan is dit gewoon heel simpel voor mij en geeft heel veel flexabiliteit wat je soms toch echt nodig hebt met een minimaal aantal regels code (als je kijkt hoeveel regels de Awf_Template class nou eigenlijk is..).
0 -0
-0
Klopt :) Ik heb ook nooit gezegd dat jouw methode niet handig is, maar de discussie was het scheiden van presentatie en logica ten behoeve van de designer. Dat bewerkstellig ik met mijn DOMDocument/XPath methode.
PHP is een template taal, dus als je alles zelf doet zou ik het ook gewoon op jouw manier doen!
PHP is een template taal, dus als je alles zelf doet zou ik het ook gewoon op jouw manier doen!
0 -0
-0
@Tommy,
klopt. Eenzelfde klasse heb ik een paar maanden al eens geplaatst met dezelfde nog uiteenlopendere discussie.
http://phphulp.nl/php/scripts/4/1281/
Een 0.3 staat al een tijdje daar maar ook hier zijn nog wat foutjes die ik er nog uit moet halen. Deze versie bevat wel een caching mechanisme. Alleen is de caching erg agressief, dus wil deze eerst uitgebreidt documenteren.
klopt. Eenzelfde klasse heb ik een paar maanden al eens geplaatst met dezelfde nog uiteenlopendere discussie.
http://phphulp.nl/php/scripts/4/1281/
Een 0.3 staat al een tijdje daar maar ook hier zijn nog wat foutjes die ik er nog uit moet halen. Deze versie bevat wel een caching mechanisme. Alleen is de caching erg agressief, dus wil deze eerst uitgebreidt documenteren.
0 -0
-0
DOM is wel echt heel erg traag en slecht voor je memory, nooit gebruiken als het niet nodig is als je het mij vraagt. Nu kun je natuurlijk wel cachen, maar dan hangt het sterk van de site af of je het goed kan toepassen met redelijke performance.
Ik vind niet dat er één manier is die het best is. Het ligt er gewoon heel erg aan voor wie of wat je werkt en wat de doelstellingen zijn.
Het invullen en query'en van een DOMDocument lijkt mij niet de meest praktische manier, aangezien je dan in je PHP moet gaan bepalen wáár in je HTML bepaalde output moet komen. Als de opbouw (=HTML) dan verandert dan mag je ook je PHP aanpassen, dat vind ik juist niet flexibel.
XSLT is ook nog een hele goede optie als je het mij vraagt. Je PHP output gewoon XML en verder gaat de hele presentatie in XSLT.
Toch staat bij mij een template engine meestal op nummer 1. Bij PHP voornamelijk Smarty, omdat iedereen in de business dit kent en gebruikt en het een prima template engine is. Het lijkt ook heel erg op bijvoorbeeld Velocity (Java). Toch zou een XML-achtige syntax mij zelf beter lijken zoals JSP met codelib(s).
@Pim & anderen
In de praktijk zal een designer vrijwel nooit zelf z'n HTML of CSS schrijven, hier heb je front-end developers voor. En die kunnen ook gewoon Smarty of PHP; als ze maar hun eigen gescheiden plekje hebben qua code; dus presentatie scheiden van de rest. Het is niet een eis dat HTML altijd 100% apart aangepast hoeft te worden, dit is in de praktijk vrijwel nooit nodig.
Ik vind niet dat er één manier is die het best is. Het ligt er gewoon heel erg aan voor wie of wat je werkt en wat de doelstellingen zijn.
Het invullen en query'en van een DOMDocument lijkt mij niet de meest praktische manier, aangezien je dan in je PHP moet gaan bepalen wáár in je HTML bepaalde output moet komen. Als de opbouw (=HTML) dan verandert dan mag je ook je PHP aanpassen, dat vind ik juist niet flexibel.
XSLT is ook nog een hele goede optie als je het mij vraagt. Je PHP output gewoon XML en verder gaat de hele presentatie in XSLT.
Toch staat bij mij een template engine meestal op nummer 1. Bij PHP voornamelijk Smarty, omdat iedereen in de business dit kent en gebruikt en het een prima template engine is. Het lijkt ook heel erg op bijvoorbeeld Velocity (Java). Toch zou een XML-achtige syntax mij zelf beter lijken zoals JSP met codelib(s).
@Pim & anderen
In de praktijk zal een designer vrijwel nooit zelf z'n HTML of CSS schrijven, hier heb je front-end developers voor. En die kunnen ook gewoon Smarty of PHP; als ze maar hun eigen gescheiden plekje hebben qua code; dus presentatie scheiden van de rest. Het is niet een eis dat HTML altijd 100% apart aangepast hoeft te worden, dit is in de praktijk vrijwel nooit nodig.
0 -0
-0
Mee eens, PHPErik, ik schetste alleen een voorbeeld van hoe je het zou kunnen doen als het volledig scheiden van HTML en PHP-code een eis zou zijn. Ik kan bevestigen dat het in de praktijk vrijwel nooit voorkomt en van front-end developers verwacht wordt dat ze kennis hebben van PHP of een vergelijkbare template taal.
Over DOM: je geeft zelf al aan dat dit door te cachen te doen is. Je applicatie structuur moet het inderdaad ondersteunen, maar dat is best te doen met goede performance, denk ik. Daarnaast client-side optimaliseren met bijvoorbeeld 304 Not-Modified headers kan hier veel winst opleveren.
Met je punt dat PHP gaat bepalen wáár in HTML bepaalde output moet komen niet praktisch is ben ik het niet helemaal eens. In veel MVC applicaties is de View niets meer dan een HTML template met wat php code die het een en ander aan de controller vraagt. In het geval van een DOM template parser maak je niet meer gebruik van dit soort templates, maar heb je 'echte' View objecten. Het is de verantwoordelijkheid van het View object waar de output komt. Dit blijft zo.
Ik denk ook dat dit zeer praktisch ingezet kan worden. In principe verandert er namelijk vrij weinig. Je verplaatst de code alleen; waar je 'normaliter' je php code door je HTML heen mixte, staat alle code voor het bepalen van de locatie van de output op één plek verzameld. Makkelijk onderhoudbaar dus. Vergelijk het met het injecteren van HTML content met JavaScript. Een ander voordeel is dat je op deze manier zeer makkelijk meerdere representaties van ouput via hetzelfde view-object kunt laten lopen. Denk aan makkelijk output genereren op basis van de extensie die je meegeeft: .html geeft je de output in een html pagina, .xml geeft je netjes een xml file terug.. etc etc.
Ik ben het met je eens dat er niet één beste manier is. Dit verschilt duidelijk per situatie. Maak je een site zelf waar niet veel eisen zitten aan de view, dan kan het simpel via een normaal php template gedaan worden. Moet je echter ook webservices ondersteunen, dan is het wellicht handig om voor een View object te kiezen in plaats van een php template. De DOM methode daar gelaten; daar zijn vast wel alternatieven voor als je het niet ziet zitten. Je noemt zelf al XSLT, wat ook handig is voor meerdere representaties van content.
Over DOM: je geeft zelf al aan dat dit door te cachen te doen is. Je applicatie structuur moet het inderdaad ondersteunen, maar dat is best te doen met goede performance, denk ik. Daarnaast client-side optimaliseren met bijvoorbeeld 304 Not-Modified headers kan hier veel winst opleveren.
Met je punt dat PHP gaat bepalen wáár in HTML bepaalde output moet komen niet praktisch is ben ik het niet helemaal eens. In veel MVC applicaties is de View niets meer dan een HTML template met wat php code die het een en ander aan de controller vraagt. In het geval van een DOM template parser maak je niet meer gebruik van dit soort templates, maar heb je 'echte' View objecten. Het is de verantwoordelijkheid van het View object waar de output komt. Dit blijft zo.
Ik denk ook dat dit zeer praktisch ingezet kan worden. In principe verandert er namelijk vrij weinig. Je verplaatst de code alleen; waar je 'normaliter' je php code door je HTML heen mixte, staat alle code voor het bepalen van de locatie van de output op één plek verzameld. Makkelijk onderhoudbaar dus. Vergelijk het met het injecteren van HTML content met JavaScript. Een ander voordeel is dat je op deze manier zeer makkelijk meerdere representaties van ouput via hetzelfde view-object kunt laten lopen. Denk aan makkelijk output genereren op basis van de extensie die je meegeeft: .html geeft je de output in een html pagina, .xml geeft je netjes een xml file terug.. etc etc.
Ik ben het met je eens dat er niet één beste manier is. Dit verschilt duidelijk per situatie. Maak je een site zelf waar niet veel eisen zitten aan de view, dan kan het simpel via een normaal php template gedaan worden. Moet je echter ook webservices ondersteunen, dan is het wellicht handig om voor een View object te kiezen in plaats van een php template. De DOM methode daar gelaten; daar zijn vast wel alternatieven voor als je het niet ziet zitten. Je noemt zelf al XSLT, wat ook handig is voor meerdere representaties van content.
0 -0
-0
Quote:
XML en XSLT hebben ook als voordeel dat je niet afhankelijk bent van de programmeertaal, ook .NET, Java, etc. kunnen hier prima mee uit de voeten. Tevens kun je eenvoudiger en sneller de boel opbouwen en testen, je kunt gewoon een XML-file schrijven, valideren met de XSD en presenteren met 1 van de vele XSLT's die je er voor schrijft. Ook kun je met de juiste XSLT de XML even in Excel-formaat drukken of er direct een Word-document van maken.XSLT is ook nog een hele goede optie als je het mij vraagt. Je PHP output gewoon XML en verder gaat de hele presentatie in XSLT.
XML heeft helaas ook wat nadelen, het vreet geheugen en is hierdoor langzamer dat bv. een geoptimaliseerde versie van Smarty. Gelukkig kost geheugen tegenwoordig niet zo veel meer en zijn processors erg snel, toch mag je dit niet uit het oog verliezen. Cache kan een uitkomst zijn.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu