[php] vraagje voor gebruik templates

[Y0ur1]

Ik gebruik een simpele template voor mijn website, dit doe is al volgt:
Ik heb een template bestand waar de html pagina in staat en de variabele content wordt aangeduidt door %...%. Waar ik vervolgens met '$template = str_replace("%...%", $de variabele, $template);' vervang door een variabele.

Alleen op deze manier kan ik maar 1 variabele kwijt waar een text in zit. Voor sommige delen wil ik functies of een include gebruiken, hoe los ik dat op? Dus dat hij bij %...% een functie kan gebruiken of iets kan includen. Alvast bedankt

[Spider.007]

Hoe bedoel je dat je een functie wil gebruiken? Wil je de output van een functie gebruiken als input voor de template? Dan kun je toch dit doen:

PHP:

$template = str_replace("%...%", deFunctie(), $template);

[Y0ur1]

en iets includen?

[-FoX-]

Waarom werk je niet met template systems zoals bijvoorbeeld Smarty?

[Y0ur1]

-FoX- schreef op 05 juni 2004 @ 20:00:
Waarom werk je niet met template systems zoals bijvoorbeeld Smarty?

omdat dit ook prima werkt, het hoeft niet zo uitgereid. Ik moet alleen nog weten hoe ik iets moet includen...

[Verwijderd]

Y0ur1 schreef op 05 juni 2004 @ 20:03:
[...]


omdat dit ook prima werkt, het hoeft niet zo uitgereid. Ik moet alleen nog weten hoe ik iets moet includen...

En als veel beter alternatief op Smart is er nog TinyButStrong

De reden dat ik deze vermeld is omdat hij dat gene doet wat je vraagt, je zou hem even kunnen ontleden.

Bovendien, TBS werkt met 1 enkel bestand en is makkelijk te gebruiken, op die manier zou je een hoop tijd kunnen besparen. Maar goed, of je het wil gebruiken moet je zelf weten

Kijk maar eens in de broncode van tbs, die heeft zo'n optie....

[Y0ur1]

Nogmaals weet niemand hoe ik dit even kan doen? Ik wil wel al die standaard templates gaan bekijken maar als iemand het even kan zeggen zou dat handiger zijn want ik wil gewoon mijn eigen systeem gebruiken.

[Skaah]

Verwijderd schreef op 05 juni 2004 @ 20:23:
[...]

En als veel beter alternatief op Smart is er nog TinyButStrong

De reden dat ik deze vermeld is omdat hij dat gene doet wat je vraagt, je zou hem even kunnen ontleden.

Bovendien, TBS werkt met 1 enkel bestand en is makkelijk te gebruiken, op die manier zou je een hoop tijd kunnen besparen. Maar goed, of je het wil gebruiken moet je zelf weten

Kijk maar eens in de broncode van tbs, die heeft zo'n optie....

offtopic:
OMG, weer TBS? Het is niet nodig om bij ieder topic je template engine aan te prijzen hoor.

Waarom zet je niet telkens een andere tekst tussen de procenttekens (%)? Dus bijv,

%titel% voor de titel, en %body% voor de inhoud van een pagina.

[-FoX-]

Waarom het wiel/warm water opnieuw uitvinden als er reeds bestaande (en waarschijnlijk betere) systemen beschikbaar zijn?!

[Y0ur1]

Skaah schreef op 05 juni 2004 @ 20:36:
[...]

offtopic:
OMG, weer TBS? Het is niet nodig om bij ieder topic je template engine aan te prijzen hoor.

Waarom zet je niet telkens een andere tekst tussen de procenttekens (%)? Dus bijv,

%titel% voor de titel, en %body% voor de inhoud van een pagina.

Dat doe ik ook. Alleen ik wil dat hij op de plek %bla% een pagina includen. Hoe kan ik dit doen?

[Y0ur1]

-FoX- schreef op 05 juni 2004 @ 20:37:
Waarom het wiel/warm water opnieuw uitvinden als er reeds bestaande (en waarschijnlijk betere) systemen beschikbaar zijn?!

Ik heb toch duidelijk aangegeven dat ik mijn eigen template systeem wil gebruiken? Het heeft dus geen zin om hier iedere keer weer over te beginnen.

[Shadowman]

Kun je dan niet gewoon in je include-bestand niet een paar functies/1 functie zetten die een string returnen en die dan gebruiken in je str_replace?

Als dat niet mogelijk is is het wel mogelijk om met een outputbuffer te gaan werken. (ob_*-functies). Ik vind deze functies alleen meer het omzeilen van het probleem dan het goed aan te pakken overigens.

[Y0ur1]

Shadowman schreef op 05 juni 2004 @ 20:49:
Kun je dan niet gewoon in je include-bestand niet een paar functies/1 functie zetten die een string returnen en die dan gebruiken in je str_replace?

Als dat niet mogelijk is is het wel mogelijk om met een outputbuffer te gaan werken. (ob_*-functies). Ik vind deze functies alleen meer het omzeilen van het probleem dan het goed aan te pakken overigens.

Ik heb de include nu in een functie gedaan maar hij include hem nu aan het begin van de pagina en nu op de plek waar ik dat graag wil.

[Shadowman]

Ik bedoel dus dat je in je include-bestand een functie maakt die een string returnt ipv dat hij data echo't.

[Y0ur1]

Shadowman schreef op 05 juni 2004 @ 20:53:
Ik bedoel dus dat je in je include-bestand een functie maakt die een string returnt ipv dat hij data echo't.

Nee dat gaat niet want het is een dynamische drop down box die uit de database komt en wat nog allerlei php aan vooraf gaat.

[Shadowman]

En hoezo zou je dan geen php in die functie kunnen uitvoeren?

ipv die echo gewoon $return_waarde.="data" gebruiken lijkt me toch voldoende .

Iig kun je neem ik aan wel gebruik maken van de output buffer van php (ob_start, etc).

[Y0ur1]

Shadowman schreef op 05 juni 2004 @ 20:59:
En hoezo zou je dan geen php in die functie kunnen uitvoeren?

ipv die echo gewoon $return_waarde.="data" gebruiken lijkt me toch voldoende .

Iig kun je neem ik aan wel gebruik maken van de output buffer van php (ob_start, etc).

Ik heb het zo opgeslost, maar bij iedere drol het toevoegen aan een variabele is niet echt mooie code maar het werkt wel. tnx voor de tip.

[ Voor 141% gewijzigd door Y0ur1 op 05-06-2004 22:19 ]

[Verwijderd]

Ok, je mag best eigenwijs zijn, maakt mij geen verschil

Maar als je mijn tip opvolgt en naar die website gaat, dan kun je het vragen aan de maker, die binnen een paar uur meestal reageert, hij heeft dit functie aanroep probleem gedaan in zn template engine, dus hij weet ook hoe dit moet.

Beetje buigzaamheid en je had dit al lang opgelost, dus hup, naar tbs en vragen...

Skaah schreef op 05 juni 2004 @ 20:36:

offtopic:
OMG, weer TBS? Het is niet nodig om bij ieder topic je template engine aan te prijzen hoor.

offtopic:
Dat is wel nodig, het is een "tekortkoming" van zo te zien bijna iedereen hier omdat een template engine nogal duidelijke voordelen biedt. Ik heb gelezen dat er hier argumenten over en weer gaan in een aantal topics. En ik kan alleen maar aanvoeren dat sinds de introductie van templates in mn code de overzichtelijkheid en aanpasbaarheid enorm gestegen is, en ik veel aanpassingen aan de ontwerper over kon laten zonder er zelf nog naar om te hoeven kijken. TBS is hier speciaal geschikt voor omdat er geen programmecode of echte logica in de template hoeft te komen zoals bij Smarty bijvoorbeeld wel het geval is.

En ik hoop dat je het niet letterlijk bedoelde, want de engine is van een fransman, niet van mij

[ Voor 7% gewijzigd door Verwijderd op 05-06-2004 21:57 ]

[Y0ur1]

*zucht* het is nu gelukt, bedankt voor de gene die mij hebben geholpen met mijn vraag.

[Shadowman]

Verwijderd schreef op 05 juni 2004 @ 21:55:
Ok, je mag best eigenwijs zijn, maakt mij geen verschil

Maar als je mijn tip opvolgt en naar die website gaat, dan kun je het vragen aan de maker, die binnen een paar uur meestal reageert, hij heeft dit functie aanroep probleem gedaan in zn template engine, dus hij weet ook hoe dit moet.

Beetje buigzaamheid en je had dit al lang opgelost, dus hup, naar tbs en vragen...

Soms is ervaring opdoen beter dan zomaar dingen van andere personen te gebruiken. Daarnaas hoeft de template engine die jij aanraad niet per definitie de beste te zijn.

Je mag trouwens ook wel een goede reden geven om die template-engine te gebruiken dan zo'n argument als het werkt makkelijk.

[NMe]

Is P&W niet sowieso bedoeld voor het zelf programmeren? Ik persoonlijk zou geen boodschap hebben aan allerlei componenten en third party scripts als ik als TS een vraag stel. Dan heb je namelijk een concreet probleem, en op dat probleem wil je antwoord hebben. Zoiets als een template systeem is heel erg persoonlijk wat betreft eisen. Mijn eigen template class heeft welgeteld 3 functies en 1 variabele, namelijk een constructor die een file inleest, en replace functie en een functie om de uiteindelijke string terug te geven. Die string is dan ook de enige variabele die ik nodig heb. Maar ik kan me goed voorstellen dat iemand anders iets wil hebben dat veel uitgebreider is.

Laat iedereen lekker zelf bepalen wat ze nodig hebben. Als iets zo simpel is als een template engine, dan kun je dat veel beter zelf doen. Kost amper tijd en dan zit er ook niets te veel of te weinig in.

[Verwijderd]

NMe84 schreef op 06 juni 2004 @ 00:38:
Is P&W niet sowieso bedoeld voor het zelf programmeren? Ik persoonlijk zou geen boodschap hebben aan allerlei componenten en third party scripts als ik als TS een vraag stel. Dan heb je namelijk een concreet probleem, en op dat probleem wil je antwoord hebben. Zoiets als een template systeem is heel erg persoonlijk wat betreft eisen. Mijn eigen template class heeft welgeteld 3 functies en 1 variabele, namelijk een constructor die een file inleest, en replace functie en een functie om de uiteindelijke string terug te geven. Die string is dan ook de enige variabele die ik nodig heb. Maar ik kan me goed voorstellen dat iemand anders iets wil hebben dat veel uitgebreider is.

Laat iedereen lekker zelf bepalen wat ze nodig hebben. Als iets zo simpel is als een template engine, dan kun je dat veel beter zelf doen. Kost amper tijd en dan zit er ook niets te veel of te weinig in.

Als de TS mijn link zou volgen wetende dat deze template engine zo'n functie heeft als waar hij naar vraagt (heb ik de tweede keer verteld) lijkt mij dat verstandig. Je zou hier mogelijk (en in dit geval zeker) van de ontwikkelaar tips kunnen krijgen, of zelfs hulp bij het oplossen van je vraagstuk. Ikzelf zou dat creatief gebruik maken van de raad die je krijgt noemen...

Gezien het ontbreken van zo'n vraag in het tbs forum, neem ik aan dat de vraag hier niet gesteld is. Nu is in dit geval de vraag hier opgelost, maar hij had wellicht al eerder opgelost kunnen worden in het andere forum.

Dus zo erg vondt ik mijn raad voor tbs niet...

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

[dusty]

-FoX- schreef op 05 juni 2004 @ 20:37:
Waarom het wiel/warm water opnieuw uitvinden als er reeds bestaande (en waarschijnlijk betere) systemen beschikbaar zijn?!

Waarom zou jij uberhaupt nog iets programmeren? Het meeste is toch al een keer gemaakt? bovendien zijn er veel betere programmeurs dan jou dus waarom zou jij nog proberen te programmeren?

Jouw houding is echt een houding van "Ik neem wel een oplossing van iemand anders, dan hoef ik zelf niets meer te doen" en "Ik copy/paste code van iemand anders en dan noem ik dat mijn eigen code". Als jij een echte programmeur in hart en nieren zou zijn zou je weten waarom hij het zelf wilt programmeren, dat jij dat blijkbaar niet weet waarom iemand dat zou willen doen, toont wat voor programmeur jij bent.

[dusty]

Y0ur1 schreef op 05 juni 2004 @ 22:20:
*zucht* het is nu gelukt, bedankt voor de gene die mij hebben geholpen met mijn vraag.

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

[Skaah]

Verwijderd schreef op 05 juni 2004 @ 21:55:

offtopic:
Dat is wel nodig, het is een "tekortkoming" van zo te zien bijna iedereen hier omdat een template engine nogal duidelijke voordelen biedt. Ik heb gelezen dat er hier argumenten over en weer gaan in een aantal topics. En ik kan alleen maar aanvoeren dat sinds de introductie van templates in mn code de overzichtelijkheid en aanpasbaarheid enorm gestegen is, en ik veel aanpassingen aan de ontwerper over kon laten zonder er zelf nog naar om te hoeven kijken. TBS is hier speciaal geschikt voor omdat er geen programmecode of echte logica in de template hoeft te komen zoals bij Smarty bijvoorbeeld wel het geval is.

En ik hoop dat je het niet letterlijk bedoelde, want de engine is van een fransman, niet van mij

Ik gebruik zelf ook een template engine, Smarty, waarmee ik de presentational logic van de buisness logic kan scheiden. Ik onderschrijf je opmerking dat code leesbaarder en aanpasbaarder wordt wanneer je templates gebruikt.

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.

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.

[-FoX-]

dusty schreef op 06 juni 2004 @ 01:45:
Waarom zou jij uberhaupt nog iets programmeren? Het meeste is toch al een keer gemaakt? bovendien zijn er veel betere programmeurs dan jou dus waarom zou jij nog proberen te programmeren?

Jouw houding is echt een houding van "Ik neem wel een oplossing van iemand anders, dan hoef ik zelf niets meer te doen" en "Ik copy/paste code van iemand anders en dan noem ik dat mijn eigen code". Als jij een echte programmeur in hart en nieren zou zijn zou je weten waarom hij het zelf wilt programmeren, dat jij dat blijkbaar niet weet waarom iemand dat zou willen doen, toont wat voor programmeur jij bent.

Wie ben jij om mij een copy/paste programmeur te noemen?

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!

Trouwens, de TS geeft in zijn openingspost nergens blijk van dat hij persé zelf een eigen template systeem wil schrijven. Hij wil enkel dezelfde functionaliteit bekomen. En had blijkbaar geen weet van de reeds bestaande systemen. En mijn mening hierover is dat je je beter kan bezighouden met reeds bestaande systemen, als je kennis over een subject nog niet zo ver gevorderd is.

[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>