[PHP] site-structuur

zaterdag 13 december 2003 21:08

Acties:

0 Henk 'm!

Hopla!

Php

Topicstarter

Stel, ik wil een veilingsite maken. Neem aan dat deze site maar drie pagina's kent:

1. overview van de product-categorien
2. product-details
3. bied-pagina

Ik heb twee manieren om dit te programmeren:

manier 1: ik maak drie pagina's aan:

- http://www.mijnsite.com/categories.php
- http://www.mijnsite.com/product-details.php
- http://www.mijnsite.com/place-bid.php

manier 2: ik include een pagina in mijn index.php

- http://www.mijnsite.com/index.php?page=categories
- http://www.mijnsite.com/index.php?page=product-details
- http://www.mijnsite.com/index.php?page=place-bid

pseudo-code van index.php:

PHP:

...
<body>
<table cellpadding="0" cellspacing="0" width="100%" border="0">
  <tr>
    <td><?php include_once "topnav.php"; ?></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td><?php include_once($_GET['page']); ?></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td><?php include_once "footer.php" ?></td>
  </tr>
</table>
</body>
...

waarbij ik natuurlijk wel ervoor zou zorgen dat het onmogelijk is om een "evil page" in te laden via de querystring:

http://www.mijnsite.com/i...evilsite.com/evilcode.php
etc. etc. maar dit is buiten de vraag.

In principe is elke site via een van deze twee manieren op te bouwen. Mijn vraag is nu: wat zijn belangrijke verschillen tussen deze twee? Brengt het toepassen van manier 2 een zware belasting voor index.php met zich mee (deze wordt immers altijd aangeroepen) en is dit nadeling dan wanneer ik fysiek verschillende pagina's maak?

Graag jullie mening over de voor/ en nadelen van beide methodes. Waarom gebruik je zelf 1 of 2? Is het slechts een kwestie van voorkeur of zijn er daadwerkelijk (performance) redenen aan te geven?

[ Voor 52% gewijzigd door Reveller op 13-12-2003 21:55 . Reden: ik was een beetje dom (zie eerste reaktie) ]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."

zaterdag 13 december 2003 21:31

Acties:

0 Henk 'm!

Verwijderd

1.

PHP:

1	<?php include_once "$_include.php" ?>

is fout

PHP:

1	<? include_once($_GET['page']); ?>

2. ?page=*** wordt vaak gebruikt in combinatie met een database of CMS omdat dit makkelijker werkt als files editten. Dus niets includen.

3. Ik ben zelf voor aparte pagina's, maar dan met belangrijke dingen zoals titel etc. in een config, en menu in een appart bestand of mysql database, etc.

De GET variabelen gebruik ik alleen als het echt nodig is, vind ze niet mooi uitzien zoiezo.

Maarja, je weet nu wat ik rvan vind, nu de rest nog

zondag 14 december 2003 01:20

Acties:

0 Henk 'm!

Grijze Vos

Tis een kwestie van smaak denk ik. Ik ben wel fan van het index-gebruik, zeg maar. Het heeft als voordeel dat je met zo'n soort footer kunt werken, en dat je altijd alle nodige brul in je index.php kunt includen. Dus niet per se een include nodig hebt in de page die je aanroept.

Het geheel geeft mij iets meer een modulair gevoel.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zondag 14 december 2003 02:20

Acties:

0 Henk 'm!

Verwijderd

En dan daarbij als je dit soort code's gebruikt als url(hacker b.v.) dit dan hebben ze je password file al, dat is dus alles behalve veilig.
^{Nee dat path en filename zullen niet kloppen, maar zoiets was het iig.}

Je kan b.v. wel een array maken en de files er inzetten die je MAG includen via dat script, bv

PHP:

1 2	$inclacceptarr = array("file.php","file2.php","file3.php","file4.php"); if (in_array($inclacceptarr,$_GET['page'])) include_once($_GET['page'];

Maar ik ben toch tegenstander van bestanden includen vanuit een get/post

zondag 14 december 2003 02:22

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Verwijderd schreef op 14 december 2003 @ 02:20:
En dan daarbij als je dit soort code's gebruikt als url(hacker b.v.) dit dan hebben ze je password file al, dat is dus alles behalve veilig.

Daarom moet je ook je password file .htpasswd noemen. Dan zorgt Apache er wel voor dat de gebruiker die niet mag bekijken.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

zondag 14 december 2003 02:26

Acties:

0 Henk 'm!

Verwijderd

LauPro schreef op 14 december 2003 @ 02:22:
[...]
Daarom moet je ook je password file .htpasswd noemen. Dan zorgt Apache er wel voor dat de gebruiker die niet mag bekijken.

Ja dat is ook zo, maar wist de filename niet meer presies

[/offtopic]

zondag 14 december 2003 03:09

Acties:

0 Henk 'm!

Grijze Vos

Niet voor het een of het ander, maar een apache negeert per default alles wat met een "." begint. Die "." staat voor hidden file, zeg maar..

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zondag 14 december 2003 11:12

Acties:

0 Henk 'm!

dingstje

Sinds wanneer gebruikt PHP Apache om zijn files te includen? Moest PHP .php files includen van Apache zouden die al geparsed zijn op voorhand en dat is niet de bedoeling. PHP haalt zijn files gewoon van het filesystem, anders zouden hacks als /etc/passwd ook niet werken aangezien NIEMAND apache rechten geeft aan /etc.

If you can't beat them, try harder

zondag 14 december 2003 12:15

Acties:

0 Henk 'm!

Kogelvis

Nu ook met gitaar

LauPro schreef op 14 december 2003 @ 02:22:
[...]
Daarom moet je ook je password file .htpasswd noemen. Dan zorgt Apache er wel voor dat de gebruiker die niet mag bekijken.

die .htpasswd die je hier noemt word vaak gebruikt om webcontent af te schermen.
de passwd die de poster hierboven noemt is een bestand op een *nix systeem in dit bestand worden alle lokale users opgeslagen, dus dat bestand naar .htpasswd hernoemen is niet bevorderlijk voor de werking van het *nix systeem

<Jeroen> Wirf: vrouwen versieren kan je gewoon in het OSI model proppen hoor :P
I am dyslexic of Borg prepare to have your ass laminated
Real Programmers always confuse Christmas and Halloween because oct31 = dec25

zondag 14 december 2003 12:21

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

ehm het gaat hier toch niet om hoe je het uitvoerd, maar op welke manier?
in principe kan je ze allebei prima gebruiken.
Zelf kies ik meestal voor een derde mogelijkheid:

http://host/scriptnaam/module

waarbij 'scriptnaam' de php file is, ziet er beter uit, schonere urls etc

zondag 14 december 2003 12:40

Acties:

0 Henk 'm!

Johnny

ondergewaardeerde internetguru

Naast het feit dat het gebruik van tabellen tegenwoordig helemaal uit is vind ik di een rare structuur.

Waarom staat al die HTML code in index.php? Je kunt het toch net zo goed in topnav.php en footer.php zetten?

Waarom gebuik je topnav.php en footer.php als je ze alleen include op index.php? Dan kun je toch beter alle HTML code op die pagina zetten?

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

zondag 14 december 2003 13:19

Acties:

0 Henk 'm!

Verwijderd

Erkens schreef op 14 december 2003 @ 12:21:
ehm het gaat hier toch niet om hoe je het uitvoerd, maar op welke manier?
in principe kan je ze allebei prima gebruiken.
Zelf kies ik meestal voor een derde mogelijkheid:

http://host/scriptnaam/module

waarbij 'scriptnaam' de php file is, ziet er beter uit, schonere urls etc

Ja dit doe ik ook altijd, in de .htaccess even een Options +Multiviews neerzetten en dan werkt het. Mbv php even de REQUEST_URI laten exploden en dan kan je dmv de array waardes ophalen. Moet je voor de grap eens een print_r op die array loslaten, dan zie je wat er inzit.
^{Tja ik ben in een goeie bui, dan hoeft de TS niet te zoeken}

zondag 14 december 2003 16:20

Acties:

0 Henk 'm!

chris

Reveller schreef op 13 december 2003 @ 21:08:
Stel, ik wil een veilingsite maken. Neem aan dat deze site maar drie pagina's kent:

1. overview van de product-categorien
2. product-details
3. bied-pagina

Ik heb twee manieren om dit te programmeren:

manier 1: ik maak drie pagina's aan:

- http://www.mijnsite.com/categories.php
- http://www.mijnsite.com/product-details.php
- http://www.mijnsite.com/place-bid.php

manier 2: ik include een pagina in mijn index.php

- http://www.mijnsite.com/index.php?page=categories
- http://www.mijnsite.com/index.php?page=product-details
- http://www.mijnsite.com/index.php?page=place-bid

pseudo-code van index.php:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
...
<body>
<table cellpadding="0" cellspacing="0" width="100%" border="0">
  <tr>
    <td><?php include_once "topnav.php"; ?></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td><?php include_once($_GET['page']); ?></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td><?php include_once "footer.php" ?></td>
  </tr>
</table>
</body>
...
waarbij ik natuurlijk wel ervoor zou zorgen dat het onmogelijk is om een "evil page" in te laden via de querystring:

http://www.mijnsite.com/i...evilsite.com/evilcode.php
etc. etc. maar dit is buiten de vraag.

In principe is elke site via een van deze twee manieren op te bouwen. Mijn vraag is nu: wat zijn belangrijke verschillen tussen deze twee? Brengt het toepassen van manier 2 een zware belasting voor index.php met zich mee (deze wordt immers altijd aangeroepen) en is dit nadeling dan wanneer ik fysiek verschillende pagina's maak?

Graag jullie mening over de voor/ en nadelen van beide methodes. Waarom gebruik je zelf 1 of 2? Is het slechts een kwestie van voorkeur of zijn er daadwerkelijk (performance) redenen aan te geven?

De 2e vind ik persoonlijk een stuk mooier, omdat je dan veel minder dubbele code hebt (waarschijnlijk zet je anders in elke pagina iets als include("vars.php"), include("templ.php"), enz.

Wat ook nog leuk is dat je een directory includes kan maken en vervolgens check je je $_GET["page_type"] of het allemaal letters/nummers zijn (a-zA-Z0-9+) en dan ga je include("includes/" . $page_type) doen.

Wat is hier nou leuk aan? Nou, je hoeft in principe alleen maar een bestand in je includes directory te zetten en helemaal geen index.php ofzo aan te passen. Heerlijk

.

Maar qua performance/belasting zal het trouwens weinig uitmaken of je een index.php gebruikt of meerdere bestanden, zeker als je alleen include wat nodig is.

zondag 14 december 2003 16:24

Acties:

0 Henk 'm!

Verwijderd

zelf hou ik meer van : http://www.mijnsite.com/?categories in plaats van zo een lange http://www.mijnsite.com/index.php?page=categories

zondag 14 december 2003 16:34

Acties:

0 Henk 'm!

Verwijderd

Ik weet niet hoe we de TS vraag moeten bekijken, vanuit de developpers-ogen of door de ogen van de bezoeker. In het respectievelijk laatste geval denk ik namelijk dat de bezoekers van een site er toch echt niet op gaan letten of er www.mijnsite.com/index.php?page=produkten staat, of dat er www.mijnsite.com/produkten staat.

En degene die er wél op letten, zijn waarschijnlijk zelf geinteresseerd in het maken van websites. En als je het goed beveiligd, maakt het allemaal niet uit hoe je het ontwikkeld.

Maar das natuurlijk mijn mening...

zondag 14 december 2003 16:43

Acties:

0 Henk 'm!

Verwijderd

offtopic:
KingOfDos; Sorry dat ik je avatar heb laten verdwijnen, maar in je script zit een foutje..

zondag 14 december 2003 16:43

Acties:

0 Henk 'm!

hobbit_be

zelf gebruik ik een hidden form / met post.

het feit dat je dan totaal niets meer ziet is een bijkomertje voor me.

Natuurlijk kun je dan geen save as favourite doen maar het is voor een admin site (dus login required) only. Eventueel kun je het wel in een gewone "get" steken.

Ik gebruik ook maar 1 encrypted "parameter" waarin staat wat het systeem moet doen... (ie encoded funtion call(s)).

zondag 14 december 2003 16:48

Acties:

0 Henk 'm!

Mark Wegener

ik ben zelf voor een directory structuur (zie heel tweakers). Is voor gebruikers makkelijker te onthouden, en heeft bijkomende voordelen als makkelijke zoekmachines blokkeren met robots.txt bestandje en goede indexatie.

zondag 14 december 2003 17:06

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

Verwijderd schreef op 14 december 2003 @ 13:19:
[...]

Ja dit doe ik ook altijd, in de .htaccess even een Options +Multiviews neerzetten en dan werkt het. Mbv php even de REQUEST_URI laten exploden en dan kan je dmv de array waardes ophalen. Moet je voor de grap eens een print_r op die array loslaten, dan zie je wat er inzit.
^{Tja ik ben in een goeie bui, dan hoeft de TS niet te zoeken}

mja, ik gebruik gewoon $_SERVER['PATH_INFO'] ipv de REQUEST_URI

En een beetje hosting heeft Multiviews wel in de httpd.conf staan, zodat je geen .htaccess nodig hebt wat weer extra door de server ingelezen dient te worden (niet dat het veel boeit natuurlijk)

zondag 14 december 2003 17:23

Acties:

0 Henk 'm!

Grijze Vos

Martin.Duane schreef op 14 december 2003 @ 16:48:
ik ben zelf voor een directory structuur (zie heel tweakers). Is voor gebruikers makkelijker te onthouden, en heeft bijkomende voordelen als makkelijke zoekmachines blokkeren met robots.txt bestandje en goede indexatie.

redelijk invalide argument, zoekmachines negeren naar mijn weten alle urls met een "?" erin.

Mja, wrom zou je uberhaupt een zoekmachine willen blokkeren, beetje tegendraads. Het idee van internet is info aanbieden, niet afschermen.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zondag 14 december 2003 17:25

Acties:

0 Henk 'm!

gorgi_19

Kruimeltjes zijn weer op :9

Grijze Vos schreef op 14 december 2003 @ 17:23:
[...]
redelijk invalide argument, zoekmachines negeren naar mijn weten alle urls met een "?" erin.

Google heeft er in ieder geval geen problemen mee.

quote: http://www.google.nl/intl/nl/webmasters/2.html
Uw pagina's zijn dynamisch gegenereerd. Google is in staat om dynamisch gegenereerde pagina's te indexeren. Het aantal dynamisch gegenereerde pagina's dat Google indexeert, wordt echter bewust beperkt gehouden, aangezien dynamisch gegenereerde sites tijdens het crawlen makkelijk overbelast kunnen raken en crashen.

Mja, wrom zou je uberhaupt een zoekmachine willen blokkeren, beetje tegendraads. Het idee van internet is info aanbieden, niet afschermen.

Er zijn situaties denkbaar waarin het wel gewenst is.
Een paar voorbeelden:
1. Een applicatie welke niet publiek zichtbaar hoeft te zijn. Hoewel er een inloggedeelte is, hoeven buitenstaanders ook niet op dit inloggedeelte te komen.

2. Bepaalde pagina's bestaan uit vrij zware queries. Zo heb ik laatst een presentatie gezien over een forum; die dit probleem ook had. (profielen pagina's van de posters). Het nadeel was dat hier ook de 10 laatste reacties stonden; bij elkaar opgeteld leverde dat onnodig veel load op.
Door bepaalde folders niet meer te laten indexeren, was de load te allen tijde voldoende.

[ Voor 83% gewijzigd door gorgi_19 op 14-12-2003 17:31 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo

zondag 14 december 2003 17:37

Acties:

0 Henk 'm!

Grijze Vos

Dat van die "?" had ik ook maar ergens gelezen, en nooit geverifieerd (my bad).

Maar dan nog, een robots.txt wordt ook gewoon netjes naar geluisterd als je dynamische paginas gebruikt..

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zondag 14 december 2003 23:16

Acties:

0 Henk 'm!

bigtree

Ik ben sinds kort helemaal voor de eerste methode. Ten eerste krijg je esthetisch meer verantwoorde urls en ten tweede wordt je site gewoon makkelijker onderhoudbaar. Hierbij hanteer ik dan wel een Gouden Regel dat bestanden die niet direct via een url worden opgevraagd (oftewel geïnclude worden), met een underscore (_) beginnen. Dus in jouw geval zou ik _topnav.php gebruiken in plaats van topnav.php. Ten eerste staan de bestandjes dan gegroepeerd (includes versus niet-includes) als je ze op alfabet sorteert en ten tweede maak je url guessing minder makkelijk (je zou niet willen dat men bijv. een config bestandje direct via een url kan openen, voor zover code zou kunnen verraden).

Lekker woordenboek, als je niet eens weet dat vandalen met een 'n' is.

zondag 14 december 2003 23:19

Acties:

0 Henk 'm!

Grijze Vos

Dat estetisch argument vind ik een beetje waardeloos. De gemiddelde gebruiker kijket er niet eens naar. En, de gemiddelde site is zo baggerlelijk, dat er eerst iets aan de layout van de website zelf moet worden gedaan, voordat je eens hoort te gaan nadenken over of je url wel estetisch correct is...

En mijn webpages zijn minstens even onderhoudbaar als die van jou. Ik zie niet in hoe jouw manier een beter onderhoudbare webpage oplevert. Ik heb een aparte folder met include files.

[ Voor 24% gewijzigd door Grijze Vos op 14-12-2003 23:20 ]

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zondag 14 december 2003 23:36

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

bigtree schreef op 14 december 2003 @ 23:16:
Hierbij hanteer ik dan wel een Gouden Regel dat bestanden die niet direct via een url worden opgevraagd (oftewel geïnclude worden), met een underscore (_) beginnen.

nee, je moet files die geinclude mogen worden in een array stoppen en kijken of de opgevraagde file geinclude mag worden

Ten eerste staan de bestandjes dan gegroepeerd (includes versus niet-includes) als je ze op alfabet sorteert

ooit van directory structuren gehoord?

en ten tweede maak je url guessing minder makkelijk (je zou niet willen dat men bijv. een config bestandje direct via een url kan openen, voor zover code zou kunnen verraden).

ehm config files zet je over het algemeen _buiten_ je webdir, mocht dit niet mogelijk zijn dan geef je of aan in .htaccess dat die file niet opgehaald mag worden, of je geeft geen lees rechten aan die file

zondag 14 december 2003 23:46

Acties:

0 Henk 'm!

dingstje

Ik ben persoonlijk voor de directory structuur via de RewriteEngine van Apache. (zoals iemand anders hier al aanhaalde). Het ziet er netjes uit, en vooral logisch. Of toch als je op één van de oorspronkelijke bedoelingen van pc's afgaat: steekkaarten vervangen en informatie duidelijk groeperen. Maw: kaartenbak nieuws, nieuwsid 1: nieuws/1. Vind ik lekker logisch :-)

If you can't beat them, try harder

maandag 15 december 2003 11:21

Acties:

0 Henk 'm!

Verwijderd

Is deze optie niets?

- http://www.mijnsite.com/index.php?op=categories
- http://www.mijnsite.com/index.php?op=product-details
- http://www.mijnsite.com/index.php?op=place-bid

Waarbij index.php bepaalt, dmv een case switch, voor welke OPtie er gekozen is en vervolgens include hij het juiste php bestand? Of hij roept een ander php bestand aan? Lijkt mij aardig safe (geen evil pages), en je hebt de mogelijkheid nette error pages te genereren wanneer er voor een foute optie gekozen wordt.

Het keihard vanaf de URL includen van bestanden krijg ik een beetje een moeilijk gevoel bij. Ik weet dat het dicht te timmeren is, maar toch. Zou ik nooit voor kiezen.

Het netste is misschien gewoon om voor alle functies aparte bestanden te maken, maar mijn voorkeur heeft het ook niet. In principe heb je een hele berg overhead. Alle bestanden hebben stukken code gemeen. Mocht je daar wat in willen veranderen dan moet je alle bestanden wijzigen. En ja, natuurlijk maak je gebruik van headers en footers, but still. Wedden dat je er een keer tegenaan loopt??

maandag 15 december 2003 11:36

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

dingstje schreef op 14 december 2003 @ 23:46:
Ik ben persoonlijk voor de directory structuur via de RewriteEngine van Apache.

Waarom zou je de relatief gezien zware RewriteEngine willen gebruiken als je hetzelfde eenvoudiger kan bereiken met MultiViews

maandag 15 december 2003 11:41

Acties:

0 Henk 'm!

Snow_King

Konijn is stoer!

ik heb een soort gelijks ook gemaakt

PHP:

$page = $_GET["page"];

//Content
function content($page){
    if(!isset($page)){ $page = "home"; }
    $filename = "./page/$page.php";


    if (file_exists($filename)) {
    
        include($filename);

    } else {

    echo("<p>Error: Page not found!</p>");

    }

}

Werkt goed bij mij

en in de directery /page/ staat een .htaccess die het verbied om de file daar te lezen

Order Deny,Allow
Deny from All

[ Voor 36% gewijzigd door Snow_King op 15-12-2003 11:43 ]

maandag 15 december 2003 14:21

Acties:

0 Henk 'm!

Verwijderd

Verwijderd schreef op 14 december 2003 @ 16:43:

offtopic:
KingOfDos; Sorry dat ik je avatar heb laten verdwijnen, maar in je script zit een foutje..

offtopic:
Hoezo dat? Een niet bestaand id invoeren ofzo? msn/icq/mail me

maandag 15 december 2003 14:40

Acties:

0 Henk 'm!

Verwijderd

Erkens schreef op 15 december 2003 @ 11:36:
[...]

Waarom zou je de relatief gezien zware RewriteEngine willen gebruiken als je hetzelfde eenvoudiger kan bereiken met MultiViews

Is het niet zo dat MultiViews alleen te gebruiken valt wanneer je bijvoorbeeld news/123 wilt herschrijven news.php?newsid=123?

The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.

Stel dat je wilt dat index.php?page=news&newsid=123 wordt herschreven naar news/123, dan heb je alsnog toch mod_rewrite nodig?

maandag 15 december 2003 14:43

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

Verwijderd schreef op 15 december 2003 @ 14:40:
[...]

Is het niet zo dat MultiViews alleen te gebruiken valt wanneer je bijvoorbeeld news/123 wilt herschrijven news.php?newsid=123?

Stel dat je wilt dat index.php?page=news&newsid=123 wordt herschreven naar news/123, dan heb je alsnog toch mod_rewrite nodig?

mod_rewrite heb je idd alleen nodig als je manier 2 van de topic starter hebt geschreven er er 'mooie' url's van wilt maken.
Echter als je multiviews gebruikte dan zorg je ervoor dat je script meteen geladen wordt zonder dat de rewrite engine aan het werk moet, wat dus handiger is voor een lagere belasting op je server

dinsdag 16 december 2003 00:59

Acties:

0 Henk 'm!

Reveller

Hopla!

Php

Topicstarter

Ik wil tot zover iedereen al bedanken voor zijn reaktie - de waarheid schijnt ergens in het midden te liggen

.

Vele reakties gaan in op het herschrijven van de URL mbv. MultiViews of de ReWriteEngine. Ook ik ben voor "mooie" URL's, en wil uiteindelijk de URL ombouwen naar een mijnsite/script/id format.

Dit is alleen voor later. Op dit moment gaat het me vooral om wat programmeer- / structuurtechnisch gezien beter (te onderhouden) is: manier 1 of 2.

Ik ben blij te lezen dat er op allebei de fronten wordt nagedacht over eventuele securitybreaches. Hiervoor bedankt, ik leer ervan. Toch geldt ook hier weer: het gaat mij om de voorkeur voor een van de twee manieren.

Ik moet zeggen dat ik na het lezen van de reakties tot nu toe - ik heb speciaal gewacht met reageren totdat ik ook stof tot reageren had - neig naar de tweede manier, dus om de hoofdlogic van de pagina (de header en footer zijn overal gelijk) te includen in de index.php.
Hiervoor zijn leuke tips (_include) naar voren gekomen. Deze manier had toen ik het topic startte al mijn voorkeur, en is het nog steeds. Het blijkt dat er weinig harde argumenten zijn om een van de twee manieren af te schrijven; het komt vooral neer op voorkeur.

Via eerder genoemde tools herschrijf ik de URL dan wel naar "estetisch"

verantwoorde URL's.

Als iemand er nog een andere mening op na houdt, of een sterk argument heeft om mij van dit dwalend pad

af te helpen, dan hoor ik dat graag natuurlijk.

[ Voor 2% gewijzigd door Reveller op 16-12-2003 00:59 . Reden: geef post zonder signature natuurlijk... ]

"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."

dinsdag 16 december 2003 07:36

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

Reveller schreef op 16 december 2003 @ 00:59:
Vele reakties gaan in op het herschrijven van de URL mbv. MultiViews of de ReWriteEngine. Ook ik ben voor "mooie" URL's, en wil uiteindelijk de URL ombouwen naar een mijnsite/script/id format.

met MultiViews herschrijf geen URL

de webserver gaat daarmee namelijk opzoek naar de file die nodig is voor de request.
http://server.adres/script/extra/info
waarbij 'script.php' hier het script is, en aangezien er geen directory is die 'script' heet, gebruikt de server deze php file en geeft de rest van de url (/extra/info) mee via PATH_INFO.

Dit is alleen voor later. Op dit moment gaat het me vooral om wat programmeer- / structuurtechnisch gezien beter (te onderhouden) is: manier 1 of 2.

het grote verschil tussen manier 1 en manier 2 (waarbij ik multiviews samengooi met manier 2) is de manier van aanroepen, doh.
Ik neem aan dat je met manier 1 ook gebruik gaat maken van includefiles zoals standaard classen/functies die je gebruikt, alsmede wellicht een header en footer.
Als je dan wilt uitbreiden moet je goed opletten of je dan geen includes vergeet of dingen dubbel gaat zitten doen.
Onderhoud? mja, je hebt in beide gevallen voor elke (sub)functie een aparte php file. Wellicht dat dat er met manier 1 meer zijn, maar dat hangt af van het project.

Hiervoor zijn leuke tips (_include) naar voren gekomen. Deze manier had toen ik het topic startte al mijn voorkeur, en is het nog steeds. Het blijkt dat er weinig harde argumenten zijn om een van de twee manieren af te schrijven; het komt vooral neer op voorkeur.

voorkeur en kennis, ik denk dat als je altijd met manier 1 hebt gewerkt dat je daarmee sneller een veiligere applicatie schrijft dan met manier 2, anderom uiteraard ook. Echter mijn voorkeur gaat uit naar manier 2, aangezien het eenvoudiger te onderhouden is, je kan makkelijk functies in een aparte directory gooien zonder dat de eindgebruiker er 'last' van heeft, de url veranderd niet.

edit: (ik wilde nog wat toevoegen maar moest mijn trein halen

)

Via eerder genoemde tools herschrijf ik de URL dan wel naar "estetisch" verantwoorde URL's.

Hoe je dat doet (of met mod_rewrite of met multiviews) moet je zelf weten, maar hou in je achterhoofd dat multiviews niet de rewrite engine gebruikt en daardoor ook 'iets' sneller is.
Alleen dat heeft een prijs, je applicatie moet het wel ondersteunen, en dat kan alleen als je voor manier 2 kiest, je kan er dan voor kiezen om eventueel beide mogelijkheden in te bouwen: via GET variabelen ?page=1 en via multiviews: /showpage/1

Als iemand er nog een andere mening op na houdt, of een sterk argument heeft om mij van dit dwalend pad af te helpen, dan hoor ik dat graag natuurlijk.

Mocht je voor manier 1 uiteindelijk gaan kiezen, zorg er voor dat je geen dubbel werk gaat doen, of dubbele files includen. Ik snap wel dat je met een include_once of require_once hetzelfde bereikt, maar ik vind dat als je die _once dingen gebruikt je niet goed nadenkt over waar je nu mee bezig bent.

[ Voor 23% gewijzigd door Erkens op 16-12-2003 09:18 ]

Onderwerpen