[php][discussie]Hoe files opbouwen?

[blizt]

Omdat het er pas weer over ging dat templates niet altijd nut hebben, dit topic....
Hoe maak jij je files? Even een paar methodes die ik gebruikt heb:
#1, alleen een index.php met hierin het volgende & dan files met content:

PHP:

<!---
doctype, head etc.
body, begin layout
-->
<?php
switch($_GET['page'])
{
    case about:
    include('about.php');
    break;
    
    case blaat:
    include('aap.php');
    break;
    
    case tux:
    include('pinguin.php');
    break;
    
    case bill:
    include('microsoft.php');
    break;
    
    default:
    include('home.php');
}
?>
<!--
footer, layout 'afsluiten', body afsluiten, etc.
-->

#2, een header en footer die op elke contentpage geïnclude worden:

PHP:

<?php
require_once('includes/header.php');
?>
content
<?php
require_once('includes/footer.php');
?>

Header.php bevat dan de doctype, head, begin design etc., en footer het copyright etc.

#3, hier was ik aan bezig maar ben gestopt door topics hier op GoT... een eigen template_parser, heb ik nu ook niet echt een codevoorbeeld van.

Anyway, wat zijn volgens jullie de voor- en nadeln van bovengenoemde methoden? Wat gebruiken jullie zelf en waarom?

[supakeen]

Echt template-parsend systeem en alles in 1 file. Makkelijk, haal toch 3 kwart uit mijn classes die in een include staan ergens bovenaan dus ik heb geen rotzooi aan code

[ Voor 60% gewijzigd door supakeen op 07-04-2004 09:34 ]

[blizt]

Toen ik zei 'awt gebruiken jullie zelf en waarom', bedoelde ik natuurlijk ook andere methoden hè
Dit is wat ik zelf gebruikt heb, maar aangezien ik nu eindelijk weer 'ns ga coden (is alweer tijdje geleden) wilde ik wel 'ns 'n goede methode weten.... Kan je jouw manier een beetje toelichten?

[bat266]

Ik heb een main page en haal alle content uit een database

[blizt]

En in je database staat dus ook alle html e.d.? Of zien al jouw pages er hetzelfde uit qua structuur?

[Pathogen]

zie de thread die je linkte:
-template achtige file als include in:
-php bestand voor bewerkingen
-database voor data

[PrisonerOfPain]

rootpath.php:

PHP:

<?php
if (!defined ("ROOTPATH"))
{
       define ("ROOTPATH", ".");
}
?>

header.php (en ook een flooter.php, maar die is niet echt het noemen waad, lijkt veel op dit bestand)

PHP:

<?php
include_once ("rootpath.php");
include_once (ROOTPATH . "/Database/DB.php"); //Abstracte database class
include_once (ROOTPATH . "/Configuration/Config.cfg.php"); //Configuratie
//[...] nog wat includes
include_once (ROOTPATH . "/Tempates/{$_CONFIG['template']}/header.tpl.php");
//database connectie maken...
?>

pagina.php

PHP:

<?php
include_once ("rootpath.php");
include_once (ROOTPATH . "/header.php");
//code
include_once (ROOTPAHT . "/Templates/{$_CONFIG['template']}/pagina.tpl.php")
include_once (ROOTPATH . "/flooter.php");
?>

Die ROOTPATH is omdat PHP nogal een 'vage' manier heeft van includen, probeer maar eens een paar levels diep, met een relatief pad te gaan includen.... Wat ik nou dus doe, is dan alles vanuit de hoofd-dir includen en in iedere dir een rootpath.php zetten met het relative pad naar de hoofd-dir. (wil je je bestanden nog eens een keer verhuizen hoef je alleen rootpath.php aan te passen)

[ Voor 54% gewijzigd door PrisonerOfPain op 07-04-2004 09:51 . Reden: template vergeten te includen.... ]

[bat266]

blizt schreef op 07 april 2004 @ 09:36:
En in je database staat dus ook alle html e.d.? Of zien al jouw pages er hetzelfde uit qua structuur?

De meeste zijn identiek qua structuur het enige wat er aan html in de db staat is heading en paragraph text.. en een enkele <br> Moet in de toekomst nog een put in form maken voor nieuwe pages waar die de br etc zelf invoegt in de db

[T-MOB]

Ik hoe meestal als regel aan dat je zo min mogelijk "dubbele code" moet hebben. Alle content wordt bij mij dus in 1 bestand op de goede plaats gezet.
Verder gooi ik functies in een apart bestand dat ik include, maar dat is meer omwille van overzichtelijkheid. Last but not least hou ik een tekstbestandje bij wat wat is - dan weet ik over een jaar nog wat ik ook al weer gedaan had. Uit dit bestandje kun je wel opmaken hoe de boel in elkaar steekt.

[ripexx]

In mijn backend het ik de volgende opzet.

Een index.php welke de volgende bestanden include:
header
footer
module -> specifiek (geen switch maar dmv een array => 25+ modules)
functies -> bevat ongeveer 30 functies die regelmatig gebruikt worden.
config -> configuratie bestand

[Spider.007]

Net als de topicstarter include ik ook aan de hand van bepaalde voorwaarden andere bestanden; en maak ik gebruik van generieke headers en footers. Dit model is lichtelijk afgeleid van FuseBox; en zorgt ervoor dat je geen lange pagina's met switches ofzo hoeft te onderhouden.

Overigens heb ik altijd een aantal functies in aparte bestanden die bij elke pagina worden geinclude. Ook houdt ik altijd HTML en PHP gescheiden mbv simpele tempatesystemen (php files die uit een array hun data halen )

[G F0rce 1]

De laatste tijd ben ik wat meer bezig met de fuse box manier van opbouwen. In het begin is het wat ingewikkeld maar ik moet zeggen dat het na een tijdje werken zeer rendabel word.

[blizt]

Spider, ik geef verschillende voorbeelden... Dus wat doe jij nu precies? Wat ik nu begrijp is 't een soort van #1,5 ; #1 en #2 samen gegooid en dan beetje mee gerommeld ;p
Zie ik dat goed/fout?

[Bosmonster]

Persoonlijk heb ik pagina-identifiers en gebruikte templates altijd in de database staan. Dus ik heb een algemene pagina (index.php) welke standaard gegevens ophaalt (content in de juiste taal, menustructuur, etc) en vervolgens de juiste template (gewoon html/php dus, geen template engine) include.

In de template vul ik met de vooropgehaalde variabelen en wat eenvoudige controlstructures voor bijvoorbeeld de menu's de pagina.

Afhankelijk van de site bevat de globale pagina (index.php) nog stats-verwerking/caching/etc. Dit kun je dan allemaal centraal regelen.

Opzet eenvoudig, flexibel en volledig beheerbaar.

@T-MOB.. waarom zou je dat in een los tekst bestandje doen... Daar hebben ze comments voor uitgevonden

[ Voor 14% gewijzigd door Bosmonster op 07-04-2004 13:33 ]

[Spider.007]

blizt schreef op 07 april 2004 @ 12:41:
Spider, ik geef verschillende voorbeelden... Dus wat doe jij nu precies? Wat ik nu begrijp is 't een soort van #1,5 ; #1 en #2 samen gegooid en dan beetje mee gerommeld ;p
Zie ik dat goed/fout?

Oeps.. ik zie het inderdaad..

Wat ik inderdaad gebruik is #1; alleen is mijn switch niet aan de hand van een get parameter; maar door gebruik te maken van multiViews, en dan de URL te exploden

In de pagina's die worden geinclude wordt de eigenlijk HTML code weer uit een ander bestand gehaald; dat een soort van template is:

PHP:

<a href="<?=$pageData['URL']?>"><?=$pageData['title']?></a>

[ripexx]

Spider.007 schreef op 07 april 2004 @ 13:55:
[...]


Oeps.. ik zie het inderdaad..

Wat ik inderdaad gebruik is #1; alleen is mijn switch niet aan de hand van een get parameter; maar door gebruik te maken van multiViews, en dan de URL te exploden

In de pagina's die worden geinclude wordt de eigenlijk HTML code weer uit een ander bestand gehaald; dat een soort van template is:

PHP:

<a href="<?=$pageData['URL']?>"><?=$pageData['title']?></a>

Ik werk opzich ook met een zelfde systeem of dat is de bedoeling. Maar ik gebruik de volgende truck om modules te selecteren. De volgende code is nogal oud maar de basis komt op hetzlefde neer:

PHP:

if($mod == "passmailer")
{
    $outmod = "passmailer";
}
elseif(IsSet($_SESSION["login"])) // check if logged in 
{
    $uid = $_SESSION["login"];
    set_rights($uid);

    if (!empty($_GET["mod"]) || !empty($_POST["mod"])) 
    {
        if(in_array ($mod, $inc_array)) //check if file is in include list/array
        {
            $outmod = $mod;
        }
        else
        {
            $outmod = "error";
            $message = 1; // page does not exist
        };
    }
    else
    {
        header("Location: $config_default_index");
    };
}
else
{
    $outmod = "login";
};

[ Voor 11% gewijzigd door ripexx op 07-04-2004 14:02 ]

[djluc]

Ik heb index.php als basis. Alle andere bestanden met uitzondering van het configuratiebestand staan in mappen die het een .htacces zijn afgesloten voor de buitenwereld. In index.php laad ik een aantal modules die algemene zaken als databases e.d. behandelen.

Vervolgens heb ik een verdeling in sub-systemen. Zo kan ik bijvoorbeeld een aparte admin en een aparte website maken. Deze krijgen een mapje in de root en daarin bevinden zich bestanden met de bekende lange switches e.d. Ik gebruik voor mijn systeem een aantal basisregels:
*alles verloopt via index.php
*alleen het bestand index.php in een map mag aangeroepen worden

De PHP/HTML scheiding is intern ingebakken door middel van een aparte view-layer met php bestanden die gegevens uit een array halen. Indien designer hier bijvoorbeeld problemen mee hebben kan die view-layer ook gebruikt worden om de template engine aan te sturen. Hierdoor hoef ik mijn code in de business layer echter niet aan te passen.

[Michali]

Ik werk de laatste tijd eigenlijk alleen maar met het opbouwen van een XML document met PHP en het dan laten transformeren met XSL. Lekker snel, verdeeld en overzichtelijk. (vind ik dan).

[blizt]

Wilde ik nu dus ook gaan doen, maar ... waarom ondersteunt dat stomme lynx geen XML?
Ik kreeg de tip om XML-support er in te hacken, maar ja... niet zo'n C-programmeur
Of laat jij de XML serverside parsen?

[X-Lars]

Michali schreef op 07 april 2004 @ 18:20:
Ik werk de laatste tijd eigenlijk alleen maar met het opbouwen van een XML document met PHP en het dan laten transformeren met XSL. Lekker snel, verdeeld en overzichtelijk. (vind ik dan).

Daarmee dacht ik laatst ook het ei van Columbus gevonden te hebben. Maar je moet er even goed mee oppassen. Lees eventueel dit topic, ongeveer vanaf hier: [rml]drm in "[ XSL(T)/XML] Transformatie naar XML"[/rml]. Het komt, als ik het tenminste begrepen heb, vooral neer op de vraag waarom XML meerwaarde heeft boven XHTML (semantiek van XML heeft geen betekenis). Op zich ben ik nog steeds wel benieuwd naar wat meer info hierover.

[Bosmonster]

djluc schreef op 07 april 2004 @ 16:44:
Deze krijgen een mapje in de root en daarin bevinden zich bestanden met de bekende lange switches e.d.

Welke 'bekende' lange switches?

[blizt]

ik denk die van #1 in mijn startpost Bosmonster

[Verwijderd]

ik vind het hele "index.php en de pagina's zelf includen we" idee verschrikkelijk als je 't mij vraagt.. tis een kwestie van smaak, dus ik bedoel niet te flamen, tis gewoon absoluut mijn smaak niet

ik heb altijd een init.php, die file include ik in iedere file.
in die init.php regel ik een header en footer functie (geen files die ik include) die een en ander echo'en aan <html> tags e.d... en eventueel open ik direct een database connectie als ik die toch altijd gebruik.

verder zet ik in deze file allerlei functies die ik regelmatig wil gebruiken en include ik eventueel een bestand waar wat configuratie parameters in staan (een config.php)

[djluc]

ik denk die van #1 in mijn startpost Bosmonster

Die inderdaad

Abraxas werkt zo te zien niet met verschillende layers e.d. Dat is erg aan te raden bij grote projecten imo. Verder vind ik het handig om alles centraal te houden zodat je de rest van de bestanden met een htacces af kunt sluiten. Dat vind ik persoonlijk beter, maar vooral overzichtelijker.

[ Voor 15% gewijzigd door djluc op 07-04-2004 23:52 ]

[PrisonerOfPain]

Verwijderd schreef op 07 april 2004 @ 21:43:
ik heb altijd een init.php, die file include ik in iedere file.
in die init.php regel ik een header en footer functie (geen files die ik include) die een en ander echo'en aan <html> tags e.d... en eventueel open ik direct een database connectie als ik die toch altijd gebruik.

Waarom een functie? je roept een header en footer toch maar een keer per pagina aan, dus ik zie het voordeel niet zo...

[Spockz]

Ik heb een index pagina, hierin require ik mijn config bestand .
Het is voor de rest gewoon html afgezien dan van het feit dat het includen van het menu afhankelijk is van welke site je kiest en dat de inhoud ook via een php aangeroepen wordt dmv. een include. Dus dan include hij bv p1 en in de config staat dat $p1 gelijk is aan 'content/etc.'

[Bosmonster]

djluc schreef op 07 april 2004 @ 22:14:
[...]
Die inderdaad

Abraxas werkt zo te zien niet met verschillende layers e.d. Dat is erg aan te raden bij grote projecten imo. Verder vind ik het handig om alles centraal te houden zodat je de rest van de bestanden met een htacces af kunt sluiten. Dat vind ik persoonlijk beter, maar vooral overzichtelijker.

Call me crazy, maar dat zou ik uberhaupt al nooit zo oplossen Zodra je 'lange' switches nodig hebt om een eenvoudig vertaal/validatie-slag te maken moet er toch een handigere manier zijn lijkt me..

Een DB biedt uitkomst (templates koppelen aan pagina's). Of desnoods zonder DB een vertaal-verzamelingetje bijhouden.

PHP:

$pages = array (
    'bla'   => 'bla.php',
    'zozo' => 'zozo.php'
);

if (isset ($_GET['page']) && isset ($pages[$_GET['page']])) {
    include $pages[$_GET['page']];
} else {
    include 'default.php';
}

Proberen zoveel mogelijk data (de pagina-vertalingen) te scheiden van code-structuren (if/switches)... De vertaal array zou je nog in een los bestand kunnen bijhouden. Lelijke ellen-lange switches zijn bij mij dus niet 'bekend'.

[PrisonerOfPain]

Bosmonster schreef op 08 april 2004 @ 10:13:
[...]

PHP:

$pages = array (
    'bla'   => 'bla.php',
    'zozo' => 'zozo.php'
);

if (isset ($_GET['page']) && isset ($pages[$_GET['page']])) {
    include $pages[$_GET['page']];
} else {
    include 'default.php';
}

Proberen zoveel mogelijk data (de pagina-vertalingen) te scheiden van code-structuren (if/switches)... De vertaal array zou je nog in een los bestand kunnen bijhouden. Lelijke ellen-lange switches zijn bij mij dus niet 'bekend'.

Nou doe je toch precies hetzelfde? Alleen heb je nou een lange array die voor de rest van de uitvoer in het geheugen blijft staan.

[ripexx]

Nu we het toch hebben over opzet enz. Hoe doen jullie dit dan in een backend. Op een site heb je met name presentatie en relatief weinig terugkoppeling. In een CMS heb je daarentegen weer heel veel formulieren, rechten enz enz. Maken jullie bijvoorbeeld voor elke actie een php file die doet dus:
list_nieuws.php
insert_nieuws.php
edit_nieuws.php

of maken jullie gebruik van een module bestand waarin alle relevante actie worden gedaan. Het voordeel van een module bestand vind ik dat je alle gegevens bij elkaar hebt staan en je veel beter weet hoe het ervoor staat qua ontwikkeling etc. Nadeel is wel dat grotere modules nogal snel onoverzichtelijk worden. Waardoor bug hunten soms veel tijd kost.

Verder is er een hele discussie over templates geweest maar voor een backend heeft het relatief weinig nut. Het kost veel meer tijd om te maken en enkele accenten zijn snel via een css of config file aan te passen. Hoe pakken jullie nu zoiets op?

[coubertin119]

In de meeste gevallen worden die files als HTML naar de browser gestuurd. Maar XHTML valt te benaderen als XML. Als je dus een lege standaardfile, met id's op de juiste plaatsjes en de markup er al in opgeslagen, begint, kan je toch via het DOM de gegevens (uit bijvoorbeeld een database, of de userinput) er in zetten en dus pure XHTML naar de browser sturen.

Of is mijn idee wat overroepen?

[gomaster]

Ik zag hier net iets over fusebox. Het is mij totaal onbekend. Ik ben net even op die site geweest maar het voordeel wordt me niet helemaal duidelijk. Kan iemand mij daar iets meer over vertellen?

[Verwijderd]

X-Lars schreef op 07 april 2004 @ 18:36:
[...]

Daarmee dacht ik laatst ook het ei van Columbus gevonden te hebben. Maar je moet er even goed mee oppassen. Lees eventueel dit topic, ongeveer vanaf hier: [rml]drm in "[ XSL(T)/XML] Transformatie naar XML"[/rml]. Het komt, als ik het tenminste begrepen heb, vooral neer op de vraag waarom XML meerwaarde heeft boven XHTML (semantiek van XML heeft geen betekenis). Op zich ben ik nog steeds wel benieuwd naar wat meer info hierover.

Ik ben sinds een tijdje bezig met een website die gebruik maakt van PHP/MySQL/XML/XSL. index.php retourneert een XML file, waarin dan weer een referentie staat naar een XSL file op de server. Het grote voordeel is dat je in je PHP scripts dus absoluut NIETS meer merkt van opmaak/layout, oftewel de populaire kreet: "scheiden van business logic en presentation logic" is van toepassing. Het voordeel van XML retourneren boven XHTML is dat het template parsen volledig bij de client gebeurt.

[blizt]

Blukske: jij parsed je XML clientside en dat is een voordeel? Nog nooit met lynx bekeken zeker....

[Verwijderd]

Tja...ik zal hier geen vrienden mee maken, maar eerlijk gezegd kan ik me daar niet zo druk om maken. Hoeveel mensen gebruiken die browser nou? Een oplossing zou trouwens kunnen zijn om voor die (kleine) groep waarvoor clientside parsing geen optie is een uitzondering te maken en de XML serverside te parsen. Is Lynx te onderscheiden van andere browsers op basis van de $HTTP_USER_AGENT?

[ Voor 7% gewijzigd door Verwijderd op 08-04-2004 14:05 ]

[Verwijderd]

Foutje

[ Voor 98% gewijzigd door Verwijderd op 08-04-2004 14:03 ]

[djluc]

Verwijderd schreef op 08 april 2004 @ 12:52:[...]index.php retourneert een XML file, waarin dan weer een referentie staat naar een XSL file op de server. Het grote voordeel is dat je in je PHP scripts dus absoluut NIETS meer merkt van opmaak/layout, oftewel de populaire kreet: "scheiden van business logic en presentation logic" [...]

In zekere zin pas ik dat ook wel toe maar dan dus in PHP lagen. In de view layer staat dus alles over opmaak van de data en de pagina. Het voordeel is gewoon dat je met XSL netjes de pagina op kunt maken.

[Verwijderd]

Verwijderd schreef op 08 april 2004 @ 14:02:
Tja...ik zal hier geen vrienden mee maken, maar eerlijk gezegd kan ik me daar niet zo druk om maken. Hoeveel mensen gebruiken die browser nou? Een oplossing zou trouwens kunnen zijn om voor die (kleine) groep waarvoor clientside parsing geen optie is een uitzondering te maken en de XML serverside te parsen. Is Lynx te onderscheiden van andere browsers op basis van de $HTTP_USER_AGENT?

Ten eerste, nee, daar maak je geen vrienden mee. Maar gelukkig kan je je daar niet druk om maken. Antwoord op je vraag: ja, een willekeurig voorbeeld: "Lynx/2.8.5dev.7 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7".

[Skaah]

Iets als:

PHP:

require('libs/db.class.inc.php');
require('libs/objects.php');
require('libs/smarty/smarty.class.php');
require('libs/searchenginefriendly.php'); // verwerkt urls als index.php/command/view/id/3/

switch($_FRIENDLY['command'])
{
  case 'view':
   break;
  case 'search':
   break;
}

Dus, alles in een file.