Pages dynamiques et conflits d'URL non résolus

Question

J'ai fait quelques recherches sur la façon dont d'autres sites pourraient gérer cela et n'ont pas vraiment vu quelque chose qui m'a sauté aux yeux. Je travaille sur un projet dans lequel vous pouvez créer des pages liées à partir de toutes les autres pages. Voici où le problème se pose pour moi.

Je ne sais pas comment je devrais faire pour relier ces pages. Je n'ai vraiment pensé à deux idées, eux étant:

1. website.com/page/My-Page-Name
2. website.com/My-Page-Name

Pour noter, j'utilise mod_rewrite pour les rediriger vers un fichier qui prend le nom de page un paramètre et saisit toutes les informations pertinentes de la DB et l'affiche. C'est là qu'un problème se développe pour l'idée n ° 2.

Idée # 1 œuvres et est solide, mais je pense que c'est un peu laid et vous ne voyez pas beaucoup de sites qui pointent vers d'autres pages du site avec d'autres informations capitonné dans l'URL.

EDIT pour un peu de clarté. L'intention desdites pages doit être statique dans le sens où elles ne montreront jamais que ce que l'utilisateur leur a demandé d'afficher. Ils n'écarteront jamais aucune sorte de données, auquel cas les pages formatées comme dans cet exemple seraient plus appropriées. Je comparerais ces pages plus vers les faq de SO ou vers la page qui n'ont pas d'URL formatées de cette manière.

L'idée n ° 2 semble plus propre mais rencontre des problèmes lors de l'utilisation de mod_rewrite et de la création de ces pages.

D'autres parties du site qui sont liées peuvent être imitées et provoquer des conflits si vous avez nommé la même page. Par exemple, website.com/page1/ points à la page1 qui existe déjà, mais un conflit se poserait si quelqu'un voulait créer une page appelée page1. Donc, en mettant en œuvre cette idée, je devrais filtrer et limiter l'utilisateur dans quels noms de pages ils pourraient utiliser et en même temps cela pourrait rendre la fonctionnalité un peu inintéressante et les laisser se gratter la tête. De plus, cela semble un peu moche de le coder, d'avoir un tableau de noms de pages inacceptables et d'avoir à vérifier.

Le dernier bit traitant de mod_rewrite pour rediriger vers quelque chose comme ça: RewriteRule ^([A-Za-z0-9-]+)$ getPage.php?p=$1 devient un peu moche car il devient un peu gourmand, tout en limitant ce qu'il va sauf.

Alors, est-ce que quelqu'un a un aperçu sur d'autres méthodes possibles pour résoudre ce problème ou comment l'implémentation de l'un des deux mentionnés pourrait être différente/meilleure?

Merci.

Answer 1

Je suis d'accord que l'idée # 1 (website.com/page/My-Page-Name) est meilleur. Il évite le crénelage et rend le reste du code plus propre (par exemple, la règle de réécriture ne fait que regarder /page/.*). Parmi les sites populaires qui utilisent cette technique sont Wikipédia (http://en.wikipedia.org/wiki/ C), Everything2 (http://everything2.com/title/ Archive + cool de) et Answers.com (http://www.answers.com/sujet/ exquis).

EDIT: L'idée 2 peut fonctionner si vous distinguez les pages utilisateur des pages au cas par cas. la partie chemin d'une URL est sensible à la casse, et une règle de réécriture peut facilement vérifier cela. Exemple:

http://example.com/faq < - la page de FAQ intégrée au site Web.

http://example.com/Faq < - page d'un utilisateur.

http://example.com/Frequently-asked-questions < - une autre page de l'utilisateur.

Je serais toujours aller aveC# 1 pour plus de simplicité et de convivialité, mais cela évite au moins aliasing.

Answer 2

Je voudrais aller avec # 1, c'est une convention assez commune et évite les problèmes potentiels. Vous avez dit que vous ne l'avez pas vu des sites ne présente, semble-t-vous havent vers le haut échangèrent un regard

(look up) 
    ^
     | 
http://stackoverflow.com/questions/2121720/dynamic-pages-and-clean-url-conflicts 
         ^^^^^^^^^ 

autres exemples:

http://dsc.discovery.com/videos/mythbusters-raw-kari-goes-macgirlver.html 
         ^^^^^^ 

http://www.hulu.com/watch/115500/the-colbert-report-alicia-keys-and-stephen-perform 
        ^^^^^ 

Une autre alternative consiste à rembourrer le pages intégré et ont le contenu généré par être dans la racine de l'URL.Et par exemple est le wiki Tcler:

http://wiki.tcl.tk/_/recent  <-- special page padded with _ 
http://wiki.tcl.tk/coroutine  <-- user generated content