[php] vraagje voor gebruik templates

woensdag 9 juni 2004 07:59

Acties:

0 Henk 'm!

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

Ohja, deze werkt alleen met PHP5

PHP:

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

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

XML:

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

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

XML:

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

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

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

PHP:

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

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

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

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

woensdag 9 juni 2004 09:08

Acties:

0 Henk 'm!

Verwijderd

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

Ohja, deze werkt alleen met PHP5

...

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

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

...

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

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

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

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

Maar goed, dat kun je mij vast uitleggen

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

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

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

tbs is een object?

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

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

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

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

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

woensdag 9 juni 2004 09:44

Acties:

0 Henk 'm!

drm

f0pc0dert

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

En ik durf daar voor te wedden...

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

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

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

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

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

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

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

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

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

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

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

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

Mijn rode kleurtje heeft hier helemaal geen ruk mee te maken. Als ik niet had gewild dat jij je mening gegeven had, had ik je wel van het forum geschopt. Het probleem is dat je manier van discussieren niet uitnodigt tot verdere argumenten geven, want ik zie constant opmerkingen voorbijkomen die de indruk wekken dat iedereen die wat anders vindt dan jij achterlijk is. En als je dat niet bedoelt zou ik maar eens goed gaan kijken of je je punten niet eens een keertje op een andere manier duidelijk kan maken. Of wil je zeggen dat een opmerking als "Als je hieruit toch geen voordelen meer ziet, dan is mijn mening dat je het voordeel wilt negeren" wel uitnodigt tot discussieren

Misschien moet je gewoon eens leren accepteren dat er ook dingen zijn waar anderen een andere mening over hebben, ongeacht of jij dat begrijpt of niet. Dat is namelijk een heel volwassen iets, om dat in te zien.

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

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

* drm out

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

woensdag 9 juni 2004 10:25

Acties:

0 Henk 'm!

JayTaph

Portability is for canoes.

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

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

Voorbeeldjes:

code:

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

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

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

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

De Template:

code:

<!-- language_settings.tpl -->

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

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

<!-- end language_settings.tpl -->

Of een andere Template, zonder de phpcode aan te passen

code:

<!-- language_settings.tpl -->

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

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

<!-- end language_settings.tpl -->

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

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

Yo dawg, I heard you like posts so I posted below your post so you can post again.

woensdag 9 juni 2004 10:31

Acties:

0 Henk 'm!

Verwijderd

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

Maar goed...

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

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

woensdag 9 juni 2004 11:00

Acties:

0 Henk 'm!

Verwijderd

Nou, Smarty is traag, tbs is trager

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

Dit had de maker van tbs te zeggen

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

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

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

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

woensdag 9 juni 2004 11:14

Acties:

0 Henk 'm!

ripexx

bibs

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

Duh, er zijn wel meer goed text editors

Maar goed...

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

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

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

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

Ik heb inmiddels al aardig wat template enigines bekeken en zie gewoon dat er weinig verschillen zijn. De een kan net wat meer dan de ander, en een ander is weer sneller dan de een. Het is vooral lood om oud ijzer. Maar om nu te zeggen dat TBS sneller is dan PHP of meer functionaliteit heeft? Wellicht is de code wat eenvoudiger te lezen (subjectief

) en kan je het eenvoudiger aanpassen met een WYSIWYG editor. Maar wil je wel dat men zo'n ding gaat gebruiken. Ik moet er niet aandenken. Meestal bestaat de site dan uit meerdere templates die weer samengevoegd worden. Men past een deel aan en die editor gaat weer tags toevoegen, style elementen aanpassen en weet ik veel.

buit is binnen sukkel

woensdag 9 juni 2004 11:33

Acties:

0 Henk 'm!

RedRose

Icebear

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

Allereerst twee quotes die mijns inziens het belangrijkste zijn:

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

en:

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

Er moet een aantal dingen worden gescheiden:

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

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

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

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

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

Sundown Circus

woensdag 9 juni 2004 11:35

Acties:

0 Henk 'm!

RedRose

Icebear

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

Dat hangt er maar net van af hoe je met die templatesystemen omgaat.

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

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

Sundown Circus

woensdag 9 juni 2004 11:36

Acties:

0 Henk 'm!

Verwijderd

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

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

Al aangedragen voor toevoeging aan tbs...

[...]

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

Gebruik dan ook XSLT. Dat is gewoon het ding dat je "moet" gebruiken

Als ik de tijd krijg maak ik de overstap...

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

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

woensdag 9 juni 2004 11:56

Acties:

0 Henk 'm!

djluc

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

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

woensdag 9 juni 2004 12:02

Acties:

0 Henk 'm!

RedRose

Icebear

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

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

Sundown Circus

woensdag 9 juni 2004 12:30

Acties:

0 Henk 'm!

Verwijderd

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

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

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

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

woensdag 9 juni 2004 12:33

Acties:

0 Henk 'm!

RedRose

Icebear

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

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

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

Lees mijn post nog eens goed door dan.

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

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

Sundown Circus

woensdag 9 juni 2004 13:10

Acties:

0 Henk 'm!

Verwijderd

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

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

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

woensdag 9 juni 2004 13:18

Acties:

0 Henk 'm!

RedRose

Icebear

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

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

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

Sundown Circus

woensdag 9 juni 2004 13:49

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Laat, maar toch wil ik nog even reageren

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

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

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

Mja, ik zie geen voordeel van tbs tov php. Ik snap die template syntax van tbs ook niet helemaal op het eerste gezicht, block=tr

voorbeeld.some

. Bovendien, je geeft het een SQL string

Wat is dan echt het voordeel van tbs tov php? Maar goed, dat is allemaal al besproken dus daar hoef je verder ook niet op in te gaan

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

Dus jij wilt tbs gebruiken ipv omdat de makers van tbs zeggen dat smarty geen excuus was om een template engine te gebruiken

Misschien ligt het aan mij, maar ik vind het maar een kromme redenatie die kant noch wal raakt.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 9 juni 2004 14:25

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

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

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

. Dus als die persoon de accolades lelijk vindt zou je eigenlijk gewoon moeten zeggen dat ie pech heeft en dat ie het maar gewoon moet gebruiken

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

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

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 9 juni 2004 14:35

Acties:

0 Henk 'm!

RedRose

Icebear

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

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

Sundown Circus

woensdag 9 juni 2004 14:39

Acties:

0 Henk 'm!

Verwijderd

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

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

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

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

Mijn antwoord daar op:

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

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

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

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

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

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

woensdag 9 juni 2004 15:32

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

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

) schat ik ze niet veel hoger dan Zend, die hebben ook geen verstand van de zaken waar ze mee bezig zijn

.edit: toch maar wel een reactie geplaatst

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

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 9 juni 2004 16:02

Acties:

0 Henk 'm!

MisterData

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

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

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

XHTML is in feite XML hoor

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

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

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

woensdag 9 juni 2004 16:28

Acties:

0 Henk 'm!

stekkel

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

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

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

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

woensdag 9 juni 2004 17:20

Acties:

0 Henk 'm!

PrisonerOfPain

Omdat ik toch niets te doen had heb ik even een simpele benchmark geschreven

de 'test pc' (nog geen 400 Mhz) draaide met een 100% load

TBS:

PHP:

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

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

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

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

echo $end - $begin;
?>

Met de template

HTML:

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

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

PHP:

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

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

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

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

echo $end - $begin;
?>

En de template

PHP:

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

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

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

woensdag 9 juni 2004 19:12

Acties:

0 Henk 'm!

Verwijderd

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

Doe mij eens die benchmark? ik kom net echt veel verder dan 100% load en allebei even snel

Maar goed, ik heb geen benchmarkschrijfzin. Maar ik zou ze wel es willen vergelijken (om te zien of het verschil idd 15* is)

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

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

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

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

Euh, die cursus was alleen een simpele 'hoe XSLT ik'... DTD's en de hele XML zooi snap ik wel. (Ik heb nog ergens de gehele XML datastructuur op gezet, en die gebruiken ze nog steeds, ze zijn er erg blij mee

) Maar als je XML gaat voeren aan je browser dat er uit ziet als HTML of wat dan ook, dan krijg je problemen, tenminste, ik wel op op IE 6

woensdag 9 juni 2004 19:23

Acties:

0 Henk 'm!

PrisonerOfPain

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

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

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

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

Pagina: Vorige 1 2 Laatste

Reageer

Onderwerpen