de l'interet des sites index.php?rub

Bruno seul contre tous... JM à la rescousse :)

Aucun intérêt.
C'est pas pratique, moche et ça ne va pas dans le sens des URI

significatives.

Ça fait pas vraiment avancer le débat tout ça...

voila, j'ai constate que de nombreux sites font passer toutes leurs
pages par une seule page telle que index.php?rub=<x> ou <x> va etre

une multitude de chiffres... mais je ne comprends pas quel est
l'interet de l'approche ni meme comment cela fonctionne quelqu'un
pourrait il m'expliquer ou me pointer sur une url qui fait ca ?

Tout dépend des méthodes de conception et de développement du site choisies.
Ici je pense au framework Fusebox (issu de ColdFusion) qui propose
d'utiliser un script unique pour traiter tout ou partie du site et de passer
une action en paramètre, ici une « rub »-rique.

On se retrouve avec des URLs comme :
- index.php?action=presentation
- index.php?action=contact
- index.php?action=produits
...

Le script index.php s'occupe ensuite d'inclure les scripts qui se chargent
d'afficher tel ou tel page (Présentation, Produits...). Il peut s'agir de
monter des modèles pour présenter une page à partir de scripts, de gabarits
HTML... Ou encore de traiter un formulaire, de la valider... Si le
formulaire est « posté » alors l'action n'est pas visible mais elle est bien
là, gérée par le script.

Quel intérêt ?

Aucun :). Je plaisante Macromedia n'a pas introduit ColdFusion sans penser à
l'intérêt qu'il pourrait avoir pour la communauté.

Pour simplifier Fusebox est un framework qui propose une méthode simple et
efficace pour concevoir un site. Je ne suis pas certain que l'utilisation de
différents scripts, nommés différemment, soit un « framework », tout dépend
après de la conception qui est derrière mais comme vous l'avez présentée...
Dans un sens ça rejoint sans doute Fusebox. Un avantage c'est de camoufler
le « backend » du site, si vous changez de méthode on y voit que du feu et
les URLs n'ont aucune raison de changer. Ce qui n'est pas le cas pour
l'utilisation de multiples fichiers, ils sont toujours amenés à être
renommer, déplacer... La hiérarchie du site est flexible alors que Fusebox
vous permet d'avoir une hiérarchie à la fois modulaire mais « pérenne ».
Surtout lorsque l'on utilise des ids incrompéhensibles, l'id ne change pas,
le titre d'un article oui et peut même entrer en conflit avec les autres
ressources du site. D'ailleurs comment choisir un titre explicite, utilisé
dans l'URL, pour un article qui aurait pour titre « Conception et
Développement d'un site PHP avec Fusebox ». Vous choisiriez « php_fusebox »
? « conception_developpement_site_php_fusebox » ? Ou tout simplement l'id
qui identifie de manière unique l'article dans votre BDD ? « 103 », par
exemple :
- www.site.com/articles/103
ou
- www.site.com/articles/php_fusebox

Dans le second cas on a bien une URL explicite mais quel intérêt ? Le
visiteur va-t-il mémoriser l'URL dans sa mémoire et revenir sur le site...
Et la taper dans son navigateur ? Sûrement pas, il va l'ajouter à ses
marque-pages, faire une recherche de « php fusebox » sur le site à partir du
formulaire recherche ou utiliser le plan du site ou ses rubriques pour
retrouver l'article. Ça n'est pas parce que l'URL du site est là, affichée
dans le navigateur, qu'elle est forcément utile. Un site bien conçue ne
repose pas sur des URLs explicites mais plutôt sur logique sans faille et
évidente pour ses visiteurs. De plus la « branche » sur laquelle se trouve
le visiteur (Accueil > Articles > PHP Fusebox) doit être précisée quelque
part sur le site, généralement au dessus du contenu de la ressource, de
l'article. Ça permet de remonter dans l'arborescence sans avoir à jouer avec
l'URL « explicite ».

Ça n'est pas parce que cette méthode est différente de la votre, nouvelle,
que vous devez la juger comme « sans intérêt ». Il faut savoir vous adapter
aux changements pour ne pas rester à la traîne. Je ne dis pas que c'est
mieux mais une framework utilisé par des milliers de personnes apporte
forcément quelque chose de plus.

Le plus c'est une méthode unique, un standard. Rien ne régit l'organisation
d'un amalgame de fichiers sur vos serveurs, sauf vous, c'est une
organisation « subjective » qui ne repose sur aucune méthode en particulier,
un peu chaotique pour certains :). Si vous parlez Fusebox, de nombreux
interlocuteurs peuvent vous comprendre. On passe les actions en paramètre,
un simple switch se charge ensuite d'appeler les fonctions, d'inclure les
scripts qui se chargent du traitement. Rien ne vous empêche ensuite
d'étendre cette logique à plusieurs pages, on a jamais dit le contraire.
Mais l'ambition c'est d'être organisé dans le développement et la
réalisation de l'application. Si on ne sait pas comment faire les choses et
où l'on va, on n'aboutie à rien.

Si, pour la personne qui réalise et maintient le site.

Le choix des méthodes sont subjectives. Si la méthode choisie (ici je
parlais de Fusebox) est adaptée aux besoins du développeur, tout est pour le
mieux. Il ne faut pas choisir une méthode sans connaître ses avantages et
inconvénients. Je vous renvoie au site de Fusebox pour en apprendre plus sur
le sujet et vous convaincre un peu plus de son intérêt :).

Certains y verront un moyen de modéler un code adapté à leur conception.
L'approche 1 fichier, des actions, des switches, des scripts... recoupe un
peu certains concepts MVC, MFC... Pour ceux qui connaissent ou souhaitent
découvrir :).

Il est (au moins dans certains cas) possible d'avoir une URL 'publique'
propre, qui est transformée par mod_rewrite en URL du type cité par l'OP.

En effet rien n'empêche, comme je l'ai indiqué en haut d'utiliser
mod_rewrite pour afficher une URL plus « explicite » :
- http://www.monsite.com/index.php?action¯ficher_articles&id_article3
en
- http://www.monsite.com/articles/103

Donc j'approuve totalement la réécriture de l'URL, dans un sens je suis en
désaccord avec Bruno :). La seconde URL vous paraîtra forcément plus
lisible. On peut même envisager de la renommer autrement, en passant un
autre paramètre, le titre raccourci de notre article :
-
http://www.monsite.com/index.php?action¯ficher_articles&id_article3&titre_article=php_fusebox
(ça ressemble à s'y méprendre à du PHP Nuke ^^)
en
- http://www.monsite.com/articles/php_fusebox

On remplace l'id, qui ne représente rien pour le visiteur, en un titre plus
explicite. C'est à voir, je ne suis pas convaincu de l'intérêt du système.
Il faudrait même ajouter plus d'informations pour que l'URL soit « unique »
et surtout PERMANENTE. Le titre de l'article n'est pas toujours bien choisi,
on peut décider qu'il fait désormais parti d'une série d'articles sur la
conception PHP à partir de frameworks Fusebox, MVC... On se retrouve alors à
renommer le titre raccourci alors que l'id de l'article, lui est toujours le
même.

Désolé pour le chaos dans lequel ce message a été écrit mais j'ai un peu
répondu à tout le monde. J'espère ne pas avoir trop perdu Tlo avec mes
explications chaotiques :).

JM

--
Boycothon (Contre l'e-censure) : http://www.odebi.org/boycothon/ ~ « Le LEN
tue la démocratie ».

Jean-Marc Molina wrote:

Bruno seul contre tous... JM à la rescousse :)

Ouf ! Me voilà donc sauvé !-)

(snip)

Il est (au moins dans certains cas) possible d'avoir une URL 'publique'

propre, qui est transformée par mod_rewrite en URL du type cité par l'OP.

En effet rien n'empêche, comme je l'ai indiqué en haut d'utiliser
mod_rewrite pour afficher une URL plus « explicite » :
- http://www.monsite.com/index.php?action¯ficher_articles&id_article3
en
- http://www.monsite.com/articles/103

Donc j'approuve totalement la réécriture de l'URL, dans un sens je suis en
désaccord avec Bruno :).

Heu... sur quel point ? Là je ne vois pas.

La seconde URL vous paraîtra forcément plus

lisible. On peut même envisager de la renommer autrement, en passant un
autre paramètre, le titre raccourci de notre article :
-
http://www.monsite.com/index.php?action¯ficher_articles&id_article3&titre_article=php_fusebox
(ça ressemble à s'y méprendre à du PHP Nuke ^^)
en
- http://www.monsite.com/articles/php_fusebox

On remplace l'id, qui ne représente rien pour le visiteur, en un titre plus
explicite. C'est à voir, je ne suis pas convaincu de l'intérêt du système.
Il faudrait même ajouter plus d'informations pour que l'URL soit « unique »
et surtout PERMANENTE.

Ce qui est le fond de l'article 'cool URL dont change', mais je ne suis
pas sûr que tout le monde ait bien compris !-)

Ceci étant, tout n'est pas permanent... Par exemple, le résultat d'une
requête sur Google est, *par définition*, un contenu à brève durée de vie.

Mais bon, il me semble surtout que notre cher Bobe n'a pas bien compris
la question de l'OP...

Mes deux centimes,
Bruno

Message d'origine de Tlo :

voila, j'ai constate que de nombreux sites font passer toutes leurs
pages par une seule page telle que index.php?rub=<x> ou <x> va etre
une multitude de chiffres... mais je ne comprends pas quel est
l'interet de l'approche ni meme comment cela fonctionne quelqu'un
pourrait il m'expliquer ou me pointer sur une url qui fait ca ?

Personnellement, je n'y trouve aucun intérêt.
Tu fais tapage.php dans laquelle tu fais include 'header.php' et include
'footer.php' et ça revient au même.
De toute façon t'es obligé, même avec les pseudo-frames, de faire un
include dans les pages pour vérifier que l'utilisateur n'arrive pas par
un autre chemin que index.php?rub=x

Bruno Desthuilliers nous a dit le 01/02/2004 12:31:

C'est pas pratique,

En quoi ?

Que faire si une partie du site devient statique ?
Si on change de langage serveur ? (bon, là ok, c'est juste une histoire
d'extension)

moche

Mon Dieu, quelle horreur, une URL avec une requête dedans, beurk !-)

Tu l'as dit. Une URI contenant une requète. Je dirais plutôt un argument. On a
donc là une URI instable en quelque sorte.

Dans le cas où l'on demande un document précis (article, etc...), pourquoi
passer des arguments dans l'url ? On ne demande pas un traitement, simplement
afficher un document.
Dans le cas d'un moteur de recherche par contre, c'est tout à fait adéquat de
passer la chaine à rechercher par l'url.

et ça ne va pas dans le sens des URI significatives.

Le problème de URI significatives est différent. De plus, les 'requêtes'
font partie de la RFC décrivant ce que peut être une URL, et une requête
en clair (cf google...) est en soi significative AMHA.

Dans le cas de Google, voir ma réponse juste au dessus.

L'essentiel n'est pas d'avoir de "belles URI", mais de proposer un
contenu intéressant. Enfin, c'est au moins mon humble avis.

Oui mais des URI qui signifie quelque chose (au passage, google tient compte
des mots présent dans une url et n'aime pas trop en revanche les urls
contenant trop d'arguments) est toujours un plus :)

--
Bobe (Aurélien Maille)
http://webnaute.net

"la vie d'un geek est un combat perpétuel contre l'imperfection"

Bobe wrote:

Bruno Desthuilliers nous a dit le 01/02/2004 12:31:

C'est pas pratique,

En quoi ?

Que faire si une partie du site devient statique ?
Si on change de langage serveur ? (bon, là ok, c'est juste une histoire
d'extension)

Bin, l'URL change, et puis voila !-)

Bon, rassure-toi, j'avais déjà lu 'cool URIs dont change' avant que tu
ne lance ce débat, et l'article n'est pas idiot, loin s'en faut. Mais de
là à en faire un impératif ou un débat de fond, ça me parait un poil trop.

moche

Mon Dieu, quelle horreur, une URL avec une requête dedans, beurk !-)

Tu l'as dit.

Heu... Tu n'a pas remarqué comme une légère nuance d'ironie ?-)

Une URI contenant une requète. Je dirais plutôt un
argument. On a donc là une URI instable en quelque sorte.

Pas forcément tant que ça... mais bon.

Dans le cas où l'on demande un document précis (article, etc...),
pourquoi passer des arguments dans l'url ? On ne demande pas un
traitement, simplement afficher un document.

Q : comment es-tu arrivé à ce document ?
R : en suivant un lien
Q : si le document t'intéresse, que va tu faire ?
R : le bookmarquer
Q : combien de personnes vont *réellement* regarder si l'URL est du type
"monsite.com/categorie/article/"
ou du type
"monsite.com/index.php?catÊtegorie&art=article" ?
R : une poignée extrêmement minoritaires d'intégristes qui ont lu
'cool URIs dont change' !-)

(bon, je provoque un peu pour la dernière, mais sérieusement, c'est un
peu de cet ordre là).

Je suis bien d'accord qu'un petit mod_rewrite permet de régler la chose,
je précise juste que ce n'est pas forcément la priorité n°1, ni ce qui
déterminera en premier lieu la qualité du site.

Un site avec des frames qui font que tu te retrouve sur l'accueil au
lieu de l'article que tu avais bookmarqué, là par contre c'est
*vraiment* ch...

Dans le cas d'un moteur de recherche par contre, c'est tout à fait
adéquat de passer la chaine à rechercher par l'url.

N'est-ce pas ?-)

et ça ne va pas dans le sens des URI significatives.

Le problème de URI significatives est différent. De plus, les
'requêtes' font partie de la RFC décrivant ce que peut être une URL,
et une requête en clair (cf google...) est en soi significative AMHA.

Dans le cas de Google, voir ma réponse juste au dessus.

Heu... lequel est le plus "parlant", pour toi ?
a/ 'monsite.com/index.php?categorie=webdesign&article=coolurls'
b/ 'monsite.com/foo00025/42bAz/thx1136.html'

L'essentiel n'est pas d'avoir de "belles URI", mais de proposer un
contenu intéressant. Enfin, c'est au moins mon humble avis.

Oui mais des URI qui signifie quelque chose (au passage, google tient
compte des mots présent dans une url et n'aime pas trop en revanche les
urls contenant trop d'arguments) est toujours un plus :)

C'est un plus si ça ne vient pas au détriment d'autre chose.

Bon, je me fais un peu l'avocat du diable, et je suis bien d'accord sur
l'idée que dans l'absolu, là où ça peut s'appliquer, une URL *stable* -
et, accessoirement, si possible, un tant soit peu explicite - ne gâche
rien. De là à affirmer péremptoirement que les requêtes ne servent à
rien et sont moches...

Et aussi, pour revenir à la question de l'OP et au sujet de ce NG : je
ne pense pas que ta réponse - sans préjuger de l'intérêt du débat sur
les URLs - était vraiment en rapport avec la question de l'OP, qui me
semblait plus 'technique' ('ça correspond à quoi ces requêtes, qu'est-ce
qui se passe derrière etc') que théorique ('est-ce une bonne idée ?')

Mes deux centimes,
Bruno

Personnellement, je n'y trouve aucun intérêt.
Tu fais tapage.php dans laquelle tu fais include 'header.php' et include
'footer.php' et ça revient au même.

Ca commence à avoir intéret sur des sites de plusieurs centaines de pages,
pour eviter d'avoir des tonnes de fichiers physiques alors que les contenus
sont stockées dans la base. Et ça permet de rajouter des pages sans avoir a
poser un seul fichier.

--
Frédéric

Bruno Desthuilliers nous a dit le 02/02/2004 10:38:

Bon, rassure-toi, j'avais déjà lu 'cool URIs dont change' avant que tu
ne lance ce débat, et l'article n'est pas idiot, loin s'en faut. Mais de
là à en faire un impératif ou un débat de fond, ça me parait un poil trop.

Pas un impératif, mais ce serait dommage de ne pas faire les choses au mieux,
si on en a les possibilités techniques/le temps de se pencher sur la
question/l'envie de perfection.
Mais combien de fois suis je tombé sur des erreurs 404 parce que le
gestionnaire du site avait modifié ses urls pour la n-ième fois, et qu'aucune
redirection n'était effectuée, m'obligeant à une longue recherche sur le site
en question pour /peut-être/ retrouvé le document recherché au départ ? Souvent.
L'échange et la diffusion de liens vers des documents est quand même la base
du web non ? Je serais bien embété si la majorité des liens donnés dans
l'annexe de la recommandation sur html 4.01, par exemple, étaient cassés.
Donc si je peux montrer à une ou plusieurs personnes l'utilité des uri
significatives, tant mieux.

Mon Dieu, quelle horreur, une URL avec une requête dedans, beurk !-)

Tu l'as dit.

Heu... Tu n'a pas remarqué comme une légère nuance d'ironie ?-)

C'était à prendre avec la suite du texte ;-)

Une URI contenant une requète. Je dirais plutôt un argument. On a donc
là une URI instable en quelque sorte.

Pas forcément tant que ça... mais bon.

On est + tenté de peaufiner/modifier son système (nom d'argument ne convenant
pas ou plus, ajout d'autres arguments pour une raison ou une autre, ...)

Dans le cas de Google, voir ma réponse juste au dessus.

Heu... lequel est le plus "parlant", pour toi ?
a/ 'monsite.com/index.php?categorie=webdesign&article=coolurls'
b/ 'monsite.com/foo00025/42bAz/thx1136.html'

Comme je l'ai dit, dans le cas d'un moteur de recherche par exemple, où
forcément la page retournée n'est à priori jamais pareil, passer les arguments
dans l'url est bien.
Dans le cas d'un document *fixe*, monsite.com/Webdesign/CoolURI/ me semble
très bien. (et plus court que la première option)

Bon, je me fais un peu l'avocat du diable, et je suis bien d'accord sur
l'idée que dans l'absolu, là où ça peut s'appliquer, une URL *stable* -
et, accessoirement, si possible, un tant soit peu explicite - ne gâche
rien. De là à affirmer péremptoirement que les requêtes ne servent à
rien et sont moches...

Je suis allé un peu vite certes. Cette première réponse s'appliquait dans le
cas d'un document fixe, non pas dans un cadre général.

Et aussi, pour revenir à la question de l'OP et au sujet de ce NG : je
ne pense pas que ta réponse - sans préjuger de l'intérêt du débat sur
les URLs - était vraiment en rapport avec la question de l'OP, qui me
semblait plus 'technique' ('ça correspond à quoi ces requêtes, qu'est-ce
qui se passe derrière etc') que théorique ('est-ce une bonne idée ?')

Certes. Et si les modérateurs pensent que je suis hors-sujet ou hors-charte,
je pense qu'ils n'hésiteront pas à me le faire savoir. :)
Mais si cette personne a posé cette question sur les pseudo-frames, même si
c'est essentiellement sur l'aspect technique, cela veut dire qu'elle s'y
interesse. On peut donc penser qu'elle songe à utiliser un tel système, d'où
mon intervention.

--
Bobe (Aurélien Maille)
http://webnaute.net

"la vie d'un geek est un combat perpétuel contre l'imperfection"

Frederic Jacquot - spam@logeek.com :

Personnellement, je n'y trouve aucun intérêt.
Tu fais tapage.php dans laquelle tu fais include 'header.php' et
include 'footer.php' et ça revient au même.

Ca commence à avoir intéret sur des sites de plusieurs centaines de
pages, pour eviter d'avoir des tonnes de fichiers physiques alors que
les contenus sont stockées dans la base. Et ça permet de rajouter des
pages sans avoir a poser un seul fichier.

A condition que ces centaines de pages aient pour point commun d'être
statiques. C'est à dire du pure html.

Si dans ton site tu as des scripts divers correspondant à des fonctions
bien différentes je ne vois pas en quoi la base y change quelque chose.

"Zouplaz" <pouet@pouet.com> a écrit dans le message news:
Xns9483BC17F796DZoupla@213.228.0.133...

Frederic Jacquot - spam@logeek.com :


Si dans ton site tu as des scripts divers correspondant à des fonctions
bien différentes je ne vois pas en quoi la base y change quelque chose.

On peut voir ça aussi comme une méthode de programmation. On ne considère
plus l'URL comme un fichier mais comme une ressource abstraite qui peut
faire appel à différent types de flux (fichiers PHP, HTML, XML, BdD, RSS
etc.). Ca favorise le découplage données / présentation.

Ca commence à avoir intéret sur des sites de plusieurs centaines de
pages, pour eviter d'avoir des tonnes de fichiers physiques alors que
les contenus sont stockées dans la base. Et ça permet de rajouter des
pages sans avoir a poser un seul fichier.

A condition que ces centaines de pages aient pour point commun d'être
statiques. C'est à dire du pure html.

Non ce n'est pas une nécessité.

Si dans ton site tu as des scripts divers correspondant à des fonctions
bien différentes je ne vois pas en quoi la base y change quelque chose.

je dois avouer que "des scripts divers correspondant à des fonctions bien
différentes" c'est un peu trop abstrait pour que je puisse te répondre :)

--
Frédéric