TempLight 0.2

Misschien handig om er ook even een voorbeeldje bij te doen van hoe een template er dan uit komt te zien?

Hoe zit het verder met de functionaliteit? Ik heb er nog niet goed naar gekeken, maar zo op het eerste gezicht lijkt het me niet dat dit ook maar in de buurt komt van de functionaliteit die bijvoorbeeld Smarty biedt.

Zou ook moeilijk gaan Blanche, maar zou ook fijn zijn als je blocks kunt gebruiken en dat is helaas nu niet het geval, gewoon vars naar template

Hoezo? Dat is natuurlijk prima te realiseren, alleen zul je natuurlijk wel wat meer dan 260 regeltjes code nodig hebben...

smarty is 170kb... zou heel knap zijn als je dat in een paar 100 regels krijgt.
En dan komt de vraag weet... hoeveel gebruik je er eigenlijk van?
Er is ook een light variatie van smarty bijvoorbeeld, die nagenoeg het zelfde kan.

Ik heb gewoon php in mijn templates ZONDER eval(); en lng geen 170kb lib iig..
Nagenoeg een 10e...

Wat wil je, wat verwacht je, wat gebruik je... Alle functionaliteiten van smarty? Denk het niet... Maar goed blijft een persoonlijke keuze... Maar laten we gewoon geen appels met peren gaan vergelijken iig...

a

@Lode: natuurlijk, dat zal ik ook zeker niet tegenspreken. Maar het ging mij meer om deze uitspraak van Ypma bij de template parser tutorial:
En als ik dit dan zie vraag ik me toch af hoe al die functionaliteiten er dan in verwerkt zijn.

Wat je verder zegt over smarty: je kunt hem natuurlijk zelf zover strippen als je wilt. Gooi alle voor jou overbodige functies (lees: bestanden) overboord en de complete lib kun je zo met tientallen kb's reduceren.

Maar goed dit is nog maar v0.1 van TempLight, dus een kans krijgt het zeker. Maar ik ben wel benieuwd hoe een template file er nu uit zou moeten komen te zien. Een voorbeeld is dus nog steeds welkom.

Het idee achter een singleton methode gecombineerd met een public constructor en een clone mogelijkheid ontgaat me even?

Ach ja...

Ik heb er nog niet eens naar gekeken eigenlijk... Maar zijn zo vaak dezelfde discussies...

ik haal mijn geparste templates iig op met __toString(){}
welke vervolgens eventueel weer door een class gaan die 'extends tidy'.
en/of een class die bijvoorbeeld caching regelen.
Meestal strip ik alle whitespaces ook nog na tidy.. Word net als googlemaps een block code waar je bijvoorbaad al hoofdpijn van krijgt en die net iets minder bandbreedte kost en een browser net zo snel kan lezen...

ik gebruik variabele-variabele in mijn templates om een klein tipje van de sluier te lichten... Maar dan wel gedefineerde!

EDIT:
ontbreekt mij wel geheel aan voorbeelden en documentatie bij je code overigens... Serverside maakt dat bijna geen fluit uit iig...

Mijn excuses voor de toch minimale informatie hierbij. Dit had beter gekund.
De uitspraak bij ik maakte bij het "Template parser tutorial" sta ik trouwens nog steeds achter... ik biedt alle functionaliteiten van smarty, en die functionaliteiten die overbodig zijn zijn er niet meer... geen parsing...dus ook geen caching meer...

Ik wil even wat misverstanden recht zetten:


Waarom niet?... je templates bestaan gewoon uit php syntax, hier zijn alle variabelen vrijgegeven die jij hebt toegwezen.

waarom is dit niet mogelijk? je kunt gewoon andere templates includen in je template... ook hier zijn deze variabelen aanwezig.

ik nog minder en ook geen eval...

mij ook, deze is erdoorheen geslopen, zal hem zo snel mogelijk aanpassen.

Voorbeeld wordt er nu bij geplaatst, deze bevindt zich trouwens ook in de download

kan je ook gewoon:


doen...

@Lode
Kan ook... wat je wilt:)

Verder geen andere feedback meer? Dan mag ik ervanuit gaan dat iedereen voorzien is van voldoende informatie?

Op zich een goed idee omdat php idd al goed kan parsen. Maar is het ook mogelijk om for's enzo te doen? En whilen? If?

Btw, een template parser is voor een designer die geen raad weet met php of niet goed. Waarom zou je dan weer php gaan gebruiken voor de templates.

@Tommy
je kunt alles doen want je normaal in php ook kunt doen... dus ook z'n language constructs als for, while, if enz...


Stel dat dat zo is...waarom kan een designer dan wel in een nieuwe syntax een: {foreach from=$var key=foo item=bar}
html
{/foreach}
en niet in php:
foreach( $var as $foo => $bar ) {

}
meerwaarde daarvan ontgaat me even

*bump*
Zijn er nog op of aanmerkingen? Ook wacht ik nog op een reactie van de volgende personen:
Blanche, zijn de functionaliteiten en mogelijkheen je nu wel duidelijk?
Tommy, Zou je nog een reactie willen geven op mijn vraag?
ericbruggema, je hebt dus de beschikking over alle language constructs

Men is toch niet vergeten dat PHP zelf in principe al een template engine is? De enige toegevoegde waarde van Smarty is misschien het caching systeem, maar dat zou in TempLight gebouwd kunnen worden.

Welke functionaliteiten zijn er in Smarty te vinden die niet in PHP zitten?

Designers horen geen HTML en CSS te maken, daarvoor hebben we Online Programmers nodig... Designers moeten designen... Een Online Programmer die wel loopjes zou kunnen maken in Smarty en niet in PHP? Tuurlijk... Wat een onzin.

Het enige dat ik eigenlijk mis is een goed opgezette mogelijkheid om te cachen. Ik weet zeker dat Ypma dat er nog wel in gaat bouwen.

Grtz

@Esther
Bedankt voor je reactie. Je begrijpt precies wat ik heb willen bereiken met deze klasse. Een caching mogelijkheid zal er zeker nog wel inkomen. Echter is deze pas van meerwaarde bij grotere projecten. Voor kleinschalige websites zal ik het afraden om dat files openen, uitlezen en sluiten en wegschrijven toch voor de nodige vertraging zorgt.

@Ypma
Zodra er een database bij komt kijken is caching al meteen interessant. Uiteindelijk wordt bij een database request ook het filesysteem aangesproken... Behalve als de hele database in het geheugen staat en dan slaat cachen waarschijnlijk nergens op...

PHP heeft functies die niks met templates te maken hebben en die zorgen voor ernstige problemen met bouwen, debuggen en onderhouden van een website. Geef een programmeur een hamer en hij zal de boel voor je slopen. Alleen jammer dat dit nu net niet de bedoeling was...

Ik ben ooit gruwelijk op m'n bek gegaan met een prachtige PHP-template engine, maar die fout maak ik nu echt nooit meer! Smarty of XSLT worden nu gebruikt en men krijgt geen enkele, maar dan ook geen enkele mogelijkheid om met PHP-functies te klooien. Diegene die daar zelfs maar aan durft te denken wordt direct vanaf 11 hoog op straat geschopt!

Just another road to disaster...

@pgFrank
Ik ben dat totaal met je eens. Aand de andere kant kun je natuurlijk ook zeggen...schoenmaker blijf bij je leest. Waarom zou ik een designer me templates laten maken?
Hij hoort een html en css te maken... dat ik hem in me template dynamisch wil maken is mijn taak. Het is niet de fout van de Template Handler dat hij stuk kan, maar door de gebruiker. Iemand met kennis van zaken weet als het goed is waar hij mee bezig is.
Iets parsen om de reden dat me designer de website stuk kan maken vind ik totale onzin:)

Een template-engine wil je gebruiken voor je templates en niet voor je businesslogica. Wanneer het technisch mogelijk is dat er businesslogica in je templates komt, zal dat ook gebeuren. Ik spreek uit ervaring, helaas.

Dat heeft dus niks te maken met een designer die met dynamische html bezig is, maar alles met het scheiden van je businesslogica en presentatie. Ook een PHP-programmeur wordt met bv. Smarty of XSLT gedwongen om de businesslogica elders af te handelen, dat zal niet werken in de presentatielaag.

Dat er daarnaast ook nog eens minder stuk kan gaan, dat is weer mooi meegenomen.

@pgFrank
Be-aam ik... maar dan weer even wat stappen terug: Smarty weerlegt die programmeer-logica ook niet. Rest dus nog mijn veronderstelling dat deze Template Handler dezelfde funtionaliteiten biedt, maar dan sneller, als Smarty, ook al is het in princiepe appels met peren vergelijken.
Ik vind het template parsen idee totaal overbodig.

Ik heb een nieuwe versie geplaatst waar eerdere opmerkingen in verwerkt zijn. Tevens heb ik er een klasse bij gemaakt die, indien zo geconfigureerd, een compressie loslaat op de HTML output.

Mvg Michel Ypma