[php] vraagje voor gebruik templates

[Verwijderd]

Skaah schreef op 06 juni 2004 @ 11:33:...
Ik gebruik zelf ook een template engine, Smarty, waarmee ik de presentational logic van de buisness logic kan scheiden.
...

Nee, dat kun je niet zie het verschil

Skaah schreef op 06 juni 2004 @ 11:33:
Maar... de TS heeft al een template-engine, z'n eigen, een hele simpele. Dat is erg mooi, dat dat voor de TS werkt. Het is dus niet nodig om hem erop te wijzen dat hij naar een andere moet switchen, dat hij zijn hele site moet omgooien.

Toen ik op reply drukte had de TS nog niet aangegeven bekend te zijn met eenvoudige template engines die dit werk al allemaal doen (waar ik Smarty niet onder reken) op de pagina die ik toen bekeek, das punt A. En punt B; ik heb al gezegd dat hij op de site van tbs aan de maker de vraag kan stellen, die heeft het al eens gedaan, en vragen was de ts toch al aan het stellen, waarom dan niet op een plaats waar je 100% zeker een antwoord krijgt

Skaah schreef op 06 juni 2004 @ 11:33:Het valt me gewoon op de laatste tijd dat het lijkt alsof veel van je posts alleen maar zijn om die template engine te promoten. Misschien ben je er gewoon erg vol van, mischien probeer je te promo-en. IMHO horen dat soort posts in een "Welke template engine gebruik jij en waarom"-topics.

Hoezo de laatste tijd, ik ben er pas net. Ik voelde mij niet geroepen me te mengen in de threads omdat ik het merendeel van de mensen hier niet eens zou willen kennen en ik waarschijnlijk daardoor binnen een week er uit gekickt wordt. En ja, iedereen zou een template engine moeten gebruiken en als ik ze dan iets aanbeveel, dan ook iets waar ik achter kan staan, Smarty is te groot en traag en voldoet niet aan zn eigen doelstelling.

offtopic:
(nog verder offtopic dan)
Overigens moet ik wel zeggen dat er hier tegen mijn verwachting in wel een paar mensen zitten die duidelijk wel kunnen programmeren, en dat is dan weer mooi meegenomen, kan ik mn vreemde vragen hier ook kwijt. (Maar als je mn topics in de gaten zou gaan houden kom je daar snel genoeg achter, mijn vragen zijn meestal mbt vreemde problemen of vraagstukken)

[ Voor 24% gewijzigd door Verwijderd op 06-06-2004 12:47 ]

[Evilbee]

Verwijderd schreef op 06 juni 2004 @ 12:37:
En ja, iedereen zou een template engine moeten gebruiken en als ik ze dan iets aanbeveel, dan ook iets waar ik achter kan staan, Smarty is te groot en traag en voldoet niet aan zn eigen doelstelling.

Hoezo is Smarty traag, het is een kleine moeite om de documentatie ff door te lezen en daarna weet je precies hoe je hem goed kan instellen en dan is ie bloedsnel.

[Verwijderd]

Evilbee schreef op 06 juni 2004 @ 12:49:Hoezo is Smarty traag, het is een kleine moeite om de documentatie ff door te lezen en daarna weet je precies hoe je hem goed kan instellen en dan is ie bloedsnel.

Nou goed, dan is ie bloedsnel, ook goed,, maar hij doet nog steeds zn doelstelling niet compleet vervullen (aangenomen dat dit oa conent van code scheiden is)

[Skaah]

Verwijderd schreef op 06 juni 2004 @ 12:37:
[...]
Nee, dat kun je niet zie het verschil
[...]

Buisness logic: in php de data uit de database halen.
Template logic: de data in drie kolommen zetten. Of ik de data nou in een tabel, drie div's of in een XML document wil zetten, daar wil ik mijn php-code niet voor aanpassen. Scheiding van buisness en presentational logic kan dus wel.

[...]Hoezo de laatste tijd, ik ben er pas net.

Zolang valt het me dus ook al op.

Ik voelde mij niet geroepen me te mengen in de threads omdat ik het merendeel van de mensen hier niet eens zou willen kennen en ik waarschijnlijk daardoor binnen een week er uit gekickt wordt. En ja, iedereen zou een template engine moeten gebruiken en als ik ze dan iets aanbeveel, dan ook iets waar ik achter kan staan, Smarty is te groot en traag en voldoet niet aan zn eigen doelstelling.

Een template engine is niet een heel erg nodig als je goed gebruik maakt van XHTML en CSS. Je kunt er dus wel degelijk zonder. Of Smarty te groot, te zwaar of te log is is een andere discussie, waarop ik nu niet wil ingaan. TinyButStrong ondersteunt ook het uit een database halen van gegevens, is dit wel een taak van een template engine? (Denk hier eens over na).

offtopic:
(nog verder offtopic dan)
Overigens moet ik wel zeggen dat er hier tegen mijn verwachting in wel een paar mensen zitten die duidelijk wel kunnen programmeren, en dat is dan weer mooi meegenomen, kan ik mn vreemde vragen hier ook kwijt. (Maar als je mn topics in de gaten zou gaan houden kom je daar snel genoeg achter, mijn vragen zijn meestal mbt vreemde problemen of vraagstukken)

[/quote]Vreemde vragen zijn altijd de leukste

[ Voor 5% gewijzigd door Skaah op 06-06-2004 13:31 ]

[dusty]

-FoX- schreef op 06 juni 2004 @ 12:01:
[...]
Volgens jou is dus een (java-)programmeur ook geen volwaardige programmeur als hij gebruik maakt van reeds bestaande componenten (buttons, swing, ...)
Een programmeur in hart en nieren zou deze natuurlijk allemaal zelf schrijven
Wat een onzin zeg!
[..]

Nee, maar een programmeur in hart en nieren zou het idee erachter weten waarom iemand het zelf zou willen maken, jij blijkbaar niet.

[MTWZZ]

Ik gebruik een zelfgeschreven CMS/template systeempje en daar heb ik ook modules in verwerkt. Die modules zien er in de content-bestanden zo uit:

    <module id="foo" var="bar" />

De modules zijn afzonderlijke include-bestanden in de vorm van <id>.inc
Om de module tags om te zetten naar de uitvoer van de module gebruik ik preg_match_all() om de module tags eruit te vissen en dan het bestand te includen. Zodra het bestand is geinclude() gebruik ik ouput-buffering om de uitvoer van de module te vangen. Als laatste stap vervang ik de tekst waarop gematched is door de uitvoer, en klaar is kees/piet/karel/whoever.

Ik heb hier -> http://barad-dur.homelinux.net/nx/projecten/template/ een bestandje waar te zien is hoe ik het grote probleem heb opgelost.

offtopic:
Btw wat een gezeur of je wel of niet een templating engine (en zo ja welke) moet gebruiken. Je bepaalt toch zelf zeker wel wat je doet?
Owja het is toch de bedoeling van dit forum om mensen te helpen en geen zooi op te dringen??

[ Voor 18% gewijzigd door MTWZZ op 07-06-2004 11:06 ]

[Verwijderd]

MTWZZ schreef op 07 juni 2004 @ 11:00:

offtopic:
Btw wat een gezeur of je wel of niet een templating engine (en zo ja welke) moet gebruiken. Je bepaalt toch zelf zeker wel wat je doet?
Owja het is toch de bedoeling van dit forum om mensen te helpen en geen zooi op te dringen??

A. Waarom kom jij over jouw geweldige systeem zeuren als je dat vindt
B. Grappige is is dat mensen niet weten wat ze willen, dat is uit een aantal studies naar voren gekomen op meerdere gebieden zo te zijn. Dus misschien wil hij wel template engine x gebruiken...

[MTWZZ]

Verwijderd schreef op 07 juni 2004 @ 11:10:
[...]
A. Waarom kom jij over jouw geweldige systeem zeuren als je dat vindt

Nou zeuren valt ook wel mee. Overgens kun je zien dat het hier om een _manier_ gaat (waarom zou ik die link nou hebben neergezet??). Het zal me jeuken of Your1 dit gaat gebruiken of niet.

Verwijderd schreef op 07 juni 2004 @ 11:10:
[...]
B. Grappige is is dat mensen niet weten wat ze willen, dat is uit een aantal studies naar voren gekomen op meerdere gebieden zo te zijn. Dus misschien wil hij wel template engine x gebruiken...

Dat mensen niet weten wat ze willen heeft niets te maken met deze thread. Your1 heeft toch duidelijk gezegd dat ie zelf iets had waar hij iets extra's mee wilde.

[Y0ur1]

Sommige mensen zijn echt ongelofelijk, ik vraag simpel hoe een ding in php werkt en er begint er een over een studie dat mensen niet weten wat ze willen? Ik moet echt hard lachen om dat soort mensen!!

[Brakkie]

Verwijderd schreef op 06 juni 2004 @ 13:03:
[...]
Nou goed, dan is ie bloedsnel, ook goed,, maar hij doet nog steeds zn doelstelling niet compleet vervullen (aangenomen dat dit oa conent van code scheiden is)

Waarom zou dat je doelstelling zijn. Vaak gaat het er gewoon om dat je presentatie logica gescheiden is van de rest van je code. D'r is in mijn ogen niks mis met wat logica in je templates, zolang het maar redelijk simpel is. (zodat een designer/html'er d'r ook nog wat van snapt.)

En over smarty, die is gewoon bloedsnel. (compilen van de templates, eventueel caching functies).

[Verwijderd]

Y0ur1 schreef op 07 juni 2004 @ 12:43:
Sommige mensen zijn echt ongelofelijk, ik vraag simpel hoe een ding in php werkt en er begint er een over een studie dat mensen niet weten wat ze willen? Ik moet echt hard lachen om dat soort mensen!!

Hey, ik kan het niet helpen dat jij op het moment van reply drukken nog niet gezegd had iets anders te willen, bovendien was dat goed advies, waarmee je aan je oplossing had kunnen komen.

Dat dan andere mensen gaan lopen zeiken hierover is niet mijn fout.
Dus lach liever om Arie & Silvester.

Kan iemand dit ding op slot zetten??

[ Voor 7% gewijzigd door Verwijderd op 07-06-2004 13:31 ]

[Pathogen]

Ik ben een van degenen die die vraag wel degelijk eerder heeft gesteld... Helaas werd ik ook overspoeld met Smarty, TBS en Yapter, ondanks dat ik duidelijk aangaf dat het niet mogelijk was voor mij om deze te gebruiken (schoolopdracht).
Uiteindelijk werk ik nu met eenvoudige str_replace opdrachten.
Hiermee kun je idd een variabele, plain text of de output va een functie als replacement gebruiken.

Om een include te gebruiken (afhankelijk van wat het is) zul je dan in het te includen bestand variabelen kunnen declareren en die overnemen in je main code.

Het includen van de template zelf gaat bij mij via fopen() en fread().

Hopelijk heb ik iets duidelijk kunnen maken.

[Y0ur1]

Verwijderd schreef op 07 juni 2004 @ 13:30:
[...]
Hey, ik kan het niet helpen dat jij op het moment van reply drukken nog niet gezegd had iets anders te willen, bovendien was dat goed advies, waarmee je aan je oplossing had kunnen komen.

Dat dan andere mensen gaan lopen zeiken hierover is niet mijn fout.
Dus lach liever om Arie & Silvester.

Kan iemand dit ding op slot zetten??

Het was al 3 keer gezegd dat ik een standaard template kon gebruiken en ik geef toch duidelijk aan dat ik dat niet wil? Dan kun je natuurlijk doorgaan met je goedbedoelde adviezen maar daar heb ik dan niks aan.

[Shadowman]

Verwijderd schreef op 07 juni 2004 @ 13:30:
[...]
Hey, ik kan het niet helpen dat jij op het moment van reply drukken nog niet gezegd had iets anders te willen, bovendien was dat goed advies, waarmee je aan je oplossing had kunnen komen.

Dat dan andere mensen gaan lopen zeiken hierover is niet mijn fout.
Dus lach liever om Arie & Silvester.

In de eerste reply stond al duidelijk aangegeven dat hij een eigen template engine gebruikte . (mja met str_replace niet direct het beste). Zijn vraag was alleen over iets anders dan over een template-engine (stukje code dat hij daarin dan wel kan verwerken, maar dat is niet per definitie direct een vraag over template-engines).

dusty schreef op 06 juni 2004 @ 01:48:
[...]

Welke methode heb je gebruikt om het op te lossen, ( aangezien verschillende mensen oplossingen hebben gegeven, die allen werkbaar zijn)

Hij heeft uiteindelijk de manier gebruikt die ik als eerste had gegeven. (strings concatenaten en dan die returnen ). (Stond eerder nog een stukje code met z'n oplossing, maar die heeft hij (TS) weggeedit).

[gorgi_19]

Verwijderd schreef op 07 juni 2004 @ 13:30:
Kan iemand dit ding op slot zetten??

Ja dat kan, en nee dat gaat vooralsnog niet gebeuren. Hoewel de toon wat minder flamerig kan van sommigen, wordt er door andere nog best inhoudelijk gediscussieerd.

Ontopic weer.

[Verwijderd]

Y0ur1 schreef op 07 juni 2004 @ 13:34:
[...]
Het was al 3 keer gezegd dat ik een standaard template kon gebruiken en ik geef toch duidelijk aan dat ik dat niet wil? Dan kun je natuurlijk doorgaan met je goedbedoelde adviezen maar daar heb ik dan niks aan.

Zeg luister eens, ik heb alleen maar gezegd dat toen er Smarty werdaangeraden dat je ook TBS kon bekijken omdat dit datgene doet waar je om vroeg, en aangezien alles in 1 bestand zit je het er makkelijk uit kunt wippen hoe het moet. Dus ik gaf gewoon een netjes antwoord op je vraag waarbij ik je het alsnog zelf zou laten uitzoeken want daar leer je soms meer van.

Als jij dat al niet kunt waarderen vindt ik het prima, maar ga mij niet zeggen dat ik je tbs opdrong, want dat deed ik dus helemaal niet. Geen enkele zin van mij in deze thread suggereerd dat.

[Shadowman]

Verwijderd schreef op 07 juni 2004 @ 15:09:
[...]
Zeg luister eens, ik heb alleen maar gezegd dat toen er Smarty werdaangeraden dat je ook TBS kon bekijken omdat dit datgene doet waar je om vroeg, en aangezien alles in 1 bestand zit je het er makkelijk uit kunt wippen hoe het moet. Dus ik gaf gewoon een netjes antwoord op je vraag waarbij ik je het alsnog zelf zou laten uitzoeken want daar leer je soms meer van.

Ik zie nog even niet wat je bedoelt met 1 bestand. Als je bedoelt dat die hele template-engine in 1 bestand zit dan zou ik er niet graag in willen zoeken naar de goede regel en je weet sowieso niet of de verschillen tussen jouw template-engine en de template-engine van de TS niet te groot zijn (waarmee zoeken naar vinden van de juiste code onmogelijk wordt).

Als jij dat al niet kunt waarderen vindt ik het prima, maar ga mij niet zeggen dat ik je tbs opdrong, want dat deed ik dus helemaal niet. Geen enkele zin van mij in deze thread suggereerd dat.

De combinatie van zinnen
Je hoeft het niet per definitie op te dringen. Het kan er alleen ontzettend veel op lijken. (NOFI btw)

[Verwijderd]

Eerlijk gezegd vind ik PHP zelf template engine genoeg van zichzelf. Combinaties scripten / includes / echo in samen werking met HTML zijn eindeloos. Zelf geef ik nog steeds de voorkeur aan het schrijven van templates in PHP...

[Bosmonster]

100% agree met TimD...

PHP IS een template engine.. hoe nutteloos kun je bezig zijn daar weer een template systeem in te gaan zitten bouwen

De enige reden (is al eens in een ander topic genoemd) om een template engine in PHP te gebruiken is als je beheerbare templates wilt hebben voor gebruikers en hun mogelijkheden wilt beperken.

[ Voor 41% gewijzigd door Bosmonster op 07-06-2004 15:54 ]

[drm]

TimD:
Eerlijk gezegd vind ik PHP zelf template engine genoeg van zichzelf. Combinaties scripten / includes / echo in samen werking met HTML zijn eindeloos. Zelf geef ik nog steeds de voorkeur aan het schrijven van templates in PHP...

Mijn idee.

Ik begrijp ook niet zo goed waarom je jezelf zou beperken met een of ander templatesysteem terwijl php er uitermate voor geschikt is. Zelf gebruik ik tegenwoordig in templates gewoon de Alternate syntax for control structures. Er is dan volgens mij geen enkel argument om een ander templatesysteem te kiezen, behalve dat je jezelf (enorm) beperkt in functionaliteit.

Daarmee wil ik overigens niet zeggen dat het zinloos is om naar andere templatesystemen te kijken

edit:
Euh, ja wat Bosmonster zegt dus

[ Voor 3% gewijzigd door drm op 07-06-2004 16:02 ]

[Verwijderd]

Bosmonster schreef op 07 juni 2004 @ 15:53:
...
De enige reden (is al eens in een ander topic genoemd) om een template engine in PHP te gebruiken is als je beheerbare templates wilt hebben voor gebruikers en hun mogelijkheden wilt beperken.

mwa, het gaat hem om de beheerbaarheid, en ik voeg met een template engine juist mogelijkheden toe aangezien veel gebruikers juist html wel kennen, maar van php de ballen verstand hebben. Zij kunnen door gebruik van de template engine wel layout wijzigingen maken. Dit komt dubbel zo sterk naar voren als je dit professioneel toe past en grafisch ontwerpers aan je templates laat komen. Die wil je niet in je php hebben rotzooien....

Shadowman schreef op 07 juni 2004 @ 15:26:
Ik zie nog even niet wat je bedoelt met 1 bestand. Als je bedoelt dat die hele template-engine in 1 bestand zit dan zou ik er niet graag in willen zoeken naar de goede regel en je weet sowieso niet of de verschillen tussen jouw template-engine en de template-engine van de TS niet te groot zijn (waarmee zoeken naar vinden van de juiste code onmogelijk wordt).
...

Zo groot is tbs niet. en het ging in de vraag om hoe hij functies aan kon roepen, dat lijkt me standaard genoeg om het zo van iemands anders code over te kunnen nemen.

Shadowman schreef op 07 juni 2004 @ 15:26:
De combinatie van zinnen
Je hoeft het niet per definitie op te dringen. Het kan er alleen ontzettend veel op lijken. (NOFI btw)

Ja, ik heb het alleen niet gezegd, en het lijkt er ook niet op, dus waarom vermeld je dit?

drm schreef op 07 juni 2004 @ 16:02:
[...]
Mijn idee.

Ik begrijp ook niet zo goed waarom je jezelf zou beperken met een of ander templatesysteem terwijl php er uitermate voor geschikt is. Zelf gebruik ik tegenwoordig in templates gewoon de Alternate syntax for control structures. Er is dan volgens mij geen enkel argument om een ander templatesysteem te kiezen, behalve dat je jezelf (enorm) beperkt in functionaliteit.

Daarmee wil ik overigens niet zeggen dat het zinloos is om naar andere templatesystemen te kijken

edit:
Euh, ja wat Bosmonster zegt dus

Dat is een interressante manier, echter; je stopt dan weer php en html code bij mekaar waardoor het gevaarlijk wordt andere mensen je templates aan te laten passen. Tenminste, dat lijkt mij dan. Je zou dit wel kunnen gebruiken, maar erg efficient werkt het niet. je moet de hele tijd je html ingraven tussen php stukjes terwijl dat met tbs in ieder geval niet hoeft, van smarty weet ik dit niet meer, ik ben een hele tijd terug gestopt met het gebruik hier van...

[drm]

RwDwR:
Dat is een interressante manier, echter; je stopt dan weer php en html code bij mekaar waardoor het gevaarlijk wordt andere mensen je templates aan te laten passen.

Ik zie niet in waarom dat met een ander systeem minder gevaarlijk is? Het enige is dat ontwerpers en html-klopperts allemaal bang zijn voor PHP, en dat het met {somevar} in plaats van <?= $somevar ?> opeens helemaal niet meer eng is. 't Slaat nergens op, want 't doet niks anders. Dat lijkt mij vooral een kwestie van je code goed commentaar geven en iedereen gewoon even goed instrueren van te voren.

Verder heb ik wel eens templates gezien waar de honden ook geen brood van lusten. Dat was praktisch een nieuwe php, met een klein beetje minder functionaliteit, en dan wordt er verwacht dat daarmee meer de template-logic van de business-logic gescheiden wordt, om het zo maar even te noemen. Belachelijk, want dat bereik je niet door een templatesysteem te gebruiken, dat bereik je door templates te schrijven. Of je dat dan in PHP doet of in wat voor ander taaltje dan ook maakt helemaal niet uit voor het scheiden van die twee lagen. Dat is dan volgens mij ook een non-argument en alleen maar een gevoelsmatig iets. "Ik gebruik nu een templatesysteem dus ik heb mijn code goed van m'n layout gescheiden". Onzin.

't Enige wat je ontwerpers etc bij moet brengen is dat ze met hun jatten van de stukjes tussen de <? en ?> af moeten blijven, maar dat geldt voor elke templatesysteem (stukjes tussen { en }, of [ en ] of ... ga zo maar door). Willen ze meer aan kunnen passen? Laat ze de php manual maar lezen, en zorg dat je eigen templates goed gedocumenteerd zijn (welke variaben zijn beschikbaar,bijvoorbeeld) En gebruik een versiebeheersysteem

Tenminste, dat lijkt mij dan. Je zou dit wel kunnen gebruiken, maar erg efficient werkt het niet. je moet de hele tijd je html ingraven tussen php stukjes terwijl dat met tbs in ieder geval niet hoeft

Waarom zou dat bij php wel "hoeven", dan? En efficient lijkt mij weinig aan de orde; je gaat mij niet vertellen dat een stuk templateengine in PHP zelf geschreven sneller of efficienter werkt dan de engine van PHP...

[Bosmonster]

Verwijderd schreef op 07 juni 2004 @ 16:14:
[...]
mwa, het gaat hem om de beheerbaarheid, en ik voeg met een template engine juist mogelijkheden toe aangezien veel gebruikers juist html wel kennen, maar van php de ballen verstand hebben. Zij kunnen door gebruik van de template engine wel layout wijzigingen maken. Dit komt dubbel zo sterk naar voren als je dit professioneel toe past en grafisch ontwerpers aan je templates laat komen. Die wil je niet in je php hebben rotzooien....

Dat je geen 'losse' template engine gebruikt wil niet zeggen dat je ineens je code/html door elkaar heen moet gaan gooien natuurlijk. Met PHP kun je net zo eenvoudig alleen losse variabelen/control-structures toepassen in je templates en de code daar buiten houden. EXACT wat een hele 'losse' template-engine doet dus.

edit:
Euh, ja wat drm zegt dus

[ Voor 5% gewijzigd door Bosmonster op 07-06-2004 16:53 ]

[Verwijderd]

Ik ben sinds kort voor het eerst templates gaan gebruiken. Ik snapte het belang in eerste instantie ook niet (PHP is toch al handig zat?) maar nu begin ik de voordelen echt in te zien. Ik gebruik die van PHPlib (geen idee hoe smarty e.d. werken, maar voor PHPlib templates zijn ook wat tutorials te vinden wat wel een plus is). Als eerste voordeel is gewoon het feit dat je totaal geen codes meer hebt in je html. Alleen af en toe een template variabele (in PHPlib is dat {var} ) wat ik persoonlijk gewoon een stuk mooier en netter vind. In PHP zou je er <?php echo $var ?> van moeten maken (heb een persoonlijke afkeur van de ingekorte versie <?=$var ?>, als ik het goed heb). Ik denk dat de meeste {var} of %var% wel mooier vinden. Daarnaast is het gemakkelijker om een rij tabellen uit te spugen en de tabel makkelijk aan te passen. Wil je dit in php doen dan of ga je het bruut echo'en of je zet er een loop omheen (allebei een minder alternatief van de manieren die te gebruiken zijn met een 'degelijk' template systeem).

PHP is eigenlijk een programmeertaal door je opmaakcode heen geweven en zo gesteld is een template systeem logisch. (als je nu gaat flamen dat PHP een scripttaal is heb je mijn punt niet begrepen )

Ik heb een sterk vermoeden (en ik hoop dat ik hier niet een rij aan flames uitlok ) dat de meesten die beweren dat PHP op zich al template genoeg zijn zelf nog nooit een template systeem zelf gebruikt hebben, of lang genoeg gebruikt. Ik geef toe, het is eventjes wat moeite om het door te hebben bij een goed systeem maar je krijgt er stukken meer voor terug!

Tutorial voor PHPlib template class: http://www.phpbuilder.com/columns/david20000512.php3

Nog een kleine comment, persoonlijk schrijf ik alles liever zelf (houd niet van andermans werk ) maar ik heb nog niet de behoefte PHPlib template class zelf te schrijven, en in mijn ogen is dat zeer positief!

[dusty]

Zoals sommige mensen weten heb ik mijn eigen template engine gebouwd.

Ik heb mijn template engine zover ontwikkeld dat deze gedeeltes van de output kan cachen op variabelen, en daardoor dus heel veel tijdwinst kan boeken, hierdoor heb ik ook weer een gedeelte erbij moeten programmeren dat ik in een template kan aangeven dat als een bepaald gedeelte niet gecached is dat er een bepaalde stuk code uitgevoerd moet worden (of overgeslagen moet worden, opgelost door een keywoord in een array toe te voegen.) waardoor er in principe dus weer een hechtere binding tussen layout en code is gekomen. Terwijl ik dus wel de mogelijkheid behoud om makkelijk de templates aan te passen.

[drm]

GsusZ:
Ik ben sinds kort voor het eerst templates gaan gebruiken. Ik snapte het belang in eerste instantie ook niet (PHP is toch al handig zat?) maar nu begin ik de voordelen echt in te zien. Ik gebruik die van PHPlib (geen idee hoe smarty e.d. werken, maar voor PHPlib templates zijn ook wat tutorials te vinden wat wel een plus is). Als eerste voordeel is gewoon het feit dat je totaal geen codes meer hebt in je html. Alleen af en toe een template variabele (in PHPlib is dat {var} ) wat ik persoonlijk gewoon een stuk mooier en netter vind. In PHP zou je er van moeten maken (heb een persoonlijke afkeur van de ingekorte versie , als ik het goed heb). Ik denk dat de meeste {var} of %var% wel mooier vinden.

Wel of niet mooi vind ik niet echt een argument, sorry <?= ... ?> is imo net zo werkbaar als {...}, met het grote voordeel dat je er nog meer mee kunt dan alleen maar een variabele uitprinten, bijvoorbeeld functies aanroepen. (zie ook verderop)

Daarnaast is het gemakkelijker om een rij tabellen uit te spugen en de tabel makkelijk aan te passen. Wil je dit in php doen dan of ga je het bruut echo'en of je zet er een loop omheen (allebei een minder alternatief van de manieren die te gebruiken zijn met een 'degelijk' template systeem).

Je bedoelt dat zo'n templatesysteem een of andere functie heeft die 'spuug_tabel_uit' heeft ofzo? Wat weerhoudt je ervan om dergelijke functies even zelf te schrijven (en daarmee ook makkelijker aan te passen maakt)?

PHP:

<html>
   <?=spuug_tabel_uit ( $mijn_tabel_waarden )?>
</html>

PHP is eigenlijk een programmeertaal door je opmaakcode heen geweven en zo gesteld is een template systeem logisch.

Inderdaad.

Ik heb een sterk vermoeden (en ik hoop dat ik hier niet een rij aan flames uitlok ) dat de meesten die beweren dat PHP op zich al template genoeg zijn zelf nog nooit een template systeem zelf gebruikt hebben, of lang genoeg gebruikt.

Ik heb al heel wat dingen gebruikt in die trant, zelf geschreven, uitgeprobeerd, etc. Maar je loopt altijd tegen het probleem aan dat je functionaliteit mist. Bijvoorbeeld een simpele sprintf (), of strftime, sorteerfuncties, noem maar op...

Nog een kleine comment, persoonlijk schrijf ik alles liever zelf (houd niet van andermans werk ) maar ik heb nog niet de behoefte PHPlib template class zelf te schrijven, en in mijn ogen is dat zeer positief!

Dat is een punt waar ik me enigszins in kan vinden, dat een templatesysteem functionaliteit toevoegt die je liever niet zelf schrijft. Maar dat is alleen maar een argument voor de templatesystemen die inderdaad gewoon kant-en-klare functionaliteit toevoegen die PHP niet heeft. Het is geen argument voor het gebruik van (andere) template-engines dan PHP zelf (imo)

[Verwijderd]

drm schreef op 07 juni 2004 @ 17:58:
[...]
Wel of niet mooi vind ik niet echt een argument, sorry <?= ... ?> is imo net zo werkbaar als {...}, met het grote voordeel dat je er nog meer mee kunt dan alleen maar een variabele uitprinten, bijvoorbeeld functies aanroepen. (zie ook verderop)

Ik geef toe, als argument kun je het afwuiven maar ik vind <?=...?> chinees en {...} pracht en praal

[...]
Je bedoelt dat zo'n templatesysteem een of andere functie heeft die 'spuug_tabel_uit' heeft ofzo? Wat weerhoudt je ervan om dergelijke functies even zelf te schrijven (en daarmee ook makkelijker aan te passen maakt)?

PHP:

<html>
   <?=spuug_tabel_uit ( $mijn_tabel_waarden )?>
</html>

Een ander alternatief is dus ipv van dat regeltje {tabel}, et voilá (ik moet bekennen dat ik dat niet in mijn hoofd had zitten op't moment )

Ik heb al heel wat dingen gebruikt in die trant, zelf geschreven, uitgeprobeerd, etc. Maar je loopt altijd tegen het probleem aan dat je functionaliteit mist. Bijvoorbeeld een simpele sprintf (), of strftime, sorteerfuncties, noem maar op...

Ik kan je op dit punt niet helemaal volgen als je het tekort van een tpl systeem probeert weer te geven, je doet alles buiten het template systeem om dus snap niet wat voor functie je erin zou moeten zetten. Het enige wat ik wel aan heb moeten passen (ik kom er net op) is dat ik een stukje nodig had om bepaalde variabelen te _zoeken_ in het bestand beginnend met bijv subm_ (zodat ik weet welke submodule er gevraagd word en dat ik die dan kan parsen, handig om snel ergens bijvoorbeeld de laatste 5 berichten van een forum te parsen)

[drm]

GsusZ:
Een ander alternatief is dus ipv van dat regeltje {tabel}, et voilá (ik moet bekennen dat ik dat niet in mijn hoofd had zitten op't moment )

En {tabel} bevat dan een bepaald format gegevens ofzo? Of is dat een twee-dimensionale array waarvan de template aanneemt dat het dan een tabel moet worden? Goed, kan ik me iets bijvoorstellen. Nog niet echt overtuigd, maar goed

Ik kan je op dit punt niet helemaal volgen als je het tekort van een tpl systeem probeert weer te geven, je doet alles buiten het template systeem om dus snap niet wat voor functie je erin zou moeten zetten.

Sja, dan kom je in een discussie terecht waarin we gaan bepalen wat wel en geen template-logic is. Dat is een groot grijs gebied. Laten we het erop houden dat we dan allebei aan een andere kant van dat grijze gebied zitten...

[Verwijderd]

drm schreef op 07 juni 2004 @ 18:20:
[...]
En {tabel} bevat dan een bepaald format gegevens ofzo? Of is dat een twee-dimensionale array waarvan de template aanneemt dat het dan een tabel moet worden? Goed, kan ik me iets bijvoorstellen. Nog niet echt overtuigd, maar goed

code:

table.html (of table. welke andere extentie dan ook)
-------------------------
<table width="100%" cellspacing="0" cellpadding="0">
<thead>
  <tr>
    <td>Allemaal regeltjes enzow</td>
  </tr>
</thead>
<tfoot>
  <!-- BEGIN tablerow -->
  <tr><td>{plaatje} <a href="{link}">{link_description}</a></td></tr>
  <!-- END tablerow -->
</tfoot>
</table>

main.html
-------------------------
<div align="center">
{onze_tabel}
</div>

Het idee is dat je table.html dan laad in de template parser (klinkt ingewikkeler dan het altijd is) en dat geef je de naam onze_tabel. Je kan met behulp van een set_block functie die tablerow blijven herhalen zodat je een tabel met gegevens kan creeëren. Op't eind laad je ergens main.html en hij ziet daar onze_tabel en we hadden al gezegd dat hij table.html als onze_tabel moest laden, dus parsed hij hem er mooi in.
Alternatief zonder templates: je gaat met $echo .= "<tr><td>en alle andere tags</td></tr>"; aan de gang of je laad hem in een functie (waarbij je dus de tabel ergens verstopt in je code waardoor je nog minder overzicht houd, ik prefereer dan nog altijd de loop direct in de html).
Bij de manier van templates hierboven blijf je puur html houden op {...} na. In ieder geval zullen designers het liefst op die manier willen werken lijkt me...

[...]
Sja, dan kom je in een discussie terecht waarin we gaan bepalen wat wel en geen template-logic is. Dat is een groot grijs gebied. Laten we het erop houden dat we dan allebei aan een andere kant van dat grijze gebied zitten...

Ik durf er niet verder op in te gaan

edit:
In mijn voorbeeld splits ik het in 2 files, je kan het ook in 1 file laten staan door om wat ik nu table.html genoemd heb <!-- BEGIN table --><!-- END table --> te zetten maar ik splits het het liefst uit aangezien ik dan de table.html file ook op andere plaatsen kan gebruiken en hierdoor een flexibeler (en makkelijker aan te passen) systeem krijg.

[ Voor 24% gewijzigd door Verwijderd op 07-06-2004 18:38 ]

[Verwijderd]

Ik sluit me bij GsusZ aan, wat hij zegt is gewoon waar imo.

Maar 1 ding heb ik hem niet zien zeggen: php templates zijn onveiliger, iemand kan gewoon zn eigen code gaan lopen schrijven in jouw php code, terwijl dat in "mijn" systeem onmogelijk is, je kunt alleen de mooie opmaak vernagelen. En soms er eens iets aan veranderen, waarbij je de layout sowieso erg goed kunt aanpassen.

Dus uit een oogpunt op -wel beveiliging, maar toch aanpasbare websites leveren- zeg ik dat je template engines wel heel erg interessant moet vinden!

En als er nou iemand zegt: "Ja maar, ze kunnen je php bestanden toch ook aanpassen" dan moet hij/zij maar eens hier gaan kijken: IonCube want daarmee encodeer je je php bestanden. Werkt zo ongeveer als de Zend equivalent, maar deze blijkt sneller en betrouwbaarder (ook al heb ik hier geen bewijs van, op het gebied van sneller geloof ik ze wel)

[ Voor 6% gewijzigd door Verwijderd op 07-06-2004 19:26 ]

[djluc]

Dus uit een oogpunt op -wel beveiliging, maar toch aanpasbare websites leveren- zeg ik dat je template engines wel heel erg interessant moet vinden!

Waarom zou je zelf code kunnen gaan schrijven als je PHP als template parser gebruikt? Als je gewoon een goed opgezet systeem hebt en je aan de regel houdt dat je user-input nooit mag vertrouwen zie ik geen enkel probleem.

[MisterData]

Ik heb zelf heel lang mijn zelfgemaakte stackbased template parser gebruikt (zie https://svn.mycms.nl/tplphp/) maar ik gebruik nu XSLT met PHP5. Dat werkt lekker en snel en is nog veel beter ook Makkelijk ondersteuning voor foreaches, moeilijke XPath queries, etc XSLT is gewoon een goede template-taal in mijn ogen.

[Verwijderd]

Verwijderd schreef op 07 juni 2004 @ 17:17:
Ik heb een sterk vermoeden (en ik hoop dat ik hier niet een rij aan flames uitlok ) dat de meesten die beweren dat PHP op zich al template genoeg zijn zelf nog nooit een template systeem zelf gebruikt hebben, of lang genoeg gebruikt.

Ehhh, ik heb een andere mening: De mensen die beweren dat PHP opzich zelf al een templatetaal is, zijn door schande wijs geworden. Deze mensen hebben veel ervaring opgedaan met Templates, zoals Smarty, en hebben uiteindelijk het licht gezien: PHP.

Verwijderd schreef op 07 juni 2004 @ 18:34:
Alternatief zonder templates: je gaat met $echo .= "<tr><td>en alle andere tags</td></tr>"; aan de gang of je laad hem in een functie (waarbij je dus de tabel ergens verstopt in je code waardoor je nog minder overzicht houd, ik prefereer dan nog altijd de loop direct in de html).

En waarom zo ik met PHP als templatetaal niet exact hetzelfde kunnen doen? Als ik jouw zelfde voorbeeld zou gebruiken wordt het als volgt:

code:

table.html (of table. welke andere extentie dan ook)
-------------------------
<table width="100%" cellspacing="0" cellpadding="0">
<thead>
  <tr>
    <td>Allemaal regeltjes enzow</td>
  </tr>
</thead>
<tfoot>
  <? foreach($results as $row) { // BEGIN LOOP ?>
  <tr><td><?=$row['plaatje']?> <a href="<?=$row['link']?>"><?=$row['link_description']?></a></td></tr>
  <? } // END LOOP ?>
</tfoot>
</table>

main.html
-------------------------
<h1><?=$title?></h1>
<div align="center">
<?=$table?>
</div>

Verwijderd schreef op 07 juni 2004 @ 18:34:Bij de manier van templates hierboven blijf je puur html houden op {...} na. In ieder geval zullen designers het liefst op die manier willen werken lijkt me...

Bij mij voorbeeld heb je puur HTML en een beetje PHP om de presentatie te beinvloeden. Het is jouw mening dat designers alleen op jouw manier willen werken. Ik ben dit niet met je eens: Er is namelijk weinig verschil in de manier hoe designers jouw templatetaal moeten leren vs. basis PHP leren.

En het punt dat je { mooier vindt, rechtvaardigt IMHO niet de overhead voor een templatetaal. Geen enkele template taal kan tippen aan native PHP, dus dien je betere reden te hebben dan 'ik vind het mooier' .

djluc schreef op 07 juni 2004 @ 19:52:
[...]
Waarom zou je zelf code kunnen gaan schrijven als je PHP als template parser gebruikt? Als je gewoon een goed opgezet systeem hebt en je aan de regel houdt dat je user-input nooit mag vertrouwen zie ik geen enkel probleem.

Precies, dus ook dit is geen reden om een templatetaal boven native PHP te kiezen.

MisterData schreef op 07 juni 2004 @ 19:53:
XSLT is gewoon een goede template-taal in mijn ogen.

Ben ik met je eens .

-Rémy

[MisterData]

Een goede reden die ik zou kunnen bedenken voor het gebruik van template-engines is dat layout en code volledig gescheiden kan zijn. Als je PHP gebruikt als template-engine dan heb je toch de neiging om een aantal dingen te coden in je template, template-engines dwingen je dat niet te doen

[PrisonerOfPain]

Verwijderd schreef op 07 juni 2004 @ 17:17:
Ik ben sinds kort voor het eerst templates gaan gebruiken. Ik snapte het belang in eerste instantie ook niet (PHP is toch al handig zat?) maar nu begin ik de voordelen echt in te zien. Ik gebruik die van PHPlib (geen idee hoe smarty e.d. werken, maar voor PHPlib templates zijn ook wat tutorials te vinden wat wel een plus is). Als eerste voordeel is gewoon het feit dat je totaal geen codes meer hebt in je html.

Nee, het doel is over het algemeen het scheiden van presentatie (data) en bussiness logica. Zie bijvoorbeeld het n-tier model.

Alleen af en toe een template variabele (in PHPlib is dat {var} ) wat ik persoonlijk gewoon een stuk mooier en netter vind. In PHP zou je er <?php echo $var ?> van moeten maken (heb een persoonlijke afkeur van de ingekorte versie <?=$var ?>, als ik het goed heb). Ik denk dat de meeste {var} of %var% wel mooier vinden.

Je kan in de final versie een grote search&replace doen en <?= vervangen door <?php echo en vanwaar die afkeur? De meeste hosts ondersteunen het echt wel, ik het een tijd net zo 'vies' gevonden als register_globals = On gebruiken. Als je PHP in XML wil embedding is het eigenlijk de enige reden om short_tags uit te zetten, maar dan kun je gewoon de asp style tags gebruiken, <%=$var%> word het dan.

Daarnaast is het gemakkelijker om een rij tabellen uit te spugen en de tabel makkelijk aan te passen. Wil je dit in php doen dan of ga je het bruut echo'en of je zet er een loop omheen (allebei een minder alternatief van de manieren die te gebruiken zijn met een 'degelijk' template systeem).

http://php.net/include Kortom, je maakt een tabel.tpl.php file aan en die include je, op dezelfde manier als je template engine.

PHP is eigenlijk een programmeertaal door je opmaakcode heen geweven en zo gesteld is een template systeem logisch.

PHP is een hypertext preprocessor, ofwel een interpreted script taal die over je bestand heen loopt om zou output te vormen voor de browser, net als een template engine doet. Je geeft zelf ook al aan dat je PHP door je markup kan weven, waarom zou je deze functionaliteit dan niet gebruiken?

Ik heb een sterk vermoeden (en ik hoop dat ik hier niet een rij aan flames uitlok ) dat de meesten die beweren dat PHP op zich al template genoeg zijn zelf nog nooit een template systeem zelf gebruikt hebben, of lang genoeg gebruikt. Ik geef toe, het is eventjes wat moeite om het door te hebben bij een goed systeem maar je krijgt er stukken meer voor terug!

Ik heb een tijd fastTemplate gebruikt maar ben daar na een tijdje vanaf gestapt om dat ik op den duur zoveel aan de engine had veranderd dat ik inzag dat het veel makkelijker kon, met PHP zelf. De alternatieve syntax leent zich hier uitstekend voor. Geen rondslingerende haken meer, en het is overzichtelijk wat je waar afsluit.

Nog een kleine comment, persoonlijk schrijf ik alles liever zelf (houd niet van andermans werk ) maar ik heb nog niet de behoefte PHPlib template class zelf te schrijven, en in mijn ogen is dat zeer positief!

Dat heb ik ook en dat is precies de reden dat ik nog incidenteel gebruik maak van de PEAR reposity, deze is gewoon veel te bloated geworden en het is veel leuker om het zelf te scripten.

[djluc]

MisterData schreef op 07 juni 2004 @ 21:27:
Een goede reden die ik zou kunnen bedenken voor het gebruik van template-engines is dat layout en code volledig gescheiden kan zijn. Als je PHP gebruikt als template-engine dan heb je toch de neiging om een aantal dingen te coden in je template, template-engines dwingen je dat niet te doen

Dat is gewoon jezelf aan regels houden en jezelf dwingen om alles te doen volgens de regels die je op stelt. Dus dat kan ik niet echt een goede reden noemen. Zoals al eerder gezegd: de vraag wat template of business logica is blijkt een grijs gebied. Overigens kun je met Smarty ook al zo enorm veel dat je ook daar jezelf moet dwingen niet de gekste dingen in je template te doen die er niet thuis horen. Om over XSL en alle andere mogelijkheden daaromheen nog maar te zwijgen.

[Verwijderd]

Ik heb smarty eens bekeken, en ik ga nogmaals herhalen hoe het werkt om de verschillen duidelijk te maken.

PHPlib kent maar 2 constructies, de {var} constructie en de <!-- BEGIN block --><!-- END block -->. Er bestaan geen loops, dus {section name=i loop=$friends} komt niet voor of dergelijke andere combinaties. Hoe je dan wel een rij aan gegevens aanbrengt is kan op 2 manieren. Of je zet de <tr><td></td></tr> rij in een apart bestand, of je zet er <!-- BEGIN block --><!-- END block --> omheen en 'plukt' hem uit het bestand met set_block. Uiteindelijk is het resultaat hetzelfde, de PHPlib template class ziet beide als een variabele met daarin (eventueel) ook andere variabelen.
Nu zet je je loop in de php, klein voorbeeldje

PHP:

while ($data = $db->fetchassoc($select))
{
    $t->set_var(array(
             "var1" => $data['var1'],
             "var2" => $data['var2'],
             "var3" => functie($data['var3'])
             ));
    $t->parse("block", "grouprow", true);
}

Op die manier bouw je je output in PHPlib, het is niet mogelijk dit via een loop in de html zelf te doen. De kracht ligt in de simpelheid ervan.
Er zijn ook maar 4 functies voorhanden, set_var, set_block, set_file (pagina inladen) en eventueel set_root (om het pad naar de folder met de templates te geven, kun je set_file korter schrijven).

Ik heb dit even uitgelegd nadat ik wat meer had rondgeneusd in smarty en XSLT (ik kende ze wel en heb XSLT een paar maand geleden ook geprobeerd, hoewel ik XSLT te bekennen, snel opgaf). Ik kreeg het gevoel dat de output nogsteeds te veel gestuurd werd via constructies die met PHPlib niet nodig/mogelijk zijn.

Ik heb een tijd fastTemplate gebruikt maar ben daar na een tijdje vanaf gestapt om dat ik op den duur zoveel aan de engine had veranderd dat ik inzag dat het veel makkelijker kon, met PHP zelf. De alternatieve syntax leent zich hier uitstekend voor. Geen rondslingerende haken meer, en het is overzichtelijk wat je waar afsluit.

Aangezien je altijd maar enkel via die 2 constructies kan werken (je kan ook slechts 1 gebruiken maar <!-- BEGIN / END --> is makkelijk om stukjes in de pagina zelf eruit te knippen) zie ik niet zo snel aan wat wel aan de engine te moeten veranderen (op mijn zoek variabelen functie na misschien ).

Nu zullen sommigen denken, als je zo weinig met die PHPlib class kan wat heb je er dan nog verder aan? Dat is juist (zoals zovelen het met mij eens zijn heb ik gemerkt ) de kracht van PHP, php kan al die constructies makkelijk zelf oplossen een een designer hoeft echt niet aan al die loops-regex etc constructies te komen. Smarty is een mooi systeem, maar je kan netzo goed al die constructies terugbrengen in PHP. Sommige template systemen proberen PHP te vervangen, wat op zich totaal overbodig is.

Overigens lijkt mij wel dat je met smarty op dezelfde manier kan werken als hierboven beschreven, maar daar word je naar mijn vermoeden niet naar gestuurd terwijl PHP op zich een stuk krachtiger is dan een vervangende template taal.

Het enige wat een templatesysteem in mijn opzichte hoef te doen is de HTML en code scheiden, meer functie hoeft er niet aan vast te zitten en dit is in PHPlib het geval.

(ik zit nog wat rond te pluizen met XSLT maar ik heb nogsteeds de grote voordelen er niet van ontdekt behalve dat het een standaard is en dat de 'templates' gemakkelijk geport kunnen worden naar een andere taal (ASP), wat voor mij totaal niet relevant is verder)

[grootvoordeel]
Zonder er bij na te denken zit er een gigantisch en onmisbaar ander groot voordeel aan een templatesysteem (hoewel je het ook via omwegen zou kunnen oplossen). De mogelijkheid om alles in een vrij willekeurige volgorde op te bouwen. Tijdens het laden van een pagina hebben sommige delen die geladen worden bijv. een javascript/css file in de header nodig, deze kun je invoegen tot op het eind van de pagina. Zo zijn er nog 10 andere voorbeelden waarvoor ik deze functie nodig heb, maar dit voordeel is voor mij al genoeg reden _een_ tpl systeem te gebruiken. Een tpl variabele kun je altijd willekeurig ergens vullen, wordtie dat niet dan word niks uitgespuugd. Erg handig als je alles (zoals ik) in delen beschrijft en andere template delen laat bepalen welke submodule er wel of niet beschreven moeten worden
[/grootvoordeel]

Op de vraag of je HTML en code uberhaupt wel wilt scheiden kun je alleen zelf antwoord geven. Ik werk samen met een designer (niet mijn sterkste kant =]) en die is er iig heel blij mee. Als dat bij jou toch niet het geval zal zijn is het makkelijker (en sneller?) om het gewoon in de HTML zelf te schrijven.

[ Voor 21% gewijzigd door Verwijderd op 08-06-2004 09:06 . Reden: Laatste alinea toegevoegd om de discussie te verzachten ]

[Verwijderd]

Wederom sluit ik me aan bij GsusZ; template engines als Smarty zijn met zo veel functies dat je idd net zo goed php kunt grbuiken omdat er toch loops enzo in je html code komen.

en tbs is net zo als PHPLib als ik het zo lees; eenvoudig...
Je bepaald of iets een block (loop) is voornamelijk met je php code, in de template ziet het er niet anders uit afhankelijk van wat je als het block wildefinieren.

Ik vindt het wel apart dat niemand op mijn post over de beveiliging met IonCube heeft gereageerd terwijl dat mij toch wel een sterk punt voor een template engine is.

(Mijn vorige post was deze: klik hier)

Verwijderd schreef op 08 juni 2004 @ 08:45:
Op de vraag of je HTML en code uberhaupt wel wilt scheiden kun je alleen zelf antwoord geven. Ik werk samen met een designer (niet mijn sterkste kant =]) en die is er iig heel blij mee. Als dat bij jou toch niet het geval zal zijn is het makkelijker (en sneller?) om het gewoon in de HTML zelf te schrijven.

Ik ben zelf een prima -niet super- designer (KA gedaan), maar laat het liever over aan anderen omdat dit een ontwerp buiten je grenzen kan opleveren, en dat is dan weer een uitdaging, maar goed: Dit wat GsusZ zegt roep ik dus al de hele tijd als een ander sterk punt VOOR template engines, wat in het bedrijfsleven heel sterk naar voren komt. De amateur huis tuin en keukenprogrammeur zal hier niet snel bij na denken ben ik bang (hopelijk stoot ik nu niet te veel mensen voor hun kop )

[ Voor 59% gewijzigd door Verwijderd op 08-06-2004 09:37 ]

[ripexx]

Ik zie niet in wat beveiliging te maken heeft met template engines. Je mag nooit user input vertrouwen en als je het toch doet kan je genoeg problemen verwachten, een type fout is namelijk zo gemaakt. Zodra ik een bepaalde php aplicatie neem en deze op mijn server ga draaien kan ik in de source gaan rommelen tenzij je natuurlijk gebruik gaat maken van de zend encoder.

Voor een geavanceerd ontwerp loop je al snel tegen een aantal problemen aan die weer niet kunnen met een simpele template engine. Dus ga je over op aanpassingen of maak je een eigen engine.

Natuurlijk zullen er situaties zijn die voor problemen gaan zorgen maar goede documentatie is toch van belang. Verder hebben jullie het steeds over designers maar een goede webdesigner kan dus ook gewoon html en JS en dan weet je ook snel genoeg dat je van die php zut moet alfblijven. De situatie die jullie beschrijven is alleen een grafisch ontwerper, nou die geeft je psd en dan mag je het verder zelf uitzoeken, dus wat is dan het nut van je templates

Wat betreft dat IonCube kan je denk ik beter gwoon naar Zend gaan en krijg je meteen een stuk functionaliteit er voor terug. Het gaat meestal toch om het beschermen van de BL en eventueel optimalisaties.

Gebruik gewoon de juiste tools voor de juiste dingen. Een bepaalde applicatie is meestal toch niet zo'n grafisch ding en een paar kleurtjes en logo's doen wonderen

[Verwijderd]

ripexx schreef op 08 juni 2004 @ 13:35:
Ik zie niet in wat beveiliging te maken heeft met template engines. Je mag nooit user input vertrouwen en als je het toch doet kan je genoeg problemen verwachten, een type fout is namelijk zo gemaakt. Zodra ik een bepaalde php aplicatie neem en deze op mijn server ga draaien kan ik in de source gaan rommelen tenzij je natuurlijk gebruik gaat maken van de zend encoder.

Voor een geavanceerd ontwerp loop je al snel tegen een aantal problemen aan die weer niet kunnen met een simpele template engine. Dus ga je over op aanpassingen of maak je een eigen engine.

Natuurlijk zullen er situaties zijn die voor problemen gaan zorgen maar goede documentatie is toch van belang. Verder hebben jullie het steeds over designers maar een goede webdesigner kan dus ook gewoon html en JS en dan weet je ook snel genoeg dat je van die php zut moet alfblijven. De situatie die jullie beschrijven is alleen een grafisch ontwerper, nou die geeft je psd en dan mag je het verder zelf uitzoeken, dus wat is dan het nut van je templates

Wat betreft dat IonCube kan je denk ik beter gwoon naar Zend gaan en krijg je meteen een stuk functionaliteit er voor terug. Het gaat meestal toch om het beschermen van de BL en eventueel optimalisaties.

Gebruik gewoon de juiste tools voor de juiste dingen. Een bepaalde applicatie is meestal toch niet zo'n grafisch ding en een paar kleurtjes en logo's doen wonderen

Nou, dat ben ik niet met je eens. Allereerst is de hulp van IonCube fantastisch, en de juist vertaalde code 100% tot nu toe, en is ie efficienter dan Zend, en ik heb er ondertussen al navraag voor gedaan

Wat is dat stukje functionaliteit van zend dan eigenlijk?

De ontwerpers waar ik mee werk gebruiken idd Photoshop voor een initieel ontwerp, maar zijn wel degelijk bedreven in HTML, en templates aanpassen zijn ze dan ook aardig goed in. Nieuwe ontwerpers gaan eerst naar de cursus HTML...

Als je een site wilt onderhouden, of een onderhoudbare site weg geeft zonder broncode, is html lezen gewoon overzichtelijker dan php. Tenminste als je mijn programmatische problemen op moet lossen. Vaak is het niet simpel een tabelletje opbouwen rij voor rij, maar komen er heel wat if elsejes in voor ed...

Maar goed, html wordt er meer gesproken dan php, en het wordt beter beheerst dan php door de mensen die allebei spreken (lijkt me) dus html is altijd een betere keus als je het van die kant uit bekijkt...

[ripexx]

De functionaliteit van zend, werk er zelf niet mee omdat het gewoon te duur is voor de betreffende klussen, maar dat terzijde, wat dacht je van de zend optimizer en zend accelerator (soort cache) deze product suite van zend geeft gewoon een hoop extra. Met react is de preormance door gebruik t amken van zend geloof ik iets van 8% verbeterd. En dat maakt met die hoeveelheid pageviews echt wel uit.

[drm]

RwDwR:
Maar goed, html wordt er meer gesproken dan php, en het wordt beter beheerst dan php door de mensen die allebei spreken (lijkt me) dus html is altijd een betere keus als je het van die kant uit bekijkt...

En dat is dus onzin. Je zal een template taaltje, hoe eenvoudig ook, je ook eigen moeten maken als je daar mee wilt werken. En je kunt dan beter je ontwerpers de mogelijkheid bieden ook eens een beetje aan PHP te snuffelen (wat in templates echt geen hoge opstap heeft als het netjes is gedaan), want daar heb je dan in de toekomst ook gewoon meer aan (zij ook trouwens).

"HTML is makkelijker dan PHP" is echt een non-argument, omdat het bij templates niet bij html blijft, hoe dan ook.

[.oisyn]

Verwijderd schreef op 07 juni 2004 @ 18:34:
[...]

code:

table.html (of table. welke andere extentie dan ook)
-------------------------
<table width="100%" cellspacing="0" cellpadding="0">
<thead>
  <tr>
    <td>Allemaal regeltjes enzow</td>
  </tr>
</thead>
<tfoot>
  <!-- BEGIN tablerow -->
  <tr><td>{plaatje} <a href="{link}">{link_description}</a></td></tr>
  <!-- END tablerow -->
</tfoot>
</table>

main.html
-------------------------
<div align="center">
{onze_tabel}
</div>

[nohtml]Het idee is dat je table.html dan laad in de template parser (klinkt ingewikkeler dan het altijd is) en dat geef je de naam onze_tabel. Je kan met behulp van een set_block functie die tablerow blijven herhalen zodat je een tabel met gegevens kan creeëren. Op't eind laad je ergens main.html en hij ziet daar onze_tabel en we hadden al gezegd dat hij table.html als onze_tabel moest laden, dus parsed hij hem er mooi in.
Alternatief zonder templates: je gaat met $echo .= "<tr><td>en alle andere tags</td></tr>"; aan de gang of je laad hem in een functie (waarbij je dus de tabel ergens verstopt in je code waardoor je nog minder overzicht houd, ik prefereer dan nog altijd de loop direct in de html).
Bij de manier van templates hierboven blijf je puur html houden op {...} na. In ieder geval zullen designers het liefst op die manier willen werken lijkt me...[/nohtml]

Mja, dat met dat set_block vind ik dus zo'n ontzettende ranzige constructie. Dat is net zoiets als alleen een user-defined stylesheet toelaten om iets een andere look te geven: je hebt er geen fuck aan, omdat je dan gewoon vast zit aan de voorgedefinieerde opbouw. Met het voorbeeld dat jij geeft kan ik mijn data alleen rangschikken door rijen te herhalen, en dat rangschikken moet dan vervolgens ook nog eens vanuit code gebeuren. Dat noem ik geen scheiding van data en opmaak, het enige verschil is dat je niet de letterlijke html hoeft te outputten.

Scheiding van data en opmaak betekent dat je aan de ene kant puur en alleen de data hebt, en dat je aan de andere kant puur en alleen die data verwerkt in de opmaak. En hoe die verwerking vervolgens gedaan wordt mag een template devver helemaal zelf weten. Hij kan er bijvoorbeeld voor kiezen om de data in de omgekeerde volgorde weer te geven (kan op jouw manier niet), of door de data te ranschikken in meerdere kolommen per regel (kan op jouw manier ook niet). Of misschien wil ie de 5 bovenste elementen wel in een ander kleurtje afgebeeld hebben, of sowieso maar 10 elementen laten zien ipv die 35 waaruit je data bestaat.

Pas dan heb je echt scheiding tussen data en opmaak, dat zie ik met die blockstatements echt totaal niet terug

edit:
nu met nohtml tags

[ Voor 3% gewijzigd door drm op 08-06-2004 14:31 ]

[djluc]

Of misschien wil ie de 5 bovenste elementen wel in een ander kleurtje afgebeeld hebben, of sowieso maar 10 elementen laten zien ipv die 35 waaruit je data bestaat.

En dan heb je een template engine die niet zo uitgebreid is als Smarty: heeft bijvoorbeeld alleen variablen en blokken. Je kunt dus niet even kijken of je al aan de 5 items zit. Het is een duidelijk voorbeeld van template logica, maarja als de template engine het niet ondersteund en Smary is ook weer overkill want daarmee maak je PHP gewoon na heb je dus niets aan een template engine.

[Verwijderd]

ripexx schreef op 08 juni 2004 @ 14:25:
De functionaliteit van zend, werk er zelf niet mee omdat het gewoon te duur is voor de betreffende klussen, maar dat terzijde, wat dacht je van de zend optimizer en zend accelerator (soort cache) deze product suite van zend geeft gewoon een hoop extra. Met react is de preormance door gebruik t amken van zend geloof ik iets van 8% verbeterd. En dat maakt met die hoeveelheid pageviews echt wel uit.

Ok, standaard in IonCube voor zover ik kan zien...

drm schreef op 08 juni 2004 @ 14:27:
[...]
En dat is dus onzin. Je zal een template taaltje, hoe eenvoudig ook, je ook eigen moeten maken als je daar mee wilt werken. En je kunt dan beter je ontwerpers de mogelijkheid bieden ook eens een beetje aan PHP te snuffelen (wat in templates echt geen hoge opstap heeft als het netjes is gedaan), want daar heb je dan in de toekomst ook gewoon meer aan (zij ook trouwens).

"HTML is makkelijker dan PHP" is echt een non-argument, omdat het bij templates niet bij html blijft, hoe dan ook.

Ik ben de programmeur, ik bemoei me niet met design, en zij bemoeien zich niet met de php, je krijgt altijd halfbakken code van ze terug, ook al bedoelen ze het goed. Kijk maar eens naar de code van de meesten die hier posten, ze zijn er waarschijnlijk meer mee bezig dan een designer, maar soms is het toch wel zooo erg slecht...

.oisyn schreef op 08 juni 2004 @ 14:28:

Mja, dat met dat set_block vind ik dus zo'n ontzettende ranzige constructie. Dat is net zoiets als alleen een user-defined stylesheet toelaten om iets een andere look te geven: je hebt er geen fuck aan, omdat je dan gewoon vast zit aan de voorgedefinieerde opbouw. Met het voorbeeld dat jij geeft kan ik mijn data alleen rangschikken door rijen te herhalen, en dat rangschikken moet dan vervolgens ook nog eens vanuit code gebeuren. Dat noem ik geen scheiding van data en opmaak, het enige verschil is dat je niet de letterlijke html hoeft te outputten.

Scheiding van data en opmaak betekent dat je aan de ene kant puur en alleen de data hebt, en dat je aan de andere kant puur en alleen die data verwerkt in de opmaak. En hoe die verwerking vervolgens gedaan wordt mag een template devver helemaal zelf weten. Hij kan er bijvoorbeeld voor kiezen om de data in de omgekeerde volgorde weer te geven (kan op jouw manier niet), of door de data te ranschikken in meerdere kolommen per regel (kan op jouw manier ook niet). Of misschien wil ie de 5 bovenste elementen wel in een ander kleurtje afgebeeld hebben, of sowieso maar 10 elementen laten zien ipv die 35 waaruit je data bestaat.

Ik kan met tbs wel degelijk rangschikken hoe ik wil, en die rangschikking kan ik zowel in de php als in het template aangeven en multipaging, om er maar 10 te laten zien kan tbs ook (maar das een vieze methode, en dat kun je beter php kant regelen, maar toch....)
Einde van je argument, sorry

Pas dan heb je echt scheiding tussen data en opmaak, dat zie ik met die blockstatements echt totaal niet terug

Zo, en nu jij weer (maw, hier zie je het voordeel toch wel door, of niet dan?)

[drm]

RwDwR:
Ik ben de programmeur, ik bemoei me niet met design, en zij bemoeien zich niet met de php, je krijgt altijd halfbakken code van ze terug, ook al bedoelen ze het goed. Kijk maar eens naar de code van de meesten die hier posten, ze zijn er waarschijnlijk meer mee bezig dan een designer, maar soms is het toch wel zooo erg slecht...

Ja, en daarom zei ik ook dat je ze gewoon moet verbieden aan de stukjes te komen die tussen <? en ?> staan. Of je nou dat zegt of dat ze niet aan de stukjes moeten komen die tussen { en }, of <!-- en --> ontgaat mij echt volledig.

offtopic:
Dat laatste heb ik overigens altijd iets raars gevonden, de syntax voor commentaar gebruiken om code in te stoppen.

Ik kan met tbs wel degelijk rangschikken hoe ik wil, en die rangschikking kan ik zowel in de php als in het template aangeven en multipaging, om er maar 10 te laten zien kan tbs ook (maar das een vieze methode, en dat kun je beter php kant regelen, maar toch....)
Einde van je argument, sorry

mmkay, je hebt een vieze methode, je kunt het beter in php doen, maar toch is tbs beter dan php You've lost me there...

Zo, en nu jij weer (maw, hier zie je het voordeel toch wel door, of niet dan?)

*zucht* Dat geeft alleen maar aan waarom je een template engine zou gebruiken, niet waarom je een andere zou gebruiken dan PHP...

[Verwijderd]

drm schreef op 08 juni 2004 @ 15:17:
[...]
Ja, en daarom zei ik ook dat je ze gewoon moet verbieden aan de stukjes te komen die tussen <? en ?> staan. Of je nou dat zegt of dat ze niet aan de stukjes moeten komen die tussen { en }, of <!-- en --> ontgaat mij echt volledig. [ot] Dat laatste heb ik overigens altijd iets raars gevonden, de syntax voor commentaar gebruiken om code in te stoppen.

Ik heb niet alleen met de designers te maken, ook met klanten, einde verhaal, want die kan ik niks verbieden, die kan ik alleen beperken

mmkay, je hebt een vieze methode, je kunt het beter in php doen, maar toch is tbs beter dan php You've lost me there...

Je doet het er om heh? das een onlgische redenering. Elek voordeel heb zn nadeel. en een LIMIT 10, 10 inbouwen is niet echt erg. De template engine kan dit wel, echter er wordt dan meer opgehaald dan 10 rijen. Voor die andere dingen is tbs beter, maar dat vergeet jij dan voor het gemak en je opmerking dan maar

*zucht* Dat geeft alleen maar aan waarom je een template engine zou gebruiken, niet waarom je een andere zou gebruiken dan PHP...

LEZEN! het wordt vergeleken met PHP, of snap je dat niet?

[drm]

RwDwR:
Ik heb niet alleen met de designers te maken, ook met klanten, einde verhaal, want die kan ik niks verbieden, die kan ik alleen beperken

Dat is dus allang als voordeel van een template-engine aangemerkt in dit topic (ook door mij, ftr)

Je doet het er om heh?

Tuurlijk ....

das een onlgische redenering. Elek voordeel heb zn nadeel. en een LIMIT 10, 10 inbouwen is niet echt erg. De template engine kan dit wel, echter er wordt dan meer opgehaald dan 10 rijen. Voor die andere dingen is tbs beter, maar dat vergeet jij dan voor het gemak en je opmerking dan maar

Ik ben blij dat je het toch nog even uitlegt.

LEZEN! het wordt vergeleken met PHP, of snap je dat niet?

EXCUSE ME, maar je mist mijn PUNT.

Ik zal even een voorbeeld geven van wat zij (volgens mij) bedoelen (aan de hand van een stukje code)

1. PHP:
   

   <?php
   $query = "SELECT some, stuff FROM myTable";
   $res = mysql_query ( $query );
   if ( mysql_num_rows ( $res ) ) {
      ?><table><?php
      while ( $row = mysql_fetch_assoc ( $query ) ) {
         ?>
         <tr>
            <td><?php echo htmlentities ( $row [ 'some' ] ) ?></td>
            <td><?php echo htmlentities ( $row [ 'stuff' ] ) ?></td>
         </tr>
         <?
      }
      ?></table><?php
   } else {
      ?><p>Er zijn geen resultaten</p><?
   }
   ?>

   
   

   ---

2. Met zo'n templateengine als tbs zou het dus zoiets worden (ik verzin maar wat, ik ken de syntax niet, maar het idee is duidelijk):
   
   PHP:
   

   <?php
   $query = "SELECT some, stuff FROM myTable";
   $res = mysql_query ( $query );
   $rows = array ();
   while ( $row = mysql_fetch_assoc ( $res ) ) {
      $rows[]= $row;
   }
   $template = new Template ( 'myTable' );
   $template->assign ( 'rows', $rows );
   
   $template->print ()
   ?>

   
   Met template:
   
   code:
   

   [rows leeg?]
   
      <p>Er zijn geen resultaten</p>
   
      [anders]
   
      <table>
         [dit block voor alle 'rows']
            <tr>
               <td>[some]</td>
               <td>[stuff]</td>
            </tr>
         [/dit block]
      </table>
   [/rows leeg]

   
   

   ---

3. PHP:
   

   <?php
   $output = array ();
   
   $query = "SELECT some, stuff FROM myTable";
   $res = mysql_query ( $query );
   $output [ 'rows' ] = array ();
   while ( $row = mysql_fetch_assoc ( $res ) ) {
      $output [ 'rows' ][]= $row;
   }
   
   include ( './template/mytable.php' );
   ?>

   
   Met als template:
   
   PHP:
   

   <? if ( empty ( $output [ 'rows' ] ) ): ?>
      <p>Er zijn geen resultaten</p>
   <? else: ?>
      <table>
         <?foreach ( $output [ 'rows' ] as $row ): ?>
            <tr>
               <td><?=html ( $row [ 'some' ] )?></td>
               <td><?=html ( $row [ 'stuff' ] )?></td>
            </tr>
         <?endforeach;?>
      </table>
   <? endif; ?>

Het voordeel van 2 boven 1 is natuurlijk duidelijk. Maar geef nou eens concreet aan waarom 2 nou zo veel beter is dan 3 (ondersteun het eventueel met de goeie syntax van jouw favoriete template-engine)

[Verwijderd]

drm schreef op 08 juni 2004 @ 15:17:
[...]
Ja, en daarom zei ik ook dat je ze gewoon moet verbieden aan de stukjes te komen die tussen <? en ?> staan. Of je nou dat zegt of dat ze niet aan de stukjes moeten komen die tussen { en }, of <!-- en --> ontgaat mij echt volledig. [ot] Dat laatste heb ik overigens altijd iets raars gevonden, de syntax voor commentaar gebruiken om code in te stoppen.

Zal zijn om de designer meer een alleen html omgeving te geven (een comment zal wat meer herkenbaarheid geven dan {section name=i loop(etc)}. Ik vind het ook niet helemaal logisch maar dat zal het idee erachter zijn...

[grootvoordeel]
Zonder er bij na te denken zit er een gigantisch en onmisbaar ander groot voordeel aan een templatesysteem (hoewel je het ook via omwegen zou kunnen oplossen). De mogelijkheid om alles in een vrij willekeurige volgorde op te bouwen. Tijdens het laden van een pagina hebben sommige delen die geladen worden bijv. een javascript/css file in de header nodig, deze kun je invoegen tot op het eind van de pagina. Zo zijn er nog 10 andere voorbeelden waarvoor ik deze functie nodig heb, maar dit voordeel is voor mij al genoeg reden _een_ tpl systeem te gebruiken. Een tpl variabele kun je altijd willekeurig ergens vullen, wordtie dat niet dan word niks uitgespuugd. Erg handig als je alles (zoals ik) in delen beschrijft en andere template delen laat bepalen welke submodule er wel of niet beschreven moeten worden
[/grootvoordeel]

Vergeet mijn grootvoordeel niet! 'T staat er een beetje slordig maar de bedoeling is goed . Ik zou niet 123 weten hoe ik dat probleem met XML/XSLT zou moeten oplossen, tenzij ik eigenlijk hetzelfde doe wat nu mijn template parser al doet: bepaalde stukjes code zoeken in de HTML en die invullen en op het eind pas alles uitspugen. Misschien heb ik gewoon te weinig verstand van XML en XSLT maar denk dat een template parser hier gemakkelijker & sneller in is. Vergeet niet: ik bepaalde opmaak van de website niet, dat doet de designer. Die zegt: hier wil ik de forum tracker, hier wil ik de nieuws waslijst etc. Overigens werk ik samen met iemand die wel HTML kan en niet alleen een PSD file kan hanteren . PHP is hem (mede dankzij mij) compleet onbekend

Ik zie een designer nog geen XSLT leren om de volgorde van de output te veranderen? De kans dat hij dat wil is uberhaupt al gering (het enige wat je ooit zou willen veranderen aan de volgorde is dat een user kan bepalen op bijvoorbeeld een categorie/naam/tijd te sorteren, en aangezien al mijn gegevens toch al mooi in de database staan hebben we daar SQL voor uitgevonden). Oftewel de enige die dan XSLT kan hanteren ben jij maar het grappige is dat je het opmaken van de data net zo goed in PHP kan doen.

[Bosmonster]

Een designer/frontend-developer (ik zie ze nog steeds liever gescheiden, het zijn 2 compleet verschillende disciplines) die html kent hoort ook te weten hoe om te gaan met backend code.

Of die backend code nou geformat is met blokhaken voor template-engines of met php-tags maakt dan geen zak uit natuurlijk. Het blijven eenvoudige control-structures/variabelen die een html-er moet kunnen snappen als die met een backend-developer wil samenwerken.

[ Voor 39% gewijzigd door Bosmonster op 08-06-2004 16:26 ]

[.oisyn]

Verwijderd schreef op 08 juni 2004 @ 15:10:
Ik kan met tbs wel degelijk rangschikken hoe ik wil, en die rangschikking kan ik zowel in de php als in het template aangeven en multipaging, om er maar 10 te laten zien kan tbs ook (maar das een vieze methode, en dat kun je beter php kant regelen, maar toch....)

Anders lees je even goed, ik ging in op de reactie van GsusZ die PHPlib gebruikt. Dat jij daarvoor tbs gebruikt moet je zelf weten, maar het kan net zo goed met PHP, alleen dat was niet de discussie, ik had het over de manier waarop PHPlib templates afhandelde. Leuk dat tbs dat anders doet, maar wat heeft dat in hemelsnaam met mijn argumenten die ik gaf te maken?

(Trouwens, wat is het voordeel van tbs tov PHP?)

Einde van je argument, sorry

cursusje discussieren nodig? Ik ben niet onder de indruk

Zo, en nu jij weer (maw, hier zie je het voordeel toch wel door, of niet dan?)

Sorry, maar nee. Wat is je punt nou precies Daar wordt bewezen dat je html niet vanuit je logic layer moet outputten. Doe ik ook niet, maar ik gebruik wel php. Ik heb de template files apart van de logic files, dus data en opmaak is gescheiden. Dat is de essentie van het linkje dat jij postte, niet dat je geen PHP mag gebruiken.

Oftewel, zie de laatste post van drm, daar ga ik in mee.

[ Voor 5% gewijzigd door .oisyn op 08-06-2004 16:26 ]

[Verwijderd]

drm schreef op 08 juni 2004 @ 15:50:
EXCUSE ME, maar je mist mijn PUNT.

Ik zal even een voorbeeld geven van wat zij (volgens mij) bedoelen (aan de hand van een stukje code)
[snip]

Nee nee, zo makkelijk heb je me niet
Kijk naar het verschil met TBS, en huiver

PHP:

<?php
   // $cnx_id is de connectie id die ergens in de code is aangemaakt
   
   $TBS = new clsTinyButStrong; 
   $TBS->LoadTemplate( 'voorbeeld.htm' ); 
   $TBS->MergeBlock( 'voorbeeld', $cnx_id, 'SELECT some, stuff FROM myTable' ); 
   $TBS->Show() ; 
?>

En het bijbehorende template:

code:

<table>
   <tr>
      <td>[voorbeeld.some;block=tr]</td>
      <td>[voorbeeld.stuff]</td>
   </tr>
   <tr> 
      <td colspan="2">[voorbeeld;block=tr;nodata]Er zijn geen resultaten.</td> 
   </tr> 
</table>

Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren.

edit:
even aangepast zodat we niet 6 km naar beneden hoeven te scrollen

[ Voor 61% gewijzigd door drm op 08-06-2004 17:21 ]

[Verwijderd]

.oisyn schreef op 08 juni 2004 @ 16:24:Anders lees je even goed, ik ging in op de reactie van GsusZ die PHPlib gebruikt. Dat jij daarvoor tbs gebruikt moet je zelf weten, maar het kan net zo goed met PHP, alleen dat was niet de discussie, ik had het over de manier waarop PHPlib templates afhandelde. Leuk dat tbs dat anders doet, maar wat heeft dat in hemelsnaam met mijn argumenten die ik gaf te maken?

Het ging mij om template engines in het algemeen

(Trouwens, wat is het voordeel van tbs tov PHP?)

Zie mijn vorige post...
(direct hier boven, maar dit vondt ik een aparte post waard.)

Sorry, maar nee. Wat is je punt nou precies Daar wordt bewezen dat je html niet vanuit je logic layer moet outputten. Doe ik ook niet, maar ik gebruik wel php. Ik heb de template files apart van de logic files, dus data en opmaak is gescheiden. Dat is de essentie van het linkje dat jij postte, niet dat je geen PHP mag gebruiken.

Oftewel, zie de laatste post van drm, daar ga ik in mee.

Ik snap je punt, maar mn laatste post laat zien waarom je tbs wil gebruiken ipv php, oa omdat de maker van tbs zelf vondt dat smarty enzo geen excuus was om het te gebruiken en dus tbs ontwikkelde...
En vandaar dat tbs ook wat afwijkt van wat je gewend bent van een template engine...

[ Voor 4% gewijzigd door Verwijderd op 08-06-2004 17:03 ]

[drm]

Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren.

Naja, op deze manier is er dus ook van geen discussie sprake, dus ik zie niet in waarom ik dan nog op je post zou reageren...

[Shadowman]

Verwijderd schreef op 08 juni 2004 @ 16:52:
[...]
Nee nee, zo makkelijk heb je me niet
Kijk naar het verschil met TBS, en huiver

PHP:

..

En het bijbehorende template:

code:

..

Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren.

offtopic:
Hoe zit het met de snelheid. Het lijkt me namelijk niet echt supersnel als een templateparser en naar de html-tags moet kijken en ook naar de eigen tags?

[Verwijderd]

drm schreef op 08 juni 2004 @ 17:20:
[...]
Naja, op deze manier is er dus ook van geen discussie sprake, dus ik zie niet in waarom ik dan nog op je post zou reageren...

Ja hallo, ik mag mijn mening toch wel hebben, dat sluit een discussie niet uit. Je kunt zelf heel goed zien dat deze code veel overzichtelijker is dan alle voorbeelden die je zelf laat zien.

En ik durf daar voor te wedden...

Bovendien is deze code te bewerken met goede wysiwyg systemen (ik zeg goede omdat de minder goede altijd hun eigen idee hebben over hoe de opmaak er uit moet zien en je dus niet altijd blokken krijgt wat je verwacht, wat dan de template engine door de war maakt )

Maar zeg nou zelf, is dit makkelijker of lastiger te overzien dan jouw voorstel met de php-template?

Shadowman schreef op 08 juni 2004 @ 17:31:

offtopic:
Hoe zit het met de snelheid. Het lijkt me namelijk niet echt supersnel als een templateparser en naar de html-tags moet kijken en ook naar de eigen tags?

Dat vindt ik niet zo offtopic, das zelfs een heel erg goed punt, zeker nadat ik al ergens geroepen had dat smarty langzaam is.

Ik heb gelezen op het tbs forum dat er niet significant snelheidsverlies is, en hij heeft het laatst weer geoptimaliseerd. Dit zal ik anders ff precies voor jullie navragen

[Verwijderd]

Verwijderd schreef op 08 juni 2004 @ 15:25:
Ik heb niet alleen met de designers te maken, ook met klanten, einde verhaal, want die kan ik niks verbieden, die kan ik alleen beperken

Hier kunnen templates een voordeel zijn (maar welke klant probeert zijn eigen website te kraken, behalve als je aan free-hosting doet?). Echter, je kan dit echter ook met PHP doen: Gewoon de templates controleren op codes\functies die gebruikt mogen worden (dit hoeft alleen bij een aanpassing van een template gedaan te worden).

Verwijderd schreef op 08 juni 2004 @ 15:25:
LEZEN! het wordt vergeleken met PHP, of snap je dat niet?

Alleen jammer dat jij niet begrijpt dat je een template-engine ook in native PHP kan doen en de link voegt dus niets toe aan jouw stelling dat template-engines met eigen bedachte template-tags beter zijn dan template-engines met native PHP.

Verwijderd schreef op 08 juni 2004 @ 16:12:
Ik zie een designer nog geen XSLT leren om de volgorde van de output te veranderen? De kans dat hij dat wil is uberhaupt al gering (het enige wat je ooit zou willen veranderen aan de volgorde is dat een user kan bepalen op bijvoorbeeld een categorie/naam/tijd te sorteren, en aangezien al mijn gegevens toch al mooi in de database staan hebben we daar SQL voor uitgevonden). Oftewel de enige die dan XSLT kan hanteren ben jij maar het grappige is dat je het opmaken van de data net zo goed in PHP kan doen.

Dit ben ik niet met je eens, XSLT is o.a. bedoeld voor de designer! Er zijn genoeg programma's om van XML het resultaat te maken wat de designer wil dmv sleur-en-pleur-methode ('MS-methode'). De XSLT wordt dan automatisch aangemaakt (vergelijkbaar met Dreamweaver MX4 met CSS).

Verwijderd schreef op 08 juni 2004 @ 16:52:
Kijk naar het verschil met TBS, en huiver

Ik huiver inderdaad... en wel om het volgende:
1. Ik moet een template taal leren (IMHO is TBS dan geen simpele), waar ik niet veel aan heb. Leer ik wat PHP-tags, zelfde moeite, dan ken ik in ieder geval de basis van PHP (en kan daar evt. verder in verdiepen).
2. Een SQL-string in een template-engine? Dit is voor mij een punt om de programmeurs van TBS te wantrouwen qua programmeerkennis. Een goede programmeur mixt niet de DataAccesslayer en PresentationLayer door elkaar.
3. En nog steeds kan ik hetzelfde bereiken met een template-engine op basis van native PHP *zucht*.
Een voorbeeld:

PHP:

<?php
   // $cnx_id is de connectie id die ergens in de code is aangemaakt
   
   $TPL = new PhpTemplate; 
   $TPL->LoadTemplate( 'voorbeeld.htm' ); 
   $TPL->MergeBlock( 'rows', $cnx_id, 'SELECT some, stuff FROM myTable' ); 
   $TPL->Show() ; 
?>

En de bijbehorende template:

code:

<table>
  <?if(empty($rows)):?>
   <tr> 
      <td colspan="2">Er zijn geen resultaten.</td> 
   </tr>
  <?else:?>
  <?foreach($rows as $row):?>
  <tr>
      <td><?=$row['some']?></td>
      <td><?=$row['stuff']?></td>
   </tr>
  <?endforeach;?>
  <?endif:?>
</table>

A. Dit vind ik veel overzichterlijker. Ik moest de manual van TBS er bij pakken om te begrijpen dat hij de HTML-tags er omheen loopt.
B. Om de overhead van TBS te accepeteren heb ik toch echt betere argumenten nodig...

[ Voor 12% gewijzigd door Verwijderd op 08-06-2004 20:33 ]

[djluc]

Verwijderd schreef op 08 juni 2004 @ 20:17:[...]
Dat vindt ik niet zo offtopic, das zelfs een heel erg goed punt, zeker nadat ik al ergens geroepen had dat smarty langzaam is.

Ik heb gelezen op het tbs forum dat er niet significant snelheidsverlies is, en hij heeft het laatst weer geoptimaliseerd. Dit zal ik anders ff precies voor jullie navragen

Over de rest valt nog wel te discussiëren maar zou je wat je hier zegt ook even kunnen onderbouwen met een beetje objectieve argumenten? Denk hierbij aan snelheidsmetingen e.d. want alleen roepen dat Smarty traag is betekend niet dat het ook werkelijk zo is. Verder lijkt de aanpak van tbs mij niet echt optimaal, maargoed daar heb ik ook geen cijfertjes voor dus dat ga ik ook niet roepen.

[Mac_Cain13]

Verwijderd schreef op 08 juni 2004 @ 20:17:
[...]
Ja hallo, ik mag mijn mening toch wel hebben, dat sluit een discussie niet uit. Je kunt zelf heel goed zien dat deze code veel overzichtelijker is dan alle voorbeelden die je zelf laat zien.
[...]

Ik volg deze discussie nou al de hele tijd. Had helaas geen nuttige inbreng dus hield mij tot dusver stil, maar ik kan heel goed begrijpen wat drm in zijn post bedoelt.

Uiteraard mag jij je mening hebben. Graag zelf en laat hem ook horen, maar het 'probleem' is dat jij je post vaak afsluit met een opmerking zoals 'Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren.'.
Dat komt over alsof iemand die het niet met jou eens is zijn mening ook niet meer hoeft te geven, want jij hebt toch gelijk. Als ik immers laat zien dat er geen voordeel is wil je niet meer luisteren en zeg je dat ik het voordeel negeer.

Dat is wat de discussie (volgens mij) hier opbreekt, als je nou gewoon je mening post zonder erbij te zeggen 'Je doet het er om heh?' kom je een stuk vriendelijker over. Dat maakt een discussie een stuk gezelliger en mensen voelen zich dan ook niet zo aangevallen.
Vooral die opmerking 'of snap je dat niet?' vond ik erg ongepast.

Goed dat moest ik ff kwijt, srry voor het offtopic geblaat zal er snel mee stoppen.
[/off-topic geblaat over discussie dingen]

Overgens wil ik dan nu meteen even kwijt dat ik het tot nu toe een zeer interessante discussie vond. Ik heb er iig veel van geleerd over de voors en tegens van een template systeem enz.

edit:
Ik sluit mij btw ook helemaal aan bij dat stukkie over objectieve argumenten van djluc hierboven. Alleen mijn verhaal werd al te lang.

[ Voor 9% gewijzigd door Mac_Cain13 op 08-06-2004 20:45 ]

[Verwijderd]

Verwijderd schreef op 08 juni 2004 @ 20:25:
Ik huiver inderdaad... en wel om het volgende:
1. Ik moet een template taal leren (IMHO is TBS dan geen simpele), waar ik niet veel aan heb. Leer ik wat PHP-tags, zelfde moeite, dan ken ik in ieder geval de basis van PHP (en kan daar evt. verder in verdiepen).
2. Een SQL-string in een template-engine? Dit is voor mij een punt om de programmeurs van TBS te wantrouwen qua programmeerkennis. Een goede programmeur mixt niet de DataAccesslayer en PresentationLayer door elkaar.
3. En nog steeds kan ik hetzelfde bereiken met een template-engine op basis van native PHP *zucht*.
Een voorbeeld:

PHP:

<?php
   // $cnx_id is de connectie id die ergens in de code is aangemaakt
   
   $TPL = new PhpTemplate; 
   $TPL->LoadTemplate( 'voorbeeld.htm' ); 
   $TPL->MergeBlock( 'rows', $cnx_id, 'SELECT some, stuff FROM myTable' ); 
   $TPL->Show() ; 
?>

En de bijbehorende template:

code:

<table>
  <?if(empty($rows)):?>
   <tr> 
      <td colspan="2">Er zijn geen resultaten.</td> 
   </tr>
  <?else:?>
  <?foreach($rows as $row):?>
  <tr>
      <td><?=$row['some']?></td>
      <td><?=$row['stuff']?></td>
   </tr>
  <?endforeach;?>
  <?endif:?>
</table>

A. Dit vind ik veel overzichterlijker. Ik moest de manual van TBS er bij pakken om te begrijpen dat hij de HTML-tags er omheen loopt.
B. Om de overhead van TBS te accepeteren heb ik toch echt betere argumenten nodig...

ff zien, puntjes schieten

1: Ach ja, leergierigheid, maar dit is niet echt een argument om het niet te gebruiken...
2: Die SQL string gaat gewoon letterlijk naar je zelf gedefineerde mysql (of andere ondersteunde systemen) toe, en dat mag zelfs een db object zijn... Er gebeurd vrij weinig mee, tbs probeert de string niet te begrijpen...
3: Ik kan ook lopend naar mn werk toe, maar de trein is net wat fijner als het regend, bovendien is het 45 km lopen... Dus wat bedoel je nou? Dan kun je net zo goed afschaffen dat php nog objectgeorienteerd kan werken, want al die fubncties kun je ook native php oplossen. Je punt mist mij omdat hier juist de discussie over gaat en om dan je standpunt als argument te gebruiken??

A: Dus je hebt de manual er bij gepakt, je hebt gelezen wat block=tr doet, en nu weet je het, de volgende keer snap je het zonder manual... Zo veel meer hoef je voor tbs niet te leren. En hoe precies heb je PHP gelee... hey, weer dat woord
B: Overhead...

Ach, je zegt dat je jouw code overzichtelijk vindt op basis van het feit dat je PHP al geleerd hebt, terwijl TBS juist overzichtelijker is, gebaseerd op het oogpunt van "rotzooi" rond je html code...

[Shadowman]

Verwijderd schreef op 08 juni 2004 @ 21:08:
[...]
ff zien, puntjes schieten

1: Ach ja, leergierigheid, maar dit is niet echt een argument om het niet te gebruiken...
2: Die SQL string gaat gewoon letterlijk naar je zelf gedefineerde mysql (of andere ondersteunde systemen) toe, en dat mag zelfs een db object zijn... Er gebeurd vrij weinig mee, tbs probeert de string niet te begrijpen...

Dat maakt nog niet het verschil tussen die layers. tbs gaat toch de data zelf ophalen terwijl jij eigenlijk die datainput moet verzorgen en eventueel nog wat data verwerken.

3: Ik kan ook lopend naar mn werk toe, maar de trein is net wat fijner als het regend, bovendien is het 45 km lopen... Dus wat bedoel je nou? Dan kun je net zo goed afschaffen dat php nog objectgeorienteerd kan werken, want al die fubncties kun je ook native php oplossen. Je punt mist mij omdat hier juist de discussie over gaat en om dan je standpunt als argument te gebruiken??

Geef eens een goed argument zeg... Ik vind dit namelijk overkomen dat TBS "Alles" is en php "(bijna) niets" is.

A: Dus je hebt de manual er bij gepakt, je hebt gelezen wat block=tr doet, en nu weet je het, de volgende keer snap je het zonder manual... Zo veel meer hoef je voor tbs niet te leren. En hoe precies heb je PHP gelee... hey, weer dat woord
B: Overhead...

Ach, je zegt dat je jouw code overzichtelijk vindt op basis van het feit dat je PHP al geleerd hebt, terwijl TBS juist overzichtelijker is, gebaseerd op het oogpunt van "rotzooi" rond je html code...

Ik programmeer altijd zodanig dat ik de overzichtelijkheid in de HTML niet kwijt raak. Dit is gewoon een manier van programmeren die standaard moet zijn. Verder kan je met TBS er ook een rotzooi van maken.

offtopic:
Nog ff nieuwsgierig: Kun je met TBS er ook voor zorgen dat de bytes die worden verstuurd naar de client zo miniem mogelijk is? (Enters eruit halen en andere code die toch niet zal worden verwerkt door de browser)

[Verwijderd]

Mac_Cain13 schreef op 08 juni 2004 @ 20:42:
...
Uiteraard mag jij je mening hebben. Graag zelf en laat hem ook horen, maar het 'probleem' is dat jij je post vaak afsluit met een opmerking zoals 'Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren.'.
Dat komt over alsof iemand die het niet met jou eens is zijn mening ook niet meer hoeft te geven, want jij hebt toch gelijk. Als ik immers laat zien dat er geen voordeel is wil je niet meer luisteren en zeg je dat ik het voordeel negeer.

Dat is wat de discussie (volgens mij) hier opbreekt, als je nou gewoon je mening post zonder erbij te zeggen 'Je doet het er om heh?' kom je een stuk vriendelijker over. Dat maakt een discussie een stuk gezelliger en mensen voelen zich dan ook niet zo aangevallen.
Vooral die opmerking 'of snap je dat niet?' vond ik erg ongepast.

Goed dat moest ik ff kwijt, srry voor het offtopic geblaat zal er snel mee stoppen.
[/off-topic geblaat over discussie dingen]

Overgens wil ik dan nu meteen even kwijt dat ik het tot nu toe een zeer interessante discussie vond. Ik heb er iig veel van geleerd over de voors en tegens van een template systeem enz.

edit:
Ik sluit mij btw ook helemaal aan bij dat stukkie over objectieve argumenten van djluc hierboven. Alleen mijn verhaal werd al te lang.

Ik werk aan de objectieve argumenten, maar de argumenten die objectief zijn hebben alleen betrekking op "welke engine" niet of je er eentje moet gebruiken. Want PHP zie ik nog steeds niet als template engine. Een template engine zie ik als een stukje code (wellicht in de vorm van een object) dat die template functies verricht. PHP als template engine gebruiken is gewoon een slimme toepassing van een anders geschreven stukje PHP.

Ik hoop dat jij (zoals je zegt nog lerende over voors en tegens van template engines) misschien een idee kunt geven van wat jij zo overzichtelijker vindt tussen de 3/4 geboden alternatieve voor hetzelfde stukje code (als je ook de moeite neemt om de syntax te snappen, en niet zegt zoals iemand hierboven dat je iets minder overzichtelijk vindt omdat je eerst de manual moest lezen de eerste keer)

Mijzelf lijkt toch schonere code en minder mixen van gelijksoortige tags (html <> php <??>) leesbaarheid bevorderd.
(Context highlighting in text editors zoals textpad (die gebruik ik dus) even buiten beschouwing gelaten, want die kun je met een paar comandos aanpassen om alles te doen wat je zelf wilt)

en dan minder gerelateerd aan het onderwerp:
Ik erger mij ook aan de reactie van een mod die eerst vraagt voor een beter argument om een template engine te gebruiken eventueel ondersteund met code. En als hij het krijgt, met mijn mening , er dan vervolgens niet op in gaat omdat ik mijn mening niet mag posten (zoals jij ook zegt)

Als hij er nou alsnog maar op in gaat, want ik kan mij niet aan de mening ontrekken dat hij de syntax in zowel het php als in het html gedeelte overzichtelijker zou moeten vinden met gebruik van tbs....

[Verwijderd]

Shadowman schreef op 08 juni 2004 @ 21:21:
[...]

Dat maakt nog niet het verschil tussen die layers. tbs gaat toch de data zelf ophalen terwijl jij eigenlijk die datainput moet verzorgen en eventueel nog wat data verwerken.

Ach, gelukkig mag je bij tbs ook een array als input geven, dus die optie staat je vrij, het is alleen dat ik een overzichtelijke syntax wilde geven die hetzelfde bewerkstelligd als het gevraagde

[...]

Geef eens een goed argument zeg... Ik vind dit namelijk overkomen dat TBS "Alles" is en php "(bijna) niets" is.

RémyvD zegt dat php het ook kan. Dat is niet wat je noemt het argument der argumenten bovendien is mijn argument dat meer wegen naar Rome leiden en dat je zelf ook altijd kiest voor wat het makkelijkste of beste is, maar heb je (of RémyvD) tbs (en niet een andere engine) al eens gebruikt? zo nee, dan weet je ook niet hoeveel makkelijker het is en hoe snel je went aan de syntax (want alle begin is lastig geef ik toe;))

[...]

Ik programmeer altijd zodanig dat ik de overzichtelijkheid in de HTML niet kwijt raak. Dit is gewoon een manier van programmeren die standaard moet zijn. Verder kan je met TBS er ook een rotzooi van maken.

offtopic:
Nog ff nieuwsgierig: Kun je met TBS er ook voor zorgen dat de bytes die worden verstuurd naar de client zo miniem mogelijk is? (Enters eruit halen en andere code die toch niet zal worden verwerkt door de browser)

Vast Enne, zoniet, ik ga het meteen voorstellen bij de maker, die staat te springen als hij nieuwe suggesties krijgt, ik heb al heel wat functies aangedragen voor implementatie, zoals een verbeterde navigatiebalk bij multipaging, maar goed, das offtopic

edit:
overigens mijn excuses voor alweer twee posts na elkaar, maar dit leek me beter in dit geval omdat het nogal langdradig werd in 1 reply, bovendien, ik zag deze reactie pas nadat de andere gepost werd, en om dan die reply te gaan editten naar zoiets langs

[ Voor 10% gewijzigd door Verwijderd op 08-06-2004 21:53 ]

[djluc]

Ik werk aan de objectieve argumenten, maar de argumenten die objectief zijn hebben alleen betrekking op "welke engine" niet of je er eentje moet gebruiken. Want PHP zie ik nog steeds niet als template engine. Een template engine zie ik als een stukje code (wellicht in de vorm van een object) dat die template functies verricht. PHP als template engine gebruiken is gewoon een slimme toepassing van een anders geschreven stukje PHP.

Je stelt je alweer niet open aangezien je PHP toch niet wilt zien als een template engine. Daar kunnen we dus nog lang over doorzeuren. Lees voor de gein dit eens: http://www.php.net/manual/nl/introduction.php PHP zoals PHP bedoeld is.

[Shadowman]

Verwijderd schreef op 08 juni 2004 @ 21:48:
[...]
Ach, gelukkig mag je bij tbs ook een array als input geven, dus die optie staat je vrij, het is alleen dat ik een overzichtelijke syntax wilde geven die hetzelfde bewerkstelligd als het gevraagde

Met het arrays doorgeven heb ik geen probleem . Ik vind het eerder apart dat je gelijk rechtstreeks een query kunt uitvoeren en laten verwerken.

[...]
Jij zegt dat php het ook kan. Dat is niet wat je noemt het argument der argumenten bovendien is mijn argument dat meer wegen naar Rome leiden en dat je zelf ook altijd kiest voor wat het makkelijkste of beste is, maar heb je tbs (en niet een andere engine) al eens gebruikt? zo nee, dan weet je ook niet hoeveel makkelijker het is en hoe snel je went aan de syntax (want alle begin is lastig geef ik toe;))

Ik heb in geen argumenten gegeven. Ik heb enkel gevraagd of je een beter argument wist. (en ik heb ook half zitten te lezen , alleen het eerste gedeelte).

Ik ben eerlijk gezegd nog niet echt met templates bezig geweest. Dat komt ook meer omdat het achterliggende me meer interesseert en ik weet ook dat je je aan syntax altijd moet wennen als je een keer aan een iets andere type syntax begint. (Redelijk vergelijkbaar met als je begint aan een andere taal ).

[megamuch]

Ik volg deze discussie ook al een tijdje. Ik ben zelf ook wel een voorstander van een template systeem. PHP code samen met HTML code gaat op een gegeven moment zeer irritant werken. Dat was in ieder geval mijn ervaring.

Overigens vind ik de syntax van Tinybutstrong zeer vreemd. Niet iets wat ik zelf nou als echt makkelijk interpreteer. Zelf gebruik ik daarvoor TemplatePower.

Simpele template parser die absoluut niet opkan tegen de performance van Smarty en Tbs maar volledig voldoet voor de gemiddelde website.

om een voorbeeldje te geven

PHP:

// class aanroepen

include_once( "includes/class.TemplatePower.inc.php" );
$tpl = new TemplatePower( "tpl/articles.tpl" );

// hier wat includes van andere templates om de volledige pagina te genereren

$tpl->assignInclude( "header", "tpl/header.tpl" );
$tpl->assignInclude( "footer", "tpl/footer.tpl" );
$tpl->assignInclude( "poll", "includes/poll.php" );
$tpl->assignInclude( "sponsors", "includes/sponsor.php" );
$tpl->assignInclude( "today_tips", "includes/today_tips.php" );
$tpl->assignInclude( "shoutbox", "includes/shoutbox.php" );

// na includen moeten we prepare aanroepen
$tpl->prepare();

// hier gaan we wat variabelen vullen
$tpl->assign( "title", $articlerow['title'] );
$tpl->assign( "poster", $articlerow['poster'] );
$tpl->assign( "dateadded", $articlerow['dateadded'] );

//Hier gaan we nog wat blokken vullen enzo
....

// hier gaan we alles richting browser sturen
$tpl->printToScreen();

bij behorende template :

HTML:

    <table>
         <tr>
            <td class="title">{title}</td>
        </tr>
        <tr>
            <td class="bron">Posted by {poster} - {dateadded}</td>
        </tr>
        <tr>
            <td class="articlebig">{article}</td>
        </tr>
    </table>

Persoonlijk vind ik dit een stuk overzichtelijker tov php en html door elkaar. Zeker met pagina's waarbij je volledige stukken html moet uit'echo'en. Dat zie ik dan liever in een apart TPL bestand.

Het heeft meer te maken met wat je zelf makkelijker vind. Ik heb liever mijn loopjes niet in de template zelf (zoals met smarty en tbs mogelijk is), maar gescheiden tussen templateblok en php.

Daarnaast dwingt het gebruik van TemplatePower mij om geen HTML in de php code te stoppen. En dat maakt mijn documentjes toch eenvoudiger te lezen voor collega's en voor mijzelf als ik na 3 maanden weer is in oude code duik.

[Verwijderd]

Shadowman schreef op 08 juni 2004 @ 22:03:
Ik ben eerlijk gezegd nog niet echt met templates bezig geweest. Dat komt ook meer omdat het achterliggende me meer interesseert en ik weet ook dat je je aan syntax altijd moet wennen als je een keer aan een iets andere type syntax begint. (Redelijk vergelijkbaar met als je begint aan een andere taal ).

Mooi, misschien kun jij dan ook je mening geven over 1 van mijn redenen om tbs te gebruiken, namelijk de overzichtelijkheid die zo op het oog toch grote is bij het tbs voorbeeld dat ik aan draag...

Maar goed, wat vindt jij?

djluc schreef op 08 juni 2004 @ 22:02:
[...]
Je stelt je alweer niet open aangezien je PHP toch niet wilt zien als een template engine. Daar kunnen we dus nog lang over doorzeuren. Lees voor de gein dit eens: http://www.php.net/manual/nl/introduction.php PHP zoals PHP bedoeld is.

Hahaha, das wel een typisch voorbeeld hoor

Want natuurlijk is PHP wel een beetje bedoelt om HTML weer te geven maar dan dynamisch maar we hebben het nu over de manier waarop.

Dit voorbeeld dat je geeft is overduidelijk bedoelt voor mensen die HTML al kennen, want anders begrijp ik geen snars van dat hele eerste voorbeeld. Bovendien wordt hier uitgelegd waarom je PHP zou gebruiken in je webpagina's (als HTML gebruiker). Dus dit voorbeeld is wat te zeer op een doelgroep toegesplitst

"PHP is vooral bedoeld als server-side scripting taal" staat op de volgende pagina, en ik zie hier dan eigenlijk weer nergens staan dat het voor HTML bedoelt is (want ook al zei ik net 'natuurlijk wel' eigenlijk is het totaal niet HTML gebonden), en er staat gewoon dat je er server side code mee kunt uitvoeren.

Dus dat gelezen zie ik PHP nog steeds niet als een template engine

[Verwijderd]

megamuch schreef op 08 juni 2004 @ 22:08:
Ik volg deze discussie ook al een tijdje. Ik ben zelf ook wel een voorstander van een template systeem. PHP code samen met HTML code gaat op een gegeven moment zeer irritant werken. Dat was in ieder geval mijn ervaring.

Overigens vind ik de syntax van Tinybutstrong zeer vreemd. Niet iets wat ik zelf nou als echt makkelijk interpreteer. Zelf gebruik ik daarvoor TemplatePower.

Nou, vreemd..
Ikzelf vindt het best ingenieus om html tags als delemiters te gebruiken (ook kan je tbs delemiters toevoegen mochten html tags niet goed uitkomen (1 keer gebeurd om javascript te doen)
Het is iets dat je 1 keer moet lezen, en dan weet je het en is het toch wel wat overzichtelijker. Aangezien de zgn php-template met dubbele delimeters werkt is dit onoverzichtelijker imo. Maar ook onpraktischer, je moet steeds dubbelop aangeven waar je begint en eindigt. Bij tbs hoef je dit alleen te doen als de HTML tags niet volstaan (wat zoals gezegd nooit zou gebeuren (aangezien HTML in principe goed gevormd moet zijn))

Persoonlijk vind ik dit een stuk overzichtelijker tov php en html door elkaar. Zeker met pagina's waarbij je volledige stukken html moet uit'echo'en. Dat zie ik dan liever in een apart TPL bestand.

Het heeft meer te maken met wat je zelf makkelijker vind. Ik heb liever mijn loopjes niet in de template zelf (zoals met smarty en tbs mogelijk is), maar gescheiden tussen templateblok en php.

Daarnaast dwingt het gebruik van TemplatePower mij om geen HTML in de php code te stoppen. En dat maakt mijn documentjes toch eenvoudiger te lezen voor collega's en voor mijzelf als ik na 3 maanden weer is in oude code duik.

Mee eens, met uitzondering van het loopje in de tbs template omdat ze daar juist niet in zitten (dan zou php weer een stapje dichterbij aan "goed alternatief -voor mij-" komen namelijk) de loop is namelijk de MergeBlock functie...

Maar goed, das misschien een kwestie van opvatten...

[Shadowman]

Verwijderd schreef op 08 juni 2004 @ 22:24:
[...]
Mooi, misschien kun jij dan ook je mening geven over 1 van mijn redenen om tbs te gebruiken, namelijk de overzichtelijkheid die zo op het oog toch grote is bij het tbs voorbeeld dat ik aan draag...

Maar goed, wat vindt jij?

Het ligt vooral ook aan de manier hoe je programmeert. Ik vind het makkelijker als begin en eindtags niet ook deel uitmaken van de output.

En ook een nadeel aan tbs vind ik het nesten van de html. Dat komt in mijn ogen ook niet echt de overzichtelijkheid ten goede.

En dan bedoel ik vooral dit soort stukjes :

HTML:

<DIV>
  <DIV>
    {tpldata}
  </DIV>
  <DIV>
    {tpldata}
  </DIV>
</DIV>

[ Voor 4% gewijzigd door Shadowman op 08-06-2004 22:56 ]

[Verwijderd]

Shadowman schreef op 08 juni 2004 @ 22:56:
[...]

Het ligt vooral ook aan de manier hoe je programmeert. Ik vind het makkelijker als begin en eindtags niet ook deel uitmaken van de output.

En ook een nadeel aan tbs vind ik het nesten van de html. Dat komt in mijn ogen ook niet echt de overzichtelijkheid ten goede.

En dan bedoel ik vooral dit soort stukjes :

HTML:

<DIV>
  <DIV>
    {tpldata}
  </DIV>
  <DIV>
    {tpldata}
  </DIV>
</DIV>

Zeldzaam als ze zijn in mn html
Komt idd voor, maar daar kun je om te beginnen de standaard template engine oplossing voor gebruiken. Of, je gebruikt een variabele in tbs die eenduidig aanwijst welke div je bedoelt. Maar de tweede methode draagt dan niet bij voor de leesbaarheid met het blote oog.

Trouwens, ik kan met tbs (en dit valt me nu pas in) ook stukjes template dupliceren op een ietwat ongewone manier door dat een blok dat zich binnen een groter block bevindt als tweede te mergen. Ik weet niet goed hoe ik dit het beste kan omschrijven, ik zal morgen ofzo (als ik tijd heb ) een voorbeeldje schrijven, maar ik weet voor de optie die ik bedoel geen goed php alternatief te bedenken, en als je alternatieven bedenkt zijn het minder mooie include instructies.....
maja, dat zie je straks dan wel weer...

[Michali]

Ik gebruik tegenwoordig ook XSLT als template taal en ik moet zeggen dat dat erg lekker werkt. Waar ik wel nog wel eens moeite mee heb is hoe abstract ik de data moet maken die ik aanlever (in XML formaat dus). Ik meestal toch wel uit op precies de data die ik in de HTML attributen etc. zou invullen maar zonder de echte details erbij. Samen met een CSS sheetje erbij is het erg goed te tweaken achteraf zonder dat ik ook maar 1 regel php hoef aan te passen. Werkt erg goed dus.

[Verwijderd]

Verwijderd schreef op 08 juni 2004 @ 21:08:
1: Ach ja, leergierigheid, maar dit is niet echt een argument om het niet te gebruiken...

??? Mijn argument is dat ik iets moet leren, waarbij ik de kueze heb uit een aantal dingen. Ik leer dan liever iets wat ik voor andere projecten ook kan gebruiken. Ik heb dan de keuze uit een TBS-taal of PHP. Met TBS kan ik alleen gebruiken voor jouw code en nergens anders (aangezien elke programmeur weer zijn eigen template-taal heeft). PHP is bij elke (PHP)programmeur hetzelfde, dus kan ik dit elke keer toepassen.

En als ik kijk naar wie templates aanpassen (designer of de webbeheerder) dan vind ik als bedrijf het juist een voordeel dat deze mensen een beetje PHP kennen\leren.

Een ander voorbeeld is XSLT ipv TBS. Als ik XSLT leer, dan kan ik dit ook bij andere projecten toepassen (eigenlijk is XSLT dan nog beter dan PHP, omdat ik deze kennis overal kan inzetten).

Verwijderd schreef op 08 juni 2004 @ 21:08:
2: Die SQL string gaat gewoon letterlijk naar je zelf gedefineerde mysql (of andere ondersteunde systemen) toe, en dat mag zelfs een db object zijn... Er gebeurd vrij weinig mee, tbs probeert de string niet te begrijpen...

Ja, dus de DataAccesLayer is gemixt met je PresentatieLayer.
Waarom zit er een DbConnection(Object) in je TemplateObject? Waarom stuurt een TemplateObject een SQLstring naar een DBConnection(Object)? Dit is niet de taak van een TemplateObject!

Als TBS beter ontworpen was dan had het bijv. een Iterator interface meegeleverd, waarbij de code zoiets zo worden:

code:

// layer1
$DbConnection =& new MySqlConnection('user', 'password');
$DbConnection->connect('db', 'table');
$ResultSet = & $DbConnection->query('SELECT some, stuff FROM myTable');
//Layer2
$ResultsetIterator =& new ResultsetIterator($Resultset);
//layer3
$TBS =& new clsTinyButStrong;
$TBS->MergeBlock('rows', $ResultsetIterator);

En met arrays heb ik ook geen probleem (al zou ik zelf dan een ArrayIterator gebruiken), maar het feit dat TBS een SQLstring en DBConnection gebruikt is een kenmerk van een slecht ontwerp.

Verwijderd schreef op 08 juni 2004 @ 21:08:
3: Ik kan ook lopend naar mn werk toe, maar de trein is net wat fijner als het regend, bovendien is het 45 km lopen... Dus wat bedoel je nou? [...]
Je punt mist mij omdat hier juist de discussie over gaat en om dan je standpunt als argument te gebruiken??

Verwijderd schreef op 08 juni 2004 @ 21:48:
RémyvD zegt dat php het ook kan. Dat is niet wat je noemt het argument der argumenten bovendien is mijn argument dat meer wegen naar Rome leiden en dat je zelf ook altijd kiest voor wat het makkelijkste of beste is,

Ik sluit mij hier betreft aan bij Shadowman. De vergelijking lopen vs. trein is in geen verhouding tot php vs. template-engine.

Als ik zeg dat ik met PHP hetzelfde kan bereiken, dan dien je dus over zeer goede argumenten te beschikken om een extra laag te creeeren! Ik heb de keuze uit een templates gebaseerd op native PHP (de PHP-engine als parser gebruikt!) of bijv. TBS die zijn templates parst met een eigen geschreven template-engine (boven op PHP)!

Geef mij dan goede argumenten om bijv. TBS te gebruiken! Je geeft mij argumenten en dan zeg ik vervolgens:'dat kan ook in PHP', dus is het geen goed argument. Alleen dat je iets mooier vindt (of denkt dat dit mooier is voor een designer), is geen goed argument, aangezien dit vrij persoonlijk is (en ik betwijfel of een designer PHP-tags 'eng' vindt.

Het enige argument wat een reden is om een template-engine met custom-tags te gebruiken is de echte gedwongen scheiding tussen je PresentatieLayer en BusinessLayer (echter TBS is gefaald hierin door bovenstaande uitleg)

Zal ik je ook even nadelen geven om PHP-tags te gebruiken (handje helpen kan geen kwaad )?
- het vraagt om disipline om niet ander functies van PHP te gebruiken (als hierop niet wordt gecontroleerd). Je kan dan in de verleiding raken om je PresentationLayer met je BusinessLayer te mixen;
- het is niet valid HTML (maar dat is met custom-tags ook niet zo, dus niet echt een nadeel);
- als ik of het bedrijf besluit een andere server-side technologie te gebruiken, dan zijn mijn PHP-templates, waardeloos.

Verwijderd schreef op 08 juni 2004 @ 21:08:Dan kun je net zo goed afschaffen dat php nog objectgeorienteerd kan werken, want al die fubncties kun je ook native php oplossen.

Wat is dit nou voor argument??? De voordelen van OO zijn makkelijk te benoemen (in tegenstelling tot een template-engine...). En ik beschouw OO gewoon als native PHP (het wordt toch door PHP-engine geparsed?) Ook beschouw ik Objecten niet als simpele functionwrappers....

Verwijderd schreef op 08 juni 2004 @ 21:08:
A: Dus je hebt de manual er bij gepakt, je hebt gelezen wat block=tr doet, en nu weet je het, de volgende keer snap je het zonder manual... Zo veel meer hoef je voor tbs niet te leren. En hoe precies heb je PHP gelee... hey, weer dat woord [/qoute]
[...]
Ach, je zegt dat je jouw code overzichtelijk vindt op basis van het feit dat je PHP al geleerd hebt, terwijl TBS juist overzichtelijker is, gebaseerd op het oogpunt van "rotzooi" rond je html code...

Ik vind het overzichtelijk, omdat ik de PHP-template leesbaar is, ondanks dat ik niet de syntax van PHP ken: Het is gewoon duidelijk leesbaar Engels. Óók vind ik het logischer als ik iets loop, dat ik dit zich in een loop-tag bevindt, ipv dat die dingen om de loop-tag heen zitten (maar dit vind jij weer overzichterlijker, dus is ook een persoonlijke mening).

Verwijderd schreef op 08 juni 2004 @ 21:48:
maar heb je (of RémyvD) tbs (en niet een andere engine) al eens gebruikt? zo nee, dan weet je ook niet hoeveel makkelijker het is en hoe snel je went aan de syntax (want alle begin is lastig geef ik toe;))

Alle templatesystemen lijken allemaal op elkaar (en ik heb er verscheidene gebruikt). Ik zie in TBS niet zoveel verschil met andere templates (eerder redenen om het juist niet te gebruiken).

Verwijderd schreef op 08 juni 2004 @ 21:48:zoals een verbeterde navigatiebalk bij multipaging...

Nog zoiets, ik vind dat een navigatiebalk niet in de core templateClass hoort. Misschien als extra Class erbij.

Verwijderd schreef op 08 juni 2004 @ 22:24:
"PHP is vooral bedoeld als server-side scripting taal" staat op de volgende pagina, en ik zie hier dan eigenlijk weer nergens staan dat het voor HTML bedoelt is (want ook al zei ik net 'natuurlijk wel' eigenlijk is het totaal niet HTML gebonden), en er staat gewoon dat je er server side code mee kunt uitvoeren.

Dus dat gelezen zie ik PHP nog steeds niet als een template engine

PHP is ontstaan als template-engine om templates te parsen... (dat er in de loop der jaren het één en ander is toegevoegd doet hier niet aan af)

[ Voor 3% gewijzigd door Verwijderd op 08-06-2004 23:50 ]

[megamuch]

Verwijderd schreef op 08 juni 2004 @ 22:34:

Mee eens, met uitzondering van het loopje in de tbs template omdat ze daar juist niet in zitten (dan zou php weer een stapje dichterbij aan "goed alternatief -voor mij-" komen namelijk) de loop is namelijk de MergeBlock functie...

Maar goed, das misschien een kwestie van opvatten...

Hmm als ik bijvoorbeeld een select box moet vullen met data uit een DB doe ik dat als volgt:

PHP:

//query waar we alle stijlen gaan ophalen enzo hierboven.. niet relevant
// het result komt in $muziekresult 

    for ($i=0; $i < $muziekcnt; $i++)
        {
        $muziekrow = mysql_fetch_assoc($muziekresult);
        $tpl->newBlock( "clubs_music_select_block" );
        $tpl->assign( "id", $muziekrow['id'] );
        $tpl->assign( "music_omschrijving", $muziekrow['omschrijving'] );
        }

De template:

HTML:

<select name="style">
<!-- START BLOCK : clubs_music_select_block -->
<option value="{id}">{music_omschrijving}</option>
<!-- END BLOCK : clubs_music_select_block -->        
</select>

Zo'n loopje wil ik dus niet in m'n template hebben. Dat hoort daar imho niet thuis. Kan jij me uitleggen waarom het wel in m'n template zou moeten?

[Verwijderd]

megamuch schreef op 09 juni 2004 @ 01:25:
[...]


Hmm als ik bijvoorbeeld een select box moet vullen met data uit een DB doe ik dat als volgt:

PHP:

//query waar we alle stijlen gaan ophalen enzo hierboven.. niet relevant
// het result komt in $muziekresult 

    for ($i=0; $i < $muziekcnt; $i++)
        {
        $muziekrow = mysql_fetch_assoc($muziekresult);
        $tpl->newBlock( "clubs_music_select_block" );
        $tpl->assign( "id", $muziekrow['id'] );
        $tpl->assign( "music_omschrijving", $muziekrow['omschrijving'] );
        }

De template:

HTML:

<select name="style">
<!-- START BLOCK : clubs_music_select_block -->
<option value="{id}">{music_omschrijving}</option>
<!-- END BLOCK : clubs_music_select_block -->        
</select>

Zo'n loopje wil ik dus niet in m'n template hebben. Dat hoort daar imho niet thuis. Kan jij me uitleggen waarom het wel in m'n template zou moeten?

Ik kan niet zeggen dat de tbs syntax nou zo veel verschilt, bovendien geven die start block en end block hetzelfde aan als block=option + music_select. (ik heb dat commentaar ff laten staan...)

MergeBlock in tbs kan meerdere rijen doen (3d array), maar kan ook gewoon een semi 2 dimensionaal array mergen, er staat nergens dat ik ga loopen....
(maar ok, mergeblock is er voor bedoeld, geef ik toe, maar t hoeft niet)

maar in tbs gaat het dus zo:

PHP:

   $tpl->LoadTemplate( "clubs_music_select_block.html" );
   $tpl->MergeBlock( "music_select", $connectie_id, $query );

De template:

HTML:

<select name="style">
<!-- START BLOCK : clubs_music_select_block -->
<option value="{music_select.id;block=option}">{music_select.music_omschrijving}</option>
<!-- END BLOCK : clubs_music_select_block -->        
</select>

[MisterData]

Als je XSLT overigens wil gebruiken als template-engine, dan kun je (delen van) deze class gebruiken. Ik gebruik 'em zelf ook, en het werkt erg lekker (voordeel is dat je eventueel andere template-engines met dezelfde class kan aanspreken en dus een niveau van abstractie hebt)

Ohja, deze werkt alleen met PHP5

PHP:

<?php
class pnpTemplate {
    protected $_tpl, $_xslt, $_stylesheet;
    
    function __construct($module,$tpl_name,$type='unknown') {
        $xsl_dom = new DomDocument();
        $xsl_dom->load(pnpConfig::componentDirectory.$module->GetName()."/".$tpl_name.".xsl");
        
        $this->_xslt = new XsltProcessor();
        $this->_xslt->setParameter(null,"prefix",$module->prefix());
            
        $this->_stylesheet = $this->_xslt->importStylesheet($xsl_dom);
    }
    
    private function AddVarsToDOM(&$node, $params,&$inputdom) {
        foreach($params as $k=>$v) {
            if(is_array($v)) {
                $varnode = $inputdom->createElement($k);
                $this->AddVarsToDOM($varnode,$v,$inputdom);
                $node->appendChild($varnode);
            }
            elseif(is_object($v)) {
                $varnode = $inputdom->createElement($k);
                $this->AddVarsToDOM($varnode,$v,$inputdom);
                $node->appendChild($varnode);
            }
            else {
                $varnode = $inputdom->createElement($k);
                $valnode = $inputdom->createTextNode($v);
                $varnode->appendChild($valnode);
                $node->appendChild($varnode);
            }
        }
    }
    
    function Run($params=array(), $debug=false) {
        $inputdom = new DomDocument();
        $root_node = $inputdom->createElement("template");
            
        $this->AddVarsToDOM($root_node,$params,$inputdom);
        $inputdom->appendChild($root_node);
        if($debug) {
            print "<b>Input XML:</b><hr/>";
            print htmlentities($inputdom->saveXML());
        }
            
        $newdom = $this->_xslt->transformToDoc($inputdom);
        if(!is_object($newdom)) {
            throw new pnpException("XSLT Transformation failed",pnpException::xsltFailed);
        }
            
            
        return $newdom->saveXML(); 
    }
};
?>

Deze class genereert bijvoorbeeld de volgende XML (met 1 parameter: naam):

XML:

<?xml version="1.0"?>
<template>
    <name>jantje</name>
</template>

Met de XSL-file transform je dit dan alsvolgt naar HTML:

XML:

<?xml version="1.0" encoding="iso-8859-1" ?>
 
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  
  <xsl:template match="/template">
      <html>
            <head>
                <title>Groetjes!</title>
            </head>
            <body>
                Hey <xsl:value-of select="name"/>, leuk je te zien!
            </body>
        </html>
  </xsl:template>
 
</xsl:stylesheet>

Deze class is een versimpelde versie van de originele pnpTemplate class, die ik heb gemaakt voor mijn pnp-framework. Sommige dingen zul je dus zelf moeten maken of moeten vervangen, zoals de pnpException-class

Het leuke aan deze manier van templaten is dat je zelf ook tags kunt toevoegen die op de server worden gereplaced. Ikzelf gebruik bijvoorbeeld de <pnp:widget name="time"/> als ik ergens de huidige tijd wil hebben staan ofzo. Die tags worden door de eerdergenoemde uitgebreide versie van de pnpTemplate-class allemaal gereplaced met andere tags (ook weer uit een DOM). De code hiervoor (kun je in de Run-methode ergens kwijt denk ik):

PHP:

/* in de newdom zoeken naar pnp:widget elementen enzo) */
$items = $newdom->getElementsByTagName("widget"); 

foreach($items as $k=>&$v) {
        $params = array();
        
        foreach($v->attributes as $key=>$val) {
                $params[$key] = $val->textContent;
        }
        
        $params['text'] = $v->textContent;
        $parent = $v->parentNode;
        
        if(!isset($params['name'])) {
                throw new pnpException("XSLT Transformation failed: a pnp:widget tag was found, but no name attribute was specified.",pnpException::xsltFailed);
        }
        $name = $params['name'];
        
        // nieuw object maken
        $obj = [ergens je widget class vandaan plukken]
        $parent->replaceChild($obj->Widget($params,&$newdom),$v); // gooit exception als Widget niet is geimplementeerd in $obj
}

Uit ervaring is bij mij gebleken dat XSLT ruim 2x zo snel is als mijn eigengemaakte Stackbased Template Parser (klik hier voor versie met kleurtjes), die toch ook niet traag genoemd kan worden. De reden hiervoor is dat de XSLT in machinetaal is gemaakt (ws in C++ of C) en dat is nou eenmaal een stuk sneller dan alles in PHP te laten interpreteren

[ Voor 48% gewijzigd door MisterData op 09-06-2004 08:11 ]

[Verwijderd]

MisterData schreef op 09 juni 2004 @ 07:59:
Als je XSLT overigens wil gebruiken als template-engine, dan kun je (delen van) deze class gebruiken. Ik gebruik 'em zelf ook, en het werkt erg lekker (voordeel is dat je eventueel andere template-engines met dezelfde class kan aanspreken en dus een niveau van abstractie hebt)

Ohja, deze werkt alleen met PHP5

...

Deze class is een versimpelde versie van de originele pnpTemplate class, die ik heb gemaakt voor mijn pnp-framework. Sommige dingen zul je dus zelf moeten maken of moeten vervangen, zoals de pnpException-class

Het leuke aan deze manier van templaten is dat je zelf ook tags kunt toevoegen die op de server worden gereplaced. Ikzelf gebruik bijvoorbeeld de <pnp:widget name="time"/> als ik ergens de huidige tijd wil hebben staan ofzo. Die tags worden door de eerdergenoemde uitgebreide versie van de pnpTemplate-class allemaal gereplaced met andere tags (ook weer uit een DOM). De code hiervoor (kun je in de Run-methode ergens kwijt denk ik):

...

Uit ervaring is bij mij gebleken dat XSLT ruim 2x zo snel is als mijn eigengemaakte Stackbased Template Parser (klik hier voor versie met kleurtjes), die toch ook niet traag genoemd kan worden. De reden hiervoor is dat de XSLT in machinetaal is gemaakt (ws in C++ of C) en dat is nou eenmaal een stuk sneller dan alles in PHP te laten interpreteren

Ik heb zelf hier laatst een -ik moet zeggen heel erg goede, door een engelsman met heel veel ervaring er in- cursus gehad in XSLT en ik zie de voordelen er wel van in. Op dit moment echter heb ik nog vrij weinig tijd om tijd te investeren in het bekijken van het genereren van XML om hier dan weer XSLT voor te gaan schrijven.

Wel moet ik zeggen dat na de cursus XSLT een eitje was terwijl ik daarvoor de plank behoorlijk missloeg omdat ik de handigheid van de syntax niet kon overzien, maar met een paar do's en dont's was dit zo verholpen

Dit vindt ik dus wel een goed alternatief boven tbs, maareuh, hoe werkt dit nou op internet? moet je dan de Run methode aanroepen?? Ik vraag dit omdat die methode eindigt in saveXML, wat volgens mij nog wat anders is dan (X)HTML
Want volgens mij is het dus de bedoeling dat je een php bestand aanroept, dat xml genereerd, dat getransformeerd wordt met een aanroep vanuit php naar html dat als uitput naar de browser gaat?? Of stel je meer eisen aan de browser an gaat XML met een verwijzing naar de XSLT naar de browser
Maar goed, dat kun je mij vast uitleggen

Verwijderd schreef op 08 juni 2004 @ 23:45:
...
- het is niet valid HTML (maar dat is met custom-tags ook niet zo, dus niet echt een nadeel);

TBS templates zijn makkelijk valid HTML. Maar valid HTML schrijven is best lastig, allemaal kvt regeltjes

[...]
Wat is dit nou voor argument??? De voordelen van OO zijn makkelijk te benoemen (in tegenstelling tot een template-engine...). En ik beschouw OO gewoon als native PHP (het wordt toch door PHP-engine geparsed?) Ook beschouw ik Objecten niet als simpele functionwrappers....

tbs is een object?

[...]
Alle templatesystemen lijken allemaal op elkaar (en ik heb er verscheidene gebruikt). Ik zie in TBS niet zoveel verschil met andere templates (eerder redenen om het juist niet te gebruiken).

De syntax en hoe deze zich gedraagt in de html is juist geheel anders. Waarom zijn tbs templates bijvoorbeeld maakbaar met wysiwyg editors?? omdat ze gewoon html zijn, en correct html. want een table element mag naar mijn weten geen text bevatten (alleen header, rij en footer elementen) En dat hoeft bij tbs niet, en moet bij PHP en Smarty ed. Dus dat het niet zo erg verschilt wil ik niet erg hard roepen

[...]
PHP is ontstaan als template-engine om templates te parsen... (dat er in de loop der jaren het één en ander is toegevoegd doet hier niet aan af)

Zo staat het niet op PHP.net daar staat niks over templates in den beginne of daarna. Daar staat server side scripting, wat niks anders is dan scripts die op een andere pc dan je eigen uitgevoerd worden...

[ Voor 24% gewijzigd door Verwijderd op 09-06-2004 09:20 ]

[drm]

RwDwR:
Ja hallo, ik mag mijn mening toch wel hebben, dat sluit een discussie niet uit. Je kunt zelf heel goed zien dat deze code veel overzichtelijker is dan alle voorbeelden die je zelf laat zien.

En ik durf daar voor te wedden...

Wat is dit nou voor manier van discussieren? Snap je zelf dan niet dat als jij jouw mening constant als waarheid deponeert en een ieder die het daar niet mee eens is afwijst, dat ik dan geen zin heb om nog met argumenten voor of tegen te komen

Bovendien is deze code te bewerken met goede wysiwyg systemen (ik zeg goede omdat de minder goede altijd hun eigen idee hebben over hoe de opmaak er uit moet zien en je dus niet altijd blokken krijgt wat je verwacht, wat dan de template engine door de war maakt )

Dit is al een paar keer voorbijgekomen en dat heb ik ook al lang als goed argument erkend voor een templatesysteem. Wij gebruiken bijvoorbeeld helemaal geen wysiwyg rommel, en dat maakt het hier (binnenshuis) dus geen pré. Voor klanten eventueel wel als ze zelf de zaken aan willen kunnen passen _{(hoewel ik daar geen voorstander van ben, maar goed, da's een andere discussie)}. Nogmaals, dat heb ik al meerdere keren erkend als voordeel.

Maar zeg nou zelf, is dit makkelijker of lastiger te overzien dan jouw voorstel met de php-template?

Geen van beiden, imo. Maar je zegt hierboven al dat ik wel moet zien dat het "beter is", dus ik vraag me af waarom ik je nog vertel wat ik er van vind

RwDwR:
Nou, vreemd..
Ikzelf vindt het best ingenieus om html tags als delemiters te gebruiken (ook kan je tbs delemiters toevoegen mochten html tags niet goed uitkomen (1 keer gebeurd om javascript te doen)
Het is iets dat je 1 keer moet lezen, en dan weet je het en is het toch wel wat overzichtelijker. Aangezien de zgn php-template met dubbele delimeters werkt is dit onoverzichtelijker imo. Maar ook onpraktischer, je moet steeds dubbelop aangeven waar je begint en eindigt.

Dat laatste is voor de meeste mensen juist veel beter te lezen. Ik vind de syntax van tbs ook niet intuitief. Als iemand engels kan, kan hij PHP (in de template-vorm) lezen, daar hoef je niet eens een programmeursachtergrond voor te hebben. Dat is bij TBS niet zo. Ik vind het overigens ook best een goed idee, vanuit het idee om compacte code te kunnen schrijven, maar dat is niet altijd een prioriteit (meestal niet zelfs).

RwDwR:
Ik werk aan de objectieve argumenten, maar de argumenten die objectief zijn hebben alleen betrekking op "welke engine" niet of je er eentje moet gebruiken.

Zoals je wellicht is opgevallen in deze discussie zijn dat dus twee dingen die heel erg dicht bij elkaar liggen.

Want PHP zie ik nog steeds niet als template engine. Een template engine zie ik als een stukje code (wellicht in de vorm van een object) dat die template functies verricht. PHP als template engine gebruiken is gewoon een slimme toepassing van een anders geschreven stukje PHP.

Je vergeet wel dat de reden om templates te gebruiken is dat je dus op de HTML georienteerd ben in plaats van op de PHP code. Ik zal in mijn templates zo min mogelijk PHP code zetten die het weer minder overzichtelijk maakt. Verder is alles wat in php-templates staat template-logica, dus waarom zou PHP dan geen template-engine zijn? Laat ik het anders zeggen: Waarom zou PHP niet als template-engine kunnen functioneren? _{(en daarmee dus meedingen in de discussie "welke template-engine moet ik gebruiken?")}

en dan minder gerelateerd aan het onderwerp:
Ik erger mij ook aan de reactie van een mod die eerst vraagt voor een beter argument om een template engine te gebruiken eventueel ondersteund met code. En als hij het krijgt, met mijn mening , er dan vervolgens niet op in gaat omdat ik mijn mening niet mag posten (zoals jij ook zegt)

Mijn rode kleurtje heeft hier helemaal geen ruk mee te maken. Als ik niet had gewild dat jij je mening gegeven had, had ik je wel van het forum geschopt. Het probleem is dat je manier van discussieren niet uitnodigt tot verdere argumenten geven, want ik zie constant opmerkingen voorbijkomen die de indruk wekken dat iedereen die wat anders vindt dan jij achterlijk is. En als je dat niet bedoelt zou ik maar eens goed gaan kijken of je je punten niet eens een keertje op een andere manier duidelijk kan maken. Of wil je zeggen dat een opmerking als "Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren" wel uitnodigt tot discussieren Misschien moet je gewoon eens leren accepteren dat er ook dingen zijn waar anderen een andere mening over hebben, ongeacht of jij dat begrijpt of niet. Dat is namelijk een heel volwassen iets, om dat in te zien.

Als hij er nou alsnog maar op in gaat, want ik kan mij niet aan de mening ontrekken dat hij de syntax in zowel het php als in het html gedeelte overzichtelijker zou moeten vinden met gebruik van tbs....

Daar ben ik het (zoals zo langzamerhand wel duidelijk mag zijn) dus niet mee eens. Als jij dat dan ook gewoon kan respecteren dan zijn we er over uit dat het wat mij betreft geen zin heeft om hier nog verder over te discussieren.

* drm out

[JayTaph]

Zo'n loopje wil ik dus niet in m'n template hebben. Dat hoort daar imho niet thuis.
Kan jij me uitleggen waarom het wel in m'n template zou moeten?

Hmm.. ik ben van mening dat hij daar juist WEL thuis in hoort.

Voorbeeldjes:

code:

  $template = new Smarty()
  $template->debugging = true;

  $languages = array ("Dutch"  => "dutch.jpg", 
                      "English" => "english.jpg", 
                      "French"  => "french.jpg", 
                      "German"  => ""german.jpg");

  foreach ($languages as $lang_str => $lang_img) {
    $tmp = array ();
    $tmp['str'] = $lang_str];
    $tmp['img'] = $lang_img];
    $template->append ("language", $tmp);
  }

  $template->display ($_CONFIG['theme_path']."/language_settings.tpl");

De Template:

code:

<!-- language_settings.tpl -->

<center><b>Choose your language</b></center>

<form method='post' action='{$SCRIPT_NAME}'>
  <select name='language'>
    {section loop='row' name={$language}>
      <option value='{$language[row].str}'>{$language[row].str}</option>
    {/section}
  </select>
  <input type='submit' />
</form>
<br />
<br />

<!-- end language_settings.tpl -->

Of een andere Template, zonder de phpcode aan te passen

code:

<!-- language_settings.tpl -->

<form method='post' action='{$SCRIPT_NAME}'>
<table>
  <tr><th>Choose your language</th></tr>
  <tr>
    <td>
      [img]'{$language[row].img}'[/img] 
      <input type='radio' name='language' value='{$language[row].str'}>
    </td>
  </tr>
  <tr>
    <td>
      <input type='submit' />
    </td>
  </tr>
</table>

</form>
<br />
<br />

<!-- end language_settings.tpl -->

Ik lever dus vanuit mijn code de gegevens aan die de template-bouwers / designers kunnen gebruiken, maar zeker niet HOEVEN te gebruiken. Als het voor een designer beter/gemakkelijker is om in plaats van een selectbox radiobuttons te gebruiken, of hij wil daarvoor weer iets anders gebruiken, dan is het de taak van de designer om dat aan te passen. Niet de taak van de software-bouwer. Zo maak je anders geen onderscheid tussen php en html als jij voor de webdesigner gaat bepalen dat bepaalde data al in een selectbox dient te komen.

Templates hoeven helemaal niet vrij te zijn van code in wat voor syntax dan ook. Sterker nog: zodra dat Wel het geval is, getuigd dat alleen maar van een te strak vastgelegde opmaak die waarschijnlijk alleen door de php-devver aan te passen is, en laat dat nou net de verkeerde persoon zijn

[Verwijderd]

Ik gebruik overigens zelf geen wysiwyg omdat ik eigenlijk meer heil zie in wysiwyw (waarbij de laatste w = want) omdat ik meestal wel krijg wat ik zie, maar nooit wat ik wil. Ik gebruik Textpad. Ik weet niet of je dat programma kent, maar het is notepad ^ 100 ongeveer. (Geenoverbodige overvloedige interface, en veel optionele funtcies, met een heeel veel efficienter zoekalgoritme. (voor bestanden tot 100Mb goed te doen))

Maar goed...

Ik heb voor de gein zonet een vriendin van me laten lezen (oorspronkelijk een Engelse), en ze komt uit jouw template niet wijs, de mijne kan ze lezen (ze begrijpt HTML) maar snapt ook niet hoe ik aan meerdere rijen kom en had dus bij beide systemen wat meer achtergrondkennis nodig dan Engels alleen....

Ik zie geen redenen waarom PHP niet KAN als template engine, ik zie alleen redenen waarom je het niet zou moeten doen. En deze heb ik daadwerkelijk gepost hoor...

[Verwijderd]

Nou, Smarty is traag, tbs is trager

HEb ik me zeker verlezen ooit in de tbs manual...

Dit had de maker van tbs te zeggen

Skrol29
The TBS block syntaxes (explicit, relative or simplified) have not a big impact on the merge speed. Because the block definition is read only once during the merge. You can change your TBS test with the explicit syntax (block=begin + block=end), this will not save significant time.

But when merging each rows, TBS search again for all TBS tags in the current section. That's smart and agile but slower.

But guess what... I've alread improved that. Yes. I have TBS 1.97b ready to test now. This coming next version put TBS fields in cache, so time is saved. This version has good results. And any beta testers are welcome.

TBS will still be under Smarty benches because TBS does more. For exemple, TBS has event properties that enables you to change data dynamically. But TBS is geting closer and closer.

[ripexx]

Verwijderd schreef op 09 juni 2004 @ 10:31:
Ik gebruik overigens zelf geen wysiwyg omdat ik eigenlijk meer heil zie in wysiwyw (waarbij de laatste w = want) omdat ik meestal wel krijg wat ik zie, maar nooit wat ik wil. Ik gebruik Textpad. Ik weet niet of je dat programma kent, maar het is notepad ^ 100 ongeveer. (Geenoverbodige overvloedige interface, en veel optionele funtcies, met een heeel veel efficienter zoekalgoritme. (voor bestanden tot 100Mb goed te doen))

Duh, er zijn wel meer goed text editors

Maar goed...

Ik heb voor de gein zonet een vriendin van me laten lezen (oorspronkelijk een Engelse), en ze komt uit jouw template niet wijs, de mijne kan ze lezen (ze begrijpt HTML) maar snapt ook niet hoe ik aan meerdere rijen kom en had dus bij beide systemen wat meer achtergrondkennis nodig dan Engels alleen....

Voor alles heb je een stukje uitleg nodig en dat is geen probleem. Door wat commentaar toe te voegen. Voor deel is ook nog eens dat je het commentaar in je php code kan plaatsen waardoor dit niet naar de client wordt gestuurd, want die heeft er namelijk niets aan

Ik zie geen redenen waarom PHP niet KAN als template engine, ik zie alleen redenen waarom je het niet zou moeten doen. En deze heb ik daadwerkelijk gepost hoor...

Toevallig gisteren bezig geweest om een aantal custom acties aan te passen in HTMLArea. Ik had daar dus een db-connectie voor nodig. Even wat kleine aanpassingen en nog wat rommelen met sessie het werkte. Maar nu moet de code weer gebruikt worden in je orgine bestand. Nou ik heb even gekeken naar de methode van drm maar het werkt verdomt eenvoudig. Kwestie van juist commentarieren.

Ik heb inmiddels al aardig wat template enigines bekeken en zie gewoon dat er weinig verschillen zijn. De een kan net wat meer dan de ander, en een ander is weer sneller dan de een. Het is vooral lood om oud ijzer. Maar om nu te zeggen dat TBS sneller is dan PHP of meer functionaliteit heeft? Wellicht is de code wat eenvoudiger te lezen (subjectief ) en kan je het eenvoudiger aanpassen met een WYSIWYG editor. Maar wil je wel dat men zo'n ding gaat gebruiken. Ik moet er niet aandenken. Meestal bestaat de site dan uit meerdere templates die weer samengevoegd worden. Men past een deel aan en die editor gaat weer tags toevoegen, style elementen aanpassen en weet ik veel.

[RedRose]

Pffffff, wat een discussie zeg. Er zijn hier een aantal mensen die compleet langs elkaar heen praten, maar goed.

Allereerst twee quotes die mijns inziens het belangrijkste zijn:

Bosmonster:
Een designer/frontend-developer (ik zie ze nog steeds liever gescheiden, het zijn 2 compleet verschillende disciplines) die html kent hoort ook te weten hoe om te gaan met backend code.

en:

.oisyn:
Sorry, maar nee. Wat is je punt nou precies Daar wordt bewezen dat je html niet vanuit je logic layer moet outputten. Doe ik ook niet, maar ik gebruik wel php. Ik heb de template files apart van de logic files, dus data en opmaak is gescheiden. Dat is de essentie van het linkje dat jij postte, niet dat je geen PHP mag gebruiken.

Er moet een aantal dingen worden gescheiden:

1. Je hebt data;
2. Je hebt html;
3. Je hebt een systeem nodig waarin je:
3a. De data op een snelle manier kan parsen in je html;
3b. Een html-slet een makkelijke werkset geeft om 3a. makkelijk te verwerken in zijn html;
3c. Je code op een goede manier indeelt. Zoals .oisyn aangeeft: het scheiden van html-templates en logic is een goede manier om dat te doen. Je hebt dus niet alleen een scheiding van data/code en html in de files zelf, maar ook tussen verschillende bestanden. Je moet alleen toch op de één of andere manier de data in je html krijgen. De beste argumenten naar mijn mening hoe dat op een goede manier te doen zijn : beheersbaarheid en snelheid. Voor de rest maakt het geen hol uit of je nou zelf een template-taal schrijft, xml/xslt gebruikt, of het bij native PHP houdt. Dat hangt maar net van de aanwezige kennis in het dev-team af.
4. Er wordt in deze discussie geen onderscheid gemaakt in het ontwikkelen van de template en het uiteindelijke outputten ervan naar de browser.

Het is al vaker gezegd hier op GoT, maar ik herhaal het hier eigenlijk gewoon en ik werk zelf ook op de volgende manier, die naar mijn mening nog steeds de beste en snelste is:

Je maakt zelf een template-taal als je een gebrek hebt aan htmllers die ook php-kennis hebben. Een beetje taal heeft niet alleen variabelen-tags, maar ook enigszins control-structs en dergelijke. Uiteraard kan je hier ook prima PHP voor gebruiken, zoals gezegd, maar dan heb je een htmller nodig die PHP begrijpt.

Dan bouw je een tussenfase in, waarin je een in elkaar geprutste template checkt op semantiek en syntax. Let wel, dit is nog steeds in de ontwikkelfase. Als de template goed is bevonden (als in: geen syntactische fouten etc..) 'compileer' je de delen waarin je dynamische zooi (je template-taal, data) template naar PHP. Je vervangt dus eigenlijk je template-taal en de bijbehorende data door PHP en die schrijf je weg naar een nieuw bestand. Dat 'gecompileerde' bestand ga je dan pas een keer naar je output sturen. Template-devvers behoren _niet_ aan dat laatste bestand te komen, maar kunnen gewoon lekker verder werken aan de template die ze zelf hebben ontwikkeld. Zo heb en behou je scheiding van de html-ontwikkeling en de PHP-code en bouw je een buffer in voor de templateontwikkelaar.

De uiteindelijke snelheid van een 'gecompileerde' template is dan vele malen hoger dan wanneer je ter plekke bij een browser-request je template-taal nog moet gaan converteren. Native PHP is nog steeds het snelst en je kan mij niet vertellen dat 'iets anders' in deze context net zo snel of sneller is.

[RedRose]

Verwijderd schreef op 09 juni 2004 @ 11:00:
Nou, Smarty is traag, tbs is trager

Dat hangt er maar net van af hoe je met die templatesystemen omgaat. Out of the box kan het traag zijn, maar als je gaat optimaliseren voor wat betreft code en data (fetching), dan hangt het er maar net van af.

[ Voor 26% gewijzigd door RedRose op 09-06-2004 11:37 ]

[Verwijderd]

ripexx schreef op 09 juni 2004 @ 11:14:
[...]

Voor alles heb je een stukje uitleg nodig en dat is geen probleem. Door wat commentaar toe te voegen. Voor deel is ook nog eens dat je het commentaar in je php code kan plaatsen waardoor dit niet naar de client wordt gestuurd, want die heeft er namelijk niets aan

Al aangedragen voor toevoeging aan tbs...

[...]

Ik heb inmiddels al aardig wat template enigines bekeken en zie gewoon dat er weinig verschillen zijn. De een kan net wat meer dan de ander, en een ander is weer sneller dan de een. Het is vooral lood om oud ijzer. Maar om nu te zeggen dat TBS sneller is dan PHP of meer functionaliteit heeft? Wellicht is de code wat eenvoudiger te lezen (subjectief ) en kan je het eenvoudiger aanpassen met een WYSIWYG editor. Maar wil je wel dat men zo'n ding gaat gebruiken. Ik moet er niet aandenken. Meestal bestaat de site dan uit meerdere templates die weer samengevoegd worden. Men past een deel aan en die editor gaat weer tags toevoegen, style elementen aanpassen en weet ik veel.

Gebruik dan ook XSLT. Dat is gewoon het ding dat je "moet" gebruiken
Als ik de tijd krijg maak ik de overstap...

dwz, ik maak hem thuis, op het werk wordt dat cursussen voor alle designers, weet niet of ze daar zo happy van worden....

[ Voor 7% gewijzigd door Verwijderd op 09-06-2004 11:38 ]

[djluc]

De uiteindelijke snelheid van een 'gecompileerde' template is dan vele malen hoger dan wanneer je ter plekke bij een browser-request je template-taal nog moet gaan converteren. Native PHP is nog steeds het snelst en je kan mij niet vertellen dat 'iets anders' in deze context net zo snel of sneller is.

Dit is erg interessant. Eigenlijk ga je dus dingen als: {veld} vervangen door <?PHP echo $veld;?> ?

[RedRose]

djluc schreef op 09 juni 2004 @ 11:56:
[...]
Dit is erg interessant. Eigenlijk ga je dus dingen als: {veld} vervangen door <?PHP echo $veld;?> ?

Afhankelijk van wat de template devver handig vind, ja. Bijvoorbeeld: ik heb hier een template-devver die blokhaken mooi vind (vraag me niet waarom), dus dan zet ik gewoon: $tag_start = '[';$tag_end = ']'. Dan kan hij lekker met zn blokhaken werken. De template die hij maakt wordt toch gecompileerd naar PHP en dat gooi je in je output. Dus in het geval van variabelen (of constants) gebeurt bovenstaande. Dan heb je alleen PHP in je outut-template en dat is sneller dan een template met een eigen taal die je dan ook nog moet parsen.

[Verwijderd]

djluc schreef op 09 juni 2004 @ 11:56:
[...]
Dit is erg interessant. Eigenlijk ga je dus dingen als: {veld} vervangen door <?PHP echo $veld;?> ?

Behalve interressant is het ok gevaarlijk, je zult erg op moeten passen wat je dan niet nog meer in je template gaat plaatsen tussen de <?php en ?> Want voor je het weet zit je anders terug op de oude situatie...

En op deze manier zijn je templates meteen niet meer zo toegankelijk voor mensen wie je alleen design wilt laten doen..

(Maar beide punten zijn al eens genoemd in deze thread)

[RedRose]

Verwijderd schreef op 09 juni 2004 @ 12:30:
[...]
Behalve interressant is het ok gevaarlijk, je zult erg op moeten passen wat je dan niet nog meer in je template gaat plaatsen tussen de <?php en ?> Want voor je het weet zit je anders terug op de oude situatie...

En op deze manier zijn je templates meteen niet meer zo toegankelijk voor mensen wie je alleen design wilt laten doen..

(Maar beide punten zijn al eens genoemd in deze thread)

Lees mijn post nog eens goed door dan.

edit: Je moet altijd oppassen wat je tussen PHP-tags stopt. Alleen de vereiste functionaliteit en niet te veel perfomance verslindende zooi en niet meer.

[ Voor 14% gewijzigd door RedRose op 09-06-2004 12:39 ]

[Verwijderd]

RedRose schreef op 09 juni 2004 @ 12:33:
[...]
Lees mijn post nog eens goed door dan.

edit: Je moet altijd oppassen wat je tussen PHP-tags stopt. Alleen de vereiste functionaliteit en niet te veel perfomance verslindende zooi en niet meer.

Nee, als je php als template engine gebruikt moet je oppassen wat voor soort evreiste functionaliteit thuis hoort in je template, en je wijkt er uit gemakszucht misschien wel eens vanaf...

[RedRose]

Verwijderd schreef op 09 juni 2004 @ 13:10:
[...]
Nee, als je php als template engine gebruikt moet je oppassen wat voor soort evreiste functionaliteit thuis hoort in je template, en je wijkt er uit gemakszucht misschien wel eens vanaf...

Dat jij misschien dingen soms gemakszuchtig doet wil niet zeggen dat ik dat doe.

Uiteraard bepaal je van te voren welke functionaliteit je aanbiedt in je template. Anders heb je weinig basis voor het creeeren van een template taal. Het punt was juist dat je PHP niet gebruikt als templatetaal voor de templatedevver, maar als parsetaal voor de output, waar PHP ook voor bedoeld is. Je kan PHP ook prima gebruiken als templatetaal, maar dan moet je wel een templatedevver hebben die PHP beheerst en daarnaast krijg je, als je dat doet, dus geen duidelijk begrensd aanbod van functionaliteit voor de templatedevver.

[.oisyn]

Laat, maar toch wil ik nog even reageren

Verwijderd schreef op 08 juni 2004 @ 17:02:
[.oisyn: wat is de relevantie van jouw post met mijn reactie op GsusZ]
Het ging mij om template engines in het algemeen

Waarom reageer je dan op mijn post met argumenten die niet eens op de inhoud van mijn post slaan

[.oisyn: (Trouwens, wat is het voordeel van tbs tov PHP?)]
Zie mijn vorige post...
(direct hier boven, maar dit vondt ik een aparte post waard.)

Mja, ik zie geen voordeel van tbs tov php. Ik snap die template syntax van tbs ook niet helemaal op het eerste gezicht, block=tr voorbeeld.some . Bovendien, je geeft het een SQL string
Wat is dan echt het voordeel van tbs tov php? Maar goed, dat is allemaal al besproken dus daar hoef je verder ook niet op in te gaan

Ik snap je punt, maar mn laatste post laat zien waarom je tbs wil gebruiken ipv php, oa omdat de maker van tbs zelf vondt dat smarty enzo geen excuus was om het te gebruiken en dus tbs ontwikkelde...
En vandaar dat tbs ook wat afwijkt van wat je gewend bent van een template engine...

Dus jij wilt tbs gebruiken ipv omdat de makers van tbs zeggen dat smarty geen excuus was om een template engine te gebruiken Misschien ligt het aan mij, maar ik vind het maar een kromme redenatie die kant noch wal raakt.

[.oisyn]

RedRose schreef op 09 juni 2004 @ 12:02:
[...]
Afhankelijk van wat de template devver handig vind, ja. Bijvoorbeeld: ik heb hier een template-devver die blokhaken mooi vind (vraag me niet waarom), dus dan zet ik gewoon: $tag_start = '[';$tag_end = ']'. Dan kan hij lekker met zn blokhaken werken.

Da's natuurlijk een handige feature, maar op een gegeven moment werkt die persoon niet meer in datzelfde bedrijf, en moet een andere werknemer, die altijd al de accolades heeft gebruikt, zijn werk overnemen en gaat ie dus steeds fouten maken. Eigenlijk is het gewoon een codestyle guideline, en het werkt gewoon het best als iedereen hetzelfde doet . Dus als die persoon de accolades lelijk vindt zou je eigenlijk gewoon moeten zeggen dat ie pech heeft en dat ie het maar gewoon moet gebruiken

Verwijderd schreef op 09 juni 2004 @ 13:10:
[...]
Nee, als je php als template engine gebruikt moet je oppassen wat voor soort evreiste functionaliteit thuis hoort in je template, en je wijkt er uit gemakszucht misschien wel eens vanaf...

Ik geloof niet zo in bescherming tegen jezelf. Dat is net zoiets als broodmessen verbieden omdat enkelen het nodig vinden er anderen mee pijn te doen.

[RedRose]

.oisyn schreef op 09 juni 2004 @ 14:25:
Da's natuurlijk een handige feature, maar op een gegeven moment werkt die persoon niet meer in datzelfde bedrijf, en moet een andere werknemer, die altijd al de accolades heeft gebruikt, zijn werk overnemen en gaat ie dus steeds fouten maken. Eigenlijk is het gewoon een codestyle guideline, en het werkt gewoon het best als iedereen hetzelfde doet . Dus als die persoon de accolades lelijk vindt zou je eigenlijk gewoon moeten zeggen dat ie pech heeft en dat ie het maar gewoon moet gebruiken

Klopt, het was ook meer een voorbeeld om trachten aan te tonen dat je best wat kan doen om het ontwikkelen van de template zo gebruikersvriendelijk mogelijk te maken of per geval toe te spitsen, afhankelijk van de aanwezige kennis. Ik vraag meestal welke tags ze willen en dan laat ik het zo, omdat je natuurlijk ook niet tot in de lengte van dagen met een project bezig kan zijn.

[Verwijderd]

Het argument van de maker van TBS om TBS te gebruiken boven PHP of Smarty of een ander template systeem:
(Dit is gebaseerd op het voorbeeld dat hier gegeven werd om php als template engine te gebruiken waarop ik mnet de tbs variant reageerde)

Skrol29
The Template you suggest to compare with TBS (let's call it a Smarty Template) is not what I would call a template. For me, since there is program statements, it's a kind of script over PHP.

Only a developper can build such a Template. A pure Html designer is not able to do it. He must has some algorythm understanding.

Designing Html Templates should be like designing C++Builder Forms, Delphi Forms, 4D Forms, Visual Basic Forms, .Net Forms ... I mean just like any visual RAD tools: forms in one side, program in another side.
That's what templates are (template = static form), or should be. And that's what Template Systems before TBS never did.

Mijn antwoord daar op:

RwD
Ok, but then how does a designer design a template?
I mean, in the templates I build I need some knowledge of the php files before I can build them...

So why is tbs so easy for the designer? Doesn't he still need to understand some algorythms to be able to put in the tbs tags at the right places?

I know it took some effort from me on my side to learn how to apply tbs in certain cituations.

Wil iemand anders nog schieten?
Ga gerust naar het TBS forum (www.tinybutstrong.com en klik op Forum)

(Ik ben nog vergeten te zeggen dat ze ook de syntax van tbs moeten leren terwijl ze net zo goed dan ook php kunnen leren)

[ Voor 13% gewijzigd door Verwijderd op 09-06-2004 14:42 ]

[.oisyn]

Mja ik heb niet echt de behoefte om te reageren op het TBS forum, maar ik wil hier wel even zeggen dat ik het echt totaal oneens ben met die Skrol29. Waarom zou een template "statisch" moeten zijn? Slaat mijn inziens nergens op. Een template is ervoor om een opmaak te bieden om de data heen, en daarbij mag je best flow-control structures gebruik maken. En dan te zeggen dat een pure html designer daar geen verstand van heeft vind ik ronduit arrogant te noemen. Maar goed, gezien het ontwerp van TBS (zoals bijvoorbeeld het geven van een string met een SQL statement ) schat ik ze niet veel hoger dan Zend, die hebben ook geen verstand van de zaken waar ze mee bezig zijn

.edit: toch maar wel een reactie geplaatst

[ Voor 4% gewijzigd door .oisyn op 09-06-2004 15:56 ]

[MisterData]

Verwijderd schreef op 09 juni 2004 @ 09:08:
[...]
Dit vindt ik dus wel een goed alternatief boven tbs, maareuh, hoe werkt dit nou op internet? moet je dan de Run methode aanroepen??

Eerst je variabelen (dit kunnen arrays, objecten of gewone vars zijn, de functie loopt recursief door de arrays/objecten als het goed is) adden met AddVarsToDom, daarna Run doen voor de output (als ik het goed heb).

Ik vraag dit omdat die methode eindigt in saveXML, wat volgens mij nog wat anders is dan (X)HTML

XHTML is in feite XML hoor Ik weet niet of je op je cursus uitleg over DTD's etc gehad had, maar XHTML is in feite XML met een XHTML-DTD.

Want volgens mij is het dus de bedoeling dat je een php bestand aanroept, dat xml genereerd, dat getransformeerd wordt met een aanroep vanuit php naar html dat als uitput naar de browser gaat?? Of stel je meer eisen aan de browser an gaat XML met een verwijzing naar de XSLT naar de browser
Maar goed, dat kun je mij vast uitleggen

Alle XSLT-transformaties gebeuren op de server, maar je zou eventueel ook een en ander op de client plaats kunnen laten vinden. Dat mag je zelf dus uitmaken

[stekkel]

Ik sluit me aan bij .oisyn. Toevallig ben ik vorige week begonnen aan het maken van php templates voor SquirrelMail en ik kan je vertellen dat het onmogelijk is om templates te maken zonder flow-control structures.

De te tonen inhoud is alles behalve statisch en afhankelijk van user settings.
Naar mate gebruikers meer invloed hebben op de de tonen informatie d.m.v. user settings neemt de complexiteit van de te gebruiken templates toe.

Wat mij ook opviel is dat wanneer je een template designer optimale vrijheid wilt geven dan kan dat alleen maar wanneer je enige vorm van logica die betrekking heeft op de output toevoegd aan het template.
Het is heel makkelijk om een tabel in php te maken en die door te geven aan het template maar dan valt er nog weinig te layouten voor een template designer. Echter, wanneer je alle tabel waarden in de vorm van een array meegeeft dan zal je template in ieder geval loops moeten bevatten voor het creeren van de rijen en kolommen. En dan heb ik het nog niets eens over verschillende stijlen per kolom die weer afhankelijk zijn van het type kolom dat niet gefixeerd op positie is. Idem dito voor rijen.

Overigens snap ik dat van de mogelijkheid om sql queries uit te voeren van een template ook niet. Wanneer ik de parallel trek naar imap queries (daar houd ik me mee bezig) dan moet ik er niet aan denken dat template designers controle zouden hebben over uitgevoerde queries. In 95 % van de gevallen zou er namelijk informatie opgevraagd worden die in een andere vorm al aanwezig is of er worden worden tig queries uitgevoerd die ook met 1 query uitgevoerd had kunnen worden.
Ik houd me hart al vast wanneer een php ontwikkelaar zich met queries gaat bemoeien (zoals bijvoorbeeld plugin developers voor SquirrelMail die het presteren om performance killer plugins te schrijven %&$#%). Ik zou een hart verzakking krijgen wanneer template designers zich daar mee bezig zouden houden.

[PrisonerOfPain]

Omdat ik toch niets te doen had heb ik even een simpele benchmark geschreven de 'test pc' (nog geen 400 Mhz) draaide met een 100% load

TBS:

PHP:

<?php
list ($u, $s) = explode (' ', microtime());
$begin = ((float) $u + (float) $s);

include_once ('tbs.php');
$Array = array("A" => "B", "C" => "D","E" => "F");

for ($i = 0; $i < 100; $i++)
{
    $TBS = new clsTinyButStrong;
    $TBS->LoadTemplate( 'example.htm' );
    $TBS->MergeBlock ('block1', $Array);
    $TBS->Show ();
}

list ($u, $s) = explode (' ', microtime());
$end = ((float) $u + (float) $s);

echo $end - $begin;
?>

Met de template

HTML:

<table border="1">
   <tr>
      <td>[block1.key;block=tr]</td>
      <td>[block1.val]</td>
   </tr>
</table>

Deed er (schrik niet!) 8.214012146 seconden over om te laden.
PHP:

PHP:

<?php
list ($u, $s) = explode (' ', microtime());
$begin = ((float) $u + (float) $s);

$Array = array("A" => "B", "C" => "D","E" => "F");

for ($i = 0; $i < 100; $i++)
{
    $_TPL['Array'] = $Array; //De array doorgeven aan de template
    include('template.tpl');
}

list ($u, $s) = explode (' ', microtime());
$end = ((float) $u + (float) $s);

echo $end - $begin;
?>

En de template

PHP:

<table border="1">
<?foreach ($_TPL['Array'] as $Key => $Val):?>
   <tr>
      <td><?=$Key?></td>
      <td><?=$Val?></td>
   </tr>
<?endforeach?>
</table>

Deed er 0.540458917618 seconden over. Dat is een grove 15 keer sneller. Als je deze test na zult willen doen, moet je TBS wel aanpassen, omdat deze in de 'Show' method standaard twee keer 'exit' aanroept. (Op regel 191 en 193).

[ Voor 19% gewijzigd door PrisonerOfPain op 09-06-2004 17:21 . Reden: tag aangepast voor de TBS template ]

[Verwijderd]

PrisonerOfPain schreef op 09 juni 2004 @ 17:20:
Omdat ik toch niets te doen had heb ik even een simpele benchmark geschreven de 'test pc' (nog geen 400 Mhz) draaide met een 100% load
...

Doe mij eens die benchmark? ik kom net echt veel verder dan 100% load en allebei even snel Maar goed, ik heb geen benchmarkschrijfzin. Maar ik zou ze wel es willen vergelijken (om te zien of het verschil idd 15* is)

stekkel schreef op 09 juni 2004 @ 16:28:
....
Overigens snap ik dat van de mogelijkheid om sql queries uit te voeren van een template ook niet. Wanneer ik de parallel trek naar imap queries (daar houd ik me mee bezig) dan moet ik er niet aan denken dat template designers controle zouden hebben over uitgevoerde queries. In 95 % van de gevallen zou er namelijk informatie opgevraagd worden die in een andere vorm al aanwezig is of er worden worden tig queries uitgevoerd die ook met 1 query uitgevoerd had kunnen worden.
Ik houd me hart al vast wanneer een php ontwikkelaar zich met queries gaat bemoeien (zoals bijvoorbeeld plugin developers voor SquirrelMail die het presteren om performance killer plugins te schrijven %&$#%). Ik zou een hart verzakking krijgen wanneer template designers zich daar mee bezig zouden houden.

Misverstandje, de query staat niet in de template. Lees maar waar die reactie op was, daar was dit ook niet het geval...

MisterData schreef op 09 juni 2004 @ 16:02:
[...]

XHTML is in feite XML hoor Ik weet niet of je op je cursus uitleg over DTD's etc gehad had, maar XHTML is in feite XML met een XHTML-DTD.

Euh, die cursus was alleen een simpele 'hoe XSLT ik'... DTD's en de hele XML zooi snap ik wel. (Ik heb nog ergens de gehele XML datastructuur op gezet, en die gebruiken ze nog steeds, ze zijn er erg blij mee ) Maar als je XML gaat voeren aan je browser dat er uit ziet als HTML of wat dan ook, dan krijg je problemen, tenminste, ik wel op op IE 6

[PrisonerOfPain]

Verwijderd schreef op 09 juni 2004 @ 19:12:
Doe mij eens die benchmark? ik kom net echt veel verder dan 100% load en allebei even snel Maar goed, ik heb geen benchmarkschrijfzin. Maar ik zou ze wel es willen vergelijken (om te zien of het verschil idd 15* is)

Alles wat ik gebruikt heb om te benchen is de source die daarboven staat met apache 2 en php 5 een PII servertje (klein lied dev servertje) en de laatste versie van TBS. Met een normale load (5% ofzo) is het 0.2 sec voor PHP en 3.5 tot 4.8 sec voor TBS.

Edit, even snel lijkt me sterk TBS is zelf al 3000 regels om te parsen (een klein classje dat losse functies aanroept buiten de class).

[ Voor 11% gewijzigd door PrisonerOfPain op 09-06-2004 19:26 ]