Aparte header voor ingelogde gebruikers in tpl engine

[dylanvana]

Ik maak gebruik van RainTPL template engine om mijn logica en datapresentatie te scheiden. Nu loop ik alleen tegen een probleem waar ik de "beste" oplossing voor zoek.

Ik heb nu een pagina die ik voor het gemak "helloworld" noem. Hierbij hoort een helloworld template die vervolgens een header template en footer template aanroept. Nu heb ik in de header een check gemaakt zo iets als

code:

{if="$logged_in == true"}
 {include="logged_in_header"}
{else}
 {include="not_logged_in_header"}
{/if}

En nu komt het probleem. Ik wil in de logged_in_header een aantal variabelen weergeven zoals gebruikersnaam, email enz. Maar deze moet ik dus ergens declareren en ik wil niet op elke pagina eerst 10 regels copy pasten die kijkt of iemand is ingelogd en vervolgens wat variabelen ophaalt/genereert. Dit wil ik door de template logged_in_header laten doen maar dit kan dus niet omdat dit alleen datapresentatie mag bevatten.

Hoe los ik dit het best op? Op dit moment ziet mijn code er dan zo uit (wat ik dus niet wil).

code:

<?php
    
    include("inc/raintpl.init.php");
    $tpl = new RainTPL;
    
    include("inc/authentication.class.php");
    $auth = new Authentication;
    
    $welcome = "Welkom op mijn eerste Hello World pagina met RainTPL :)";
    
    $tpl->assign("welcome", $welcome);
    
    $auth->assignTplUserVars();
    
    $tpl->draw("helloworld");

?>

Zoals je ziet $auth->assignTplUserVars() is dus mijn dirty work around

code:

    public function assignTplUserVars()
    {
        global $tpl;
        $this->user = "dylan";
        $tpl->assign("user", $this->user);
    }

Hoe zorg ik ervoor dat ik niet overal $auth->assignTplUserVars() hoef aan de roepen om variabelen aan te maken die in de logged_in_header template thuis horen.

[NMe]

Waarom zou je dat niet willen? Dat lijkt me zo'n beetje de netste manier om dit te doen. Of eventueel ergens een globale handler die hetzelfde doet, maar of je nu een extra include doet of dat je die call zelf maakt lijkt me weinig verschil maken.

[dylanvana]

Ik wil dit liever niet omdat ik dan op elke pagina $auth->assignTplUserVars() moet aanroepen om te kijken of iemand is ingelogd zo ja haal wat variabelen op om in logged_in_header template te zetten. Ik had liever gehoopt dat er een manier was om een aparte PHP pagina aan een template toe te wijzen zodat bij het aanroepen van logged_in_header de template automatisch weet dat er nog een bijbehorend PHP bestand hoort die vervolgens doet wat $auth->assignTplUserVars() doet.

Mijn excuses als mijn uitleg onduidelijk is Ik vind het lastig om te verwoorden.

iig bedankt voor je reactie

[kwaakvaak_v2]

dylanvana schreef op maandag 20 januari 2014 @ 11:54:
Ik had liever gehoopt dat er een manier was om een aparte PHP pagina aan een template toe te wijzen zodat bij het aanroepen van logged_in_header de template automatisch weet dat er nog een bijbehorend PHP bestand hoort die vervolgens doet wat $auth->assignTplUserVars() doet.

Dat is een global handler dus, maar daar voorziet raintpl uit de doos niet in, dat wordt dus zelf maken of een template engine zoeken die je wat makkelijker kan extenden met functies (twig, smarty3 etc)

[dylanvana]

Ik heb Gegoogled op "Smarty global handler" en "Twig global handler" maar ik kom helaas niets tegen. Heb jij misschien een voorbeeld voor mij?

En wat als ik het bij RainTPL wil houden, wat moet ik dan zelf maken? Moet ik de RainTPL class aanpassen en een nieuwe functie (constructor maybe?) toevoegen die deze gegevens ophaalt?

[kwaakvaak_v2]

http://twig.sensiolabs.org/doc/advanced.html#globals, of als je het in een functie wilt doen http://twig.sensiolabs.org/doc/advanced.html#functions

En anders moet je idd de raintpl class extenden en die laden in je script. Hoe je dat moet doen ga ik je niet uitleggen, dat lijkt mij basis php kennis.

[dylanvana]

kwaakvaak_v2 schreef op maandag 20 januari 2014 @ 13:46:
http://twig.sensiolabs.org/doc/advanced.html#globals, of als je het in een functie wilt doen http://twig.sensiolabs.org/doc/advanced.html#functions

En anders moet je idd de raintpl class extenden en die laden in je script. Hoe je dat moet doen ga ik je niet uitleggen, dat lijkt mij basis php kennis.

Oke thanks, denk dat ik toch maar RainTPL aanpas

Bedankt allen.

[NMe]

kwaakvaak_v2 schreef op maandag 20 januari 2014 @ 13:46:
http://twig.sensiolabs.org/doc/advanced.html#globals, of als je het in een functie wilt doen http://twig.sensiolabs.org/doc/advanced.html#functions

Dat is niet helemaal wat ik bedoelde met een globale handler. Uitgaande van een MVC-situatie heb je een view (je template) en een controller (je bijbehorende PHP-code). Je zou ervoor kunnen kiezen om voordat je CMS de juiste controller inlaadt, hij eerst een andere "globale" controller laadt. Wat uiteraard afhankelijk is van hoe je CMS/framework opgezet is.

Heb je je MVC iets netter geïmplementeerd met classes, dan zou je je controller-class af kunnen leiden van een generieke class waarin je deze functie definieert en aanroept, maar in dat geval zul je waarschijnlijk alsnog een extra call nodig hebben: return parent::functienaam($parameters);

Met vrijwel elke methode heb je hoe dan ook ergens een extra regel code staan. De vraag is waar die regel uiteindelijk terecht komt.

[Cartman!]

Ik heb in Silex/Twig welk gewoon filters/functions voor het bepalen of iemand ingelogd is in de template, daar heb ik geen generieke class voor nodig. De functionaliteit die bepaalt of iemand ingelogd is zit niet in de controller maar een authenticatie/authorizatie-laag die je los moet kunnen aanspreken imo.

Er zijn natuurlijk meerdere wegen die naar Rome leiden... het aanpassen van RainTPL behoort denk ik tot de weg waarbij je vanuit Nederland naar Rusland gaat tot je uitkomt in Rome. Ik zou aanraden om een meer constructieve optie te nemen, bijv. de manier die kwaakvaak_v2 en ik bedoelen of die van NMe.