[PHP] PHP HTML en grote userinterfaces. Hoe wel/niet?

[martijnve]

Ik heb de afgelopen tijd veel gewerkt aan (voor mijn doen) erg grote webapplicaties met veel pagina's met grote userinterfaces.

Nu valt het niet mee om deze code een beetje netjes te houden, het meeste echte werk wordt gedaan in functies en classes die ergens anders staan en dat is allemaal prima leesbaar en geordend maar ik krijg nu dus gigantische stukken php die eigenlijk niet meer doen dan gevulde html forms printen met wat if's ed er tussen. Erg lelijk dus en ook niet lekker onderhoudbaar.

Ik heb zitten kijken hoe dit beter kan en het beste wat ik tot nu toe heb kunnen bedenken is iets in deze richting: (versimpeld voorbeeld uit mijn eigen cms wat momenteel in aanbouw is, graag geen discussie/commentaar over het cms zelf)

PHP:

$menu = '
    <table class="options">
        <th colspan="4">Pagina Opties</th>
        <tr>
            <td>Pagina Naam:</td>
            <td><input type="text" name="name" value="?page_name?"></td>
            <td>Pagina volgorde:</td>
            <td>?up_button? ?down_button?</td>
        </tr><tr>
            <td>Sub-Pagina van:</td>
            <td>?parent_name? ?change_parent_button?</td>
            <td>Nieuwe Subpagina:</td>
            <td>?new_subpage_button?</td>
        </tr><tr>
            <td>?delete_page_button?</td>
            <td colspan="3" align="right">?save_page_button?</td>
        </tr>
    </table>
';
$replace['?page_name?']             = $_page['name'];
$replace['?up_button?']             = '<input type="submit" name="up" value="Omhoog">';
$replace['?down_button?']           = '<input type="submit" name="down" value="Naar Beneden">';
$replace['?parent_name?']           = $_pages[$_page['parent']]['name'];
$replace['?change_parent_button?']  = '<input type="submit" value="Verander" onclick="open_popup(\'popups/change_parent.php?page=' . $_page['id'] . '\');return false">';
$replace['?new_subpage_button?']    = '<input type="submit" value="Aanmaken" onclick="open_popup(\'popups/nieuwepagina.php?parent=' . $_page['id'] . '\');return false">';
$replace['?delete_page_button?']    = '<input type="submit" name="delete" value="Verwijder" OnClick="return confirm(\'Weet u zeker dat u deze pagina wil verwijderen?\')">';
$replace['?save_page_button?']      = '<input type="submit" name="save" value="Opslaan">';

if (!is_bovenste_pagina) $replace['?up_button?'] = "";
if (!is_onderste_pagina) $replace['?down_button?'] = "";

echo str_replace(array_keys($replace), $replace, $menu);

Wat ik hier dus doe is eerst alle html structuur in een variabele stoppen en dan de knopppen en veldwaardes er in replacen. Dit heeft als vordeel dat het overzichtelijker is en later makkelijker aan te passen als er functies bij moetten komen of het design verandert wordt.

Nu is mijn vraag hoe lossen jullie dit op?

Heb wat rond zitten browsen maar heb over dit onderwerp waar m.i. veel over te zeggen valt nog geen discussies gevonden.

[orf]

Er zijn heel veel discussies te vinden over template engines. Dat is waar je naar opzoek lijkt te zijn.
Smarty is het bekendste voorbeeld.

[ChessSpider]

Kijk even naar Smarty
Een templatesysteem warmee je HTML en PHP volledig van elkaar gescheiden kan houden.

[M55]

Als je dan toch bezig bent, check even het MVC principe ;-) Smarty gebruiken voor je view is een goed idee.

[ Voor 23% gewijzigd door M55 op 16-04-2008 19:34 ]

[CodeCaster]

Smarty is wellicht wat overkill, ik vind zelf TemplatePower een stuk makkelijker om te leren en in gebruik.

[martijnve]

M55 schreef op woensdag 16 april 2008 @ 19:34:
Als je dan toch bezig bent, check even het MVC principe ;-) Smarty gebruiken voor je view is een goed idee.

Ik ben bekend met MVC en pas dit als ik echte programma's maak ook goed toe alleen met php/javascript/html wordt de view dan alsnog erg lelijk als je niets bijzonders doet.

CodeCaster schreef op woensdag 16 april 2008 @ 19:43:
Smarty is wellicht wat overkill, ik vind zelf TemplatePower een stuk makkelijker om te leren en in gebruik.

Ziet er goed uit zal er eens mee gaan spelen.
Had er niet aan gedacht om hier een template engine voor te gaan gebruiken maar deze ziet er wel lekker simpel uit.

[Bigs]

Ik zou zelf eerder voor Smarty kiezen.. bij grote applicaties kun je die flexibiliteit wel gebruiken en je hebt het zo door. Je hoeft zelf nog maar een paar regeltjes te schrijven om een mooie MVC-basis te leggen met Smary.

In ieder geval moet je snel aan een template engine als ik je code zo zie

[trinite_t]

Hier al meer dan twee jaar smarty gebruiker. Erg goede en snelle engine. In het begin een beetje mee moeten stoeien, maar ik bouw nu geen website meer zonder, hoe klein de site ook is.
De basis is erg makkelijk, wil je meer, dan zijn er goed leesbare voorbeelden voor eigen modules.

[Brakkie]

Lees eens wat topics door uit onderstaande zoekopdracht en lees specifiek de replies eens die php als template engine aanraden.

http://gathering.tweakers...rchtimeout%5D=30#hitstart

En dat je met smarty een goede basis hebt voor een site die opgebouwd is volgens MVC vind ik onzin, dat zou impliceren een site die gebouwd is volgens het MVC pattern het meest afhankelijk is van de manier waarop je je views bouwt en laat parsen. Het is een onderdeel maar zeker niet 1 van de belangrijkste.

Beetje luie reply misschien maar de kennis die al verzameld is op GOT over dit onderwerp zou ik zeker even lezen

CodeCaster schreef op woensdag 16 april 2008 @ 19:43:
Smarty is wellicht wat overkill, ik vind zelf TemplatePower een stuk makkelijker om te leren en in gebruik.

Zijn er ook nieuwere release dan 1 uit 2003? Het hoeft niks te zeggen maar ik vind het altijd wel relaxed als er nog actief ontwikkeld wordt aan een project. Alhoewel je het natuurlijk zelf naar php5 kan omzetten.

[ Voor 29% gewijzigd door Brakkie op 16-04-2008 20:49 ]

[Verwijderd]

Het grootste voordeel van Smarty boven zuivere PHP code, is wat mij betreft de syntax.

code:

<?php nl2br ( htmlentities ( ucfirst ( $bla ? $bla : 'default' ) ) ) ?>

Versus

code:

{$bla|default:'default'|ucfirst|escape|nl2br}

De pipe tekens zorgen ervoor dat je van links naar rechts kunt lezen wat er met je output gebeurt. Dat vind ik prettig, en veel duidelijker dan functies die je "van binnen naar buiten" moet lezen. Bovendien hoef je niet overal te checken of waarden wel geset zijn. In Smarty wordt een foreach blok gewoon genegeerd als de from parameter geen waarde heeft. In PHP code moet je dan toch weer extra moelijk gaan doen.

Maar an sich is het inderdaad wel het belangrijkst dat je je applicaties zo schrijft dat in de presentation layer er niet meer met data gegoocheld wordt. Hoe je het doet maakt verder niet eens zoveel uit. Zolang er maar niet zaken als while ( $row = mysql_fetch_assoc () ) op zulke plaatsen voorkomen

[GREENSKiN]

Na veel wikken en wegen gebruik ik een bijzonder uitgebreide, maar bij mij al goed bekende, template engine... PHP

Mijn methode is gebaseerd op deze: http://www.massassi.com/php/articles/template_engines/

Het zorgt voor een nette scheiding tussen presentatie en logica terwijl je de HTML-kneed kracht van PHP houdt zonder dat je weer één of andere extra (template) taal moet leren.

[Verwijderd]

Nee. Het zorgt er niet voor. Jij moet ervoor zorgen. Weet je heel zeker dat je niet nog wat database calls wilt doen in zo'n template?

Verder doet dat verhaal een beetje afbreuk aan zichzelf. Hij komt toch weer met een templatesysteem, maar hey, het is PHP code, dus ken je het al. Dat is onzin. Ik vertel daarnet al dat PHP leuk en aardig is, maar het grootste voordeel van Smarty is dus de leesbaardere syntax. Geen geklooi met haakjes en nesting als je meerdere "filters" gebruikt. Overigens vertaalt Smarty de templates naar PHP code. De enige overhead wat dat betreft zit hem in het laden van de class, en het controleren of de gecachete PHP files nieuwer zijn dan de Smarty templates.

Overigens vind ik wel dat je pas aan dit soort engines moet denken als je een serieuze applicatie gaat schrijven. Ik heb nog altijd tal van utility scriptjes voor bijvoorbeeld cron jobs die natuurlijk alle output genereren tussen de business logic. Voor je applicatie is het grote punt dat je zelf je best moet doen om functionaliteit en presentatie te scheiden.

Als je bijvoorbeeld een MVC pattern gebruikt, moet je ervoor zorgen dat je databaseafhandeling niet in de controllers of views gebeurt. Dat zou nogal belachelijk zijn. Dat gebeurt niet vanzelf, zo'n scheiding, dat moet je leren. En daar komt de catch: je moet jezelf aanleren om in te zien wanneer je wat moet gebruiken. Er is nog steeds geen magische rode knop die een applicatie voor je genereert.

[neothor]

GREENSKiN schreef op donderdag 17 april 2008 @ 01:18:
Het zorgt voor een nette scheiding tussen presentatie en logica terwijl je de HTML-kneed kracht van PHP houdt zonder dat je weer één of andere extra (template) taal moet leren.

Je moet met smarty idd even leren hoe het werkt maar als je php kent zal je er zeker geen moeite mee hebben. Daarbij zijn er een tutorials om op gang te komen.

[GREENSKiN]

Verwijderd schreef op donderdag 17 april 2008 @ 07:46:
Nee. Het zorgt er niet voor. Jij moet ervoor zorgen. Weet je heel zeker dat je niet nog wat database calls wilt doen in zo'n template?

Gebruik maken van een template systeem is geen vervanging van gedegen software ontwerp. Als je dirty tricks uit wilt halen is er weinig technologie die je tegen jezelf kan beschermen.

Ik zie absoluut pro's aan het gebruik van Smarty, maar ik zie ook cons. Voor mij is de belangrijkste reden dat het weer een extra taal is met haar eigen eigenaardigheden. Een tweede nadeel vind ik dat je weer een extra laag(je) complexiteit in je code hebt. Less is more.

Een voordeel van Smarty is de eenvoudigere syntax waardoor je de documenten eenvoudiger naar een simpele HTML-klopper kan sturen. Let wel, ik verwacht niet dat die persoon met Smarty filters gaat werken. Het gebruik van een escape filter in het voorbeeld van Cheatah betekend dat de template bouwer kennis moet hebben van het format van de achterliggende data, en wat escapen van data überhaupt is. Leaky abstractions.

Gezegd, een oncharmant voorbeeld van een van mijn templates ziet er bijvoorbeeld zo uit:

code:

<div class="highlightElement">
    <div class="more"><a href="/news">&gt; more</a></div>
    <h2>In the media</h2>
    <ul>
        <?php foreach ($resources as $resource) {
            $title = $resource->title;
            if (trim($resource->source != '')) {
                $title = $resource->source . ', ' . formatDate($resource->publishDate, 'shortmonth_noyear');
            }
            html_printf('<li><a href="%s">%s</a>', $resource->getURL(), $title);
        }
        ?>
    </ul>
</div>

Ja! PHP tussen HTML. Waarom? Deze code is puur presentatie. Gegeven een array van resources, geef me het juiste blokje HTML. Zoals Brian al mooi verwoord, het gaat niet om de scheiding van PHP en HTML maar om de scheiding tussen presentatie en business logic. Ik wil toch echt in m'n template die handige functie kunnen aanroepen die van een array objecten een HTML selector maakt.

[Saven]

Smarty is misschien ook wat té, dan kun je wellicht Template Lite gebruiken
Werkt zo goed als hetzelfde als Smarty, maar dan iets minder opties, maar wel een stuk sneller

[!null]

Ben ook wel tevreden met smarty, ik vind het alleen jammer dat je persee een template van een file moet laden. Die keuze is natuurlijk wel verklaarbaar, maar het was toch leuker geweest mocht de template ook uit het geheugen komen. (dat was handig geweest met een database erachter)

[orf]

@GreenSky: http://www.smarty.net/manual/en/templates.from.elsewhere.php

[Kwastie]

Ik heb zelf een maand geleden een klasse geschreven voor dit soort gein, maar hij is echt far from perfect.
Zo is het nog het niet geheel mogelijk om je template en php volledig te scheiden als je bijv. als je een loop hebt, moet er een stukje html in omdat anders de opmaak niet mooi is. Ik zoek trouwens nog een 'mooie' oplossing voor dit probleem, ik heb wel een oplossing maar dan kan ik net zo goed html gebruiken door mijn php. iemand een oplossing ??

Een groot nadeel van een template engine is dat er vrij veel tijd in gaat zitten + het maak je webapplicatie langzamer..

zelf ben ik niet écht fan van smarty, dit omdat ik weer tijd in moet steken om die 'taal' te leren, heb daarom mijn eigen template ding

[Verwijderd]

Kwastie schreef op zaterdag 19 april 2008 @ 19:57:

zelf ben ik niet écht fan van smarty, dit omdat ik weer tijd in moet steken om die 'taal' te leren, heb daarom mijn eigen template ding

Die je nog meer tijd kost, en gegarandeerd minder snel, minder goed en minder "bewezen" is.

[Kwastie]

Verwijderd schreef op zaterdag 19 april 2008 @ 20:05:
[...]

Die je nog meer tijd kost, en gegarandeerd minder snel, minder goed en minder "bewezen" is.

Valt reuze mee, ik heb deze klasse in z'on 2 a 3 uur gescherven, ik hoef dus niet mijn 'code' stijl aan te passen, zoals je bij smarty wel meot gaan doen.

Ik hoef nu verder mijn 'code' stijl bijna niet te veranderen, alleen moet ik nu variable 'laten' parsen. (wat maar 1 commmando is eigelijk + aan het eind de pagina laten zien)

Over de snelheid kan ik niet zoveel zeggen eigelijk, ik merk eigelijk niet dat hij trager is dan 'normaal'. Mischien is er wel een verschil, dat zal zeker wel zijn. Maar het niet direct merkbaar. (jij durft trouwens te beweren dat smarty niet vertraagd ?)

wil binnenkort ook nog een 'cache extentie' maken, kijken of hij dan nog wat sneller word , technisch gezien zou hij dan alleen maar de pagina te hoeven laden.. en dus niet steeds op te bouwen

[ Voor 41% gewijzigd door Kwastie op 19-04-2008 21:08 ]

[orf]

Valt reuze mee, ik heb deze klasse in z'on 2 a 3 uur gescherven, ik kan ongeveer hetzelfde als smarty alleen loops willen nog niet gescheiden..

Dat is behoorlijk knap. Kun je includen, modifiers en plugins gebruiken en daarnaast ook nog eens compilen? En hoe is de snelheid?

[BarôZZa]

Dat is toch het hele punt niet? Een simpel templatesysteem kan je gemakkelijk zelf maken.
Sure, het zal vast niet alle opties van Smarty ondersteunen, maar als je die uberhaubt niet hoeft te gebruiken, dan is het imo geen probleem. Als je binnen een paar uur een perfect werkend, op maat gemaakt systeem weet te maken, dan is dat toch echt wel de moeite waard. Dan zou ik dat ook liever doen in plaats van me te verdiepen in Smarty.

[orf]

Maar dan heb je nog steeds een systeem dat trager is (geen compiler), minder opties die je in de toekomst wellicht wél nodig hebt en geen 'bewezen' systeem zoals Cheatah al aangaf.

[Fuzzillogic]

Waarom lees ik XSLT nergens terug hier? Misschien wat zwaar om mee te beginnen, maar het is tenminste een echte standaard, en de opgedane kennis kun je ook nog gebruiken als je uiteindelijk genoeg krijgt van PHP.

[curry684]

Verwijderd schreef op zaterdag 19 april 2008 @ 20:05:
[...]

Die je nog meer tijd kost, en gegarandeerd minder snel, minder goed en minder "bewezen" is.

Hoewel ik fervent gebruiker van Smarty ben vind ik de voordelen die je aanhaalt niet echt overtuigend. Voor PHP-programmeurs is PHP een fantastische template engine met alle mogelijke flexibiliteit, die ik waar nodig ook graag gebruik. Smarty en andere template engines zijn met name interessant als je met meerdere ontwikkelaars aan verschillende onderdelen werkt (voor HTML'ers is Smarty veel intuitiever en veiliger dan PHP) of met 'onbekende' template developers werkt (zoals in redistributables).

Smarty gebruiken binnen een 1 persoonsproject is niet per se een goede oplossing en lost in principe geen problemen op die je niet ook met PHP als template engine simpel op kunt lossen.

[Verwijderd]

curry684 schreef op zaterdag 19 april 2008 @ 22:27:

Smarty gebruiken binnen een 1 persoonsproject is niet per se een goede oplossing en lost in principe geen problemen op die je niet ook met PHP als template engine simpel op kunt lossen.

Dat bedoelde ik inderdaad al. Het belangrijkste is dat de programmeur handig leert programmeren. Of hij daarbij Smarty wil gebruiken moet hij zelf weten. Maar als mensen dan "in 3 uur" een eigen template engine gaan schrijven, denk ik dat ze die 3 uur beter hadden kunnen besteden.

Fuzzillogic schreef op zaterdag 19 april 2008 @ 22:06:
Waarom lees ik XSLT nergens terug hier? Misschien wat zwaar om mee te beginnen, maar het is tenminste een echte standaard, en de opgedane kennis kun je ook nog gebruiken als je uiteindelijk genoeg krijgt van PHP.

XSLT heeft hier niets te maken. Voor XSLT moet je eerst een XML document genereren. Ga je dat doen met PHP of met Smarty?

[BarôZZa]

Net alsof iemand binnen 3 uur Smarty heeft geleerd, geïnstalleerd en de templates heeft aangepast.

Overigens zal gewoon PHP natuurlijk altijd nog uitgebreider zijn dan Smarty. En is bij éénpersoonsprojecten het nou geen enorme ramp als er wat php tussen de html staat.

Ik heb gewoon een layout.php die ik include vanuit andere php bestanden. Dat is gewoon een html bestand met op een paar plekken wat php om de gegevens weer te geven. Het zal ongetwijfeld iets trager zijn, maar ik denk niet dat die milliseconden je op zullen vallen.

[Fuzzillogic]

Verwijderd schreef op zaterdag 19 april 2008 @ 22:50:
[...]
XSLT heeft hier niets te maken. Voor XSLT moet je eerst een XML document genereren. Ga je dat doen met PHP of met Smarty?

Je moet een XMLDOM genereren ja. En laat dat nu prima te doen zijn in PHP. Je kunt je database-records en overige zaken echt zonder probleem in een XML-DOM-object kieperen, en die daarna door XSLT halen. Op werk hebben we een in-house oplossing hiervoor, maar er zijn vast al kant-en-klaar-oplossingen. XSL is dan best wel fijn!

[geez]

Om even rechtstreeks te reageren op je stuk code in de TS. Persoonlijk haal ik grote lappen HTML buiten de PHP tags:

PHP:

<?php if ($blabla) { ?>
<form>
<meerhtmlcode>
<input type="text" value="<?=$waarde?>">
</form>
<?php } ?>

Bijvoorbeeld. Je houd het beter gescheiden en hoeft zo niet te prutsen met escapen van quotes (vooral als je nog eens javascript ertussen hebt staan) en je IDE highlight de HTML zoals het hoort. Zelf ben ik niet zo'n fan van libraries en engines. Puur omdat het bijna altijd functionaliteit (althans extra code) meebrengt die ik niet gebruik, wat uiteindelijk het geheel minder snel maakt.

[Fuzzillogic]

geez schreef op zondag 20 april 2008 @ 00:00:
Om even rechtstreeks te reageren op je stuk code in de TS. Persoonlijk haal ik grote lappen HTML buiten de PHP tags:

PHP:

<?php if ($blabla) { ?>
<form>
<meerhtmlcode>
<input type="text" value="<?=$waarde?>">
</form>
<?php } ?>

Bijvoorbeeld. Je houd het beter gescheiden en hoeft zo niet te prutsen met escapen van quotes (vooral als je nog eens javascript ertussen hebt staan) en je IDE highlight de HTML zoals het hoort. Zelf ben ik niet zo'n fan van libraries en engines. Puur omdat het bijna altijd functionaliteit (althans extra code) meebrengt die ik niet gebruik, wat uiteindelijk het geheel minder snel maakt.

Als snelheid een issue is dan koop je een snellere CPU of een 2de server. Dat is veel goedkoper dan telkens het wiel opnieuw uitvinden. Geen templating engine gebruiken is geen optie als je serieus aan de slag gaat.

[Verwijderd]

Fuzzillogic schreef op zondag 20 april 2008 @ 00:29:

Als snelheid een issue is dan koop je een snellere CPU of een 2de server. Dat is veel goedkoper dan telkens het wiel opnieuw uitvinden. Geen templating engine gebruiken is geen optie als je serieus aan de slag gaat.

Gelukkig was je me voor. Het gaat hier duidelijk niet om hobbyprojectjes, het gaat om keihard de kosten drukken door minder tijd kwijt te zijn aan gepruts in de marges.

Overigens kan ik je wel begrijpen als het gaat om XSLT uitvoeren op een in-memory DOM structuur. Dat is echter wel een heel andere benadering dan een "reguliere" template engine. Ik denk echter wel dat het pas interessant wordt als je interoperabiliteit nodig hebt. Als je output ook gaat gebruiken voor feeds, exports in andere formaten en dat soort dingen is XSLT ongetwijfeld interessant

---

Overigens kan ik voor de overige personen intussen gerust even melden dat het vorige bedrijf waar ik werkte Smarty heeft ingezet voor een systeem met 943 template bestanden en 1315 CSS bestanden (waarvan een aantal gegenereerd, soms ook met Smarty). Gewoon om even aan te geven over welke schaal we het (volgens mij) hebben. Er is geen seconde verloren gegaan met kijken of de boel performt. Het performt prima. Overigens was dat hele gebeuren gebouwd en onderhouden door 2 personen.

[Fuzzillogic]

Verwijderd schreef op zondag 20 april 2008 @ 00:41:
[...]
Overigens kan ik je wel begrijpen als het gaat om XSLT uitvoeren op een in-memory DOM structuur. Dat is echter wel een heel andere benadering dan een "reguliere" template engine. Ik denk echter wel dat het pas interessant wordt als je interoperabiliteit nodig hebt. Als je output ook gaat gebruiken voor feeds, exports in andere formaten en dat soort dingen is XSLT ongetwijfeld interessant

Ik heb Smarty nooit gebruikt, dus een goed vergelijk tussen Smarty en andere engines kan ik niet geven. Wij gebruik XSLT gewoon voor HTML. Geen enkel probleem. Het is echt niet alleen voor XML geschikt.

XSLT is krachtig genoeg om je datamodel en de weergave daarvan mooi gescheiden te houden, beter nog dan Smarty, als ik dat zo even vluchtig bekijk. Wellicht word je er ook meer toe gedwongen met XSLT, maar dat is vaak alleen maar beter voor de onderhoudbaarheid van code.

[Verwijderd]

Fuzzillogic schreef op zondag 20 april 2008 @ 00:49:

XSLT is krachtig genoeg om je datamodel en de weergave daarvan mooi gescheiden te houden, beter nog dan Smarty, als ik dat zo even vluchtig bekijk. Wellicht wordt je er ook meer toe gedwongen met XSLT, maar dat is vaak alleen maar beter voor de onderhoudbaarheid van code.

Bij het soort applicaties is het natuurlijk al vanzelfsprekend dat de code zo is geschreven dat alle waarden op een bepaalde manier wordt verzameld alvorens wordt gepoogd het weer te geven. Volgens mij hoeft wat dat betreft nergens aan de code te zien zijn wat voor outputmethode gebruikt wordt. Bij bijvoorbeeld Smarty (ik gebruik ook weleens PHP templates) is het zo dat je eigenlijk niet veel meer doet dan een array met gegevens doorgeven aan de engine. Dat zou bij geen enkele andere methode enorm anders moeten zijn. Als je een DOM structuur doorgeeft aan een XSLT processor, zal dat ook zuiver om "gegevens" gaan, hoop ik

[Kwastie]

@Cheatah

Het gaat bij mijn klasse niet om een 'template engine' maar een template parser. Wat hij eigelijk doet is html & php gescheiden van elkaar houden. Het heeft mij zo'n 3 uur gekost om een simpele template parser te maken.

Simpel gezegt wat hij doet is:
- kijk of voor dat bestand een template aanwezig is.
- ja/nee (nee geeft hij een error, en stopt het script)
- ja, dan leest hij het bestand, en vervangd vervolgens de 'marker' door de ingestelde waarde.
- pagina word weergegeven.

niets geen 'smarty' nee gewoon lekker simpel, hij bereikt precies hetzelfde, nouja hetzelfde.. hij bereikt wat ik nodig vind dat hij bereikt

(hij is natuurlijk niet pefect, en heeft lang niet alle functies die smarty wel heeft, maar deze ben ik ook niet nodig)

[ Voor 5% gewijzigd door Kwastie op 20-04-2008 01:26 ]

[!null]

orf schreef op zaterdag 19 april 2008 @ 19:18:
@GreenSky: http://www.smarty.net/manual/en/templates.from.elsewhere.php

Waarom heb ik dit niet kunnen vinden? Bedankt iig!

[Confusion]

Fuzzillogic schreef op zondag 20 april 2008 @ 00:49:
Ik heb Smarty nooit gebruikt, dus een goed vergelijk tussen Smarty en andere engines kan ik niet geven. Wij gebruik XSLT gewoon voor HTML. Geen enkel probleem. Het is echt niet alleen voor XML geschikt.

Ik vind een <vul templating engine in> template + een stel variabelen die je daar aan meegeeft een stuk overzichtelijker dan een onzichtbaar opgebouwde DOM die vervolgens met XSL wordt getransformeerd. Als ik een bug in een DOM+XSLT aan het zoeken ben, ben ik altijd langer bezig dan wanneer ik een bug in template+variabelen zoek.

Daarnaast snapt iedere developer hoe templating werkt en hoe je het kan gebruiken, terwijl XSLT's bouwen niet voor iedereen tot de mogelijkheden behoort.

[TheBorg]

Ik ben het met Kwastie eens. Een template parser i.p.v. engine is vaak voldoende, en dat hoeft inderdaad niet ingewikkeld te zijn. Bijv uit de tutorial Building a Template Parser Class with PHP, Part I:

PHP:

<?php   
    class templateParser {

        var $output;

        function templateParser($templateFile='default_template.htm')
        {
            (file_exists($templateFile))?$this->output=file_get_contents($templateFile):die ('Error:Template file '.$templateFile.' not found');
        }

        function parseTemplate($tags=array())
        {
            if(count($tags)>0)
            {
                foreach($tags as $tag=>$data)
                {
                    $data=(file_exists($data))?$this->parseFile($data):$data;
                    $this->output=str_replace('{'.$tag.'}',$data,$this->output);
                }
            }
            else
            {
                die('Error: No tags were provided for replacement');
            }
        }

        function parseFile($file)
        {
            ob_start();
            include($file);
            $content=ob_get_contents();
            ob_end_clean();

            return $content;
        }

        function display()
        {
            return $this->output;
        }
    }
?>

Er zitten wat haken en ogen aan de code maar het gaat om het voorbeeld. Het enige wat het doet is een tag in de vorm {sometag} vervangen in de template. Dit is voldoende om PHP en HTML volledig van elkaar te scheiden en het probleem van TS is daarmee opgelost.

[Brakkie]

Dit is voldoende om PHP en HTML volledig van elkaar te scheiden en het probleem van TS is daarmee opgelost.

"PHP: Hypertext Preprocessor"

Als het trouwens gaat om het bouwen van forms voor php applicaties (wat de topicstarter volgens mij wil) zijn daar ook een aantal handige opties voor beschikbaar. Zo kan je met Pear::HTML_QuickForm heel snel formuliertjes in elkaar draaien. Inclusief validatie e.d. Dat heeft dan ook wel weer een kleine leercurve maar het is voor mij heel erg bruikbaar geweest tijdens het bouwen van een cms met veel forms.