Talk:Coding FAQ: Difference between revisions
imported>Claratte No edit summary |
imported>Claratte No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 17: | Line 17: | ||
au niveau de la simplicité de l'url, je ne comprends pas en quoi c'est si bien ? des sites genre google, amazon et quasiment tout ceux que je connais ne se posent pas trop cette question. | au niveau de la simplicité de l'url, je ne comprends pas en quoi c'est si bien ? des sites genre google, amazon et quasiment tout ceux que je connais ne se posent pas trop cette question. | ||
--[[User: | --[[User:KAeL|KAeL]] 12:00, 4 Jul 2005 (CEST) | ||
Cela multiplie le nombre de fichiers dans le répertoire racine. | |||
je suis d'accord sur le fait qu'il est possible d'utiliser un include de sécu. Mais dans ce cas, il faut aussi inclure dans chaque fichier tous les fichiers génériques (gestion des langues par exemple), ou alors utiliser un fichier qui contiendra tout cela, ce qui revient à refaire un index.php mais en include. Ne serait-ce que l'ini-set qu'il faudra faire dans chaque fichier. | |||
Si index.php est une usine à gaz, c'est qu'il est mal fait. Mais je préfère maintenir une usine à gaz que dix usines à gaz. | |||
L'utilisateur référence ce qu'il veut, mais c'est dommage qu'il référence une page qui peut devenir un lien mort. | |||
En fait, je ne vois pas ce que cela apporte... ;-) | |||
--[[User:Claratte|Christophe]] 12:11, 4 Jul 2005 (CEST) | |||
Latest revision as of 11:11, 4 July 2005
Pourquoi je n'aime pas " l'url unique " :
le fait d'avoir plusieurs fichiers en racine permet tt de même de protéger certains fichiers en les mettant ds des sous dossiers en 'deny all'.
au niveau sécu : c'est pas compliqué d'include ds chaque page pouvant être appelée un truc genre secu.php qui gère ça. (utilisation courante qd on utilise la classe PEAR::Auth par exemple)
au niveau maintenance : il faut maintenir une page en plus : index.php, qui a rapidement tendance à devenir une usine à gaz
au niveau des chemins d'accès, mettre tout les fichiers pouvant être inclus dans un répertoire 'include' (ou plusieurs) et configurer php pour mettre ces dossiers ds le include_path par défaut, ça se fait bien aussi. (les fichiers ne bougeant pas de place, on peut aussi utiliser des chemins relatifs). et sinon, on peut toujours utiliser $_SERVER['DOCUMENT_ROOT'] par exemple pour faire le ini_set include_path... (je reconnais qu'avec un fichier c'est plus pratique, mais avec plusieurs ça n'a rien d'insurmontable)
Je vois pas le pb pour un utilisateur de referencer une page autre que index ? il fait ce qu'il veut.
au niveau de la simplicité de l'url, je ne comprends pas en quoi c'est si bien ? des sites genre google, amazon et quasiment tout ceux que je connais ne se posent pas trop cette question.
--KAeL 12:00, 4 Jul 2005 (CEST)
Cela multiplie le nombre de fichiers dans le répertoire racine.
je suis d'accord sur le fait qu'il est possible d'utiliser un include de sécu. Mais dans ce cas, il faut aussi inclure dans chaque fichier tous les fichiers génériques (gestion des langues par exemple), ou alors utiliser un fichier qui contiendra tout cela, ce qui revient à refaire un index.php mais en include. Ne serait-ce que l'ini-set qu'il faudra faire dans chaque fichier.
Si index.php est une usine à gaz, c'est qu'il est mal fait. Mais je préfère maintenir une usine à gaz que dix usines à gaz.
L'utilisateur référence ce qu'il veut, mais c'est dommage qu'il référence une page qui peut devenir un lien mort.
En fait, je ne vois pas ce que cela apporte... ;-)
--Christophe 12:11, 4 Jul 2005 (CEST)