nicht angemeldet
Hi!
[..] das Vermischen von URL-Pfaden mit GET-Parametern halte ich für sehr schlecht.
Das ist es auch. Es ist so grottenschlecht, dass es mir unbegreiflich ist, dass das überhaupt jemand macht.
Nun mal langsam. Sicher gibt es Anwendungsfälle, wo einem das Umschreiben von Pfadteilen auf GET-Parameter im Weg steht, weil man letztere für andere Anwendungsfälle benötigt. Wer sich nun wegen einer schlechten Erfahrung aus einem Projekt mit solchen Anforderungen, prinzipiell gegen ein solches Umschreiben entscheidet, schränkt sich meiner Meinung nach nur unnötig in seinen Möglichkeiten ein.
Es gibt sicher viele, die es gar nicht anders k{e|ö}nnen, als umzuschreiben. Und "jemand" macht das, weil "jemand" es öfter so sieht. Irgendwer hat damals, als "SEO"-URLs in Mode kamen, sein bestehendes Querystring auswertendes Script einfach mit einer oder wenigen RewriteRules versehen, und hatte sehr schnell ein Ergebnis, ohne in das Script eingreifen zu müssen. Es hat funktioniert, warum also das Prinzip nicht weiterverwenden, wenn es für einfache Fälle keine Nachteile hat? In der Tat kann man damit einfach auf Einträge im Array $_GET zugreifen und muss sich nicht erst noch mit dem Auseinandernehmen von REQUEST_URI oder PATH_INFO beschäftigen.
Begründung, warum das schlecht ist: Konflikte zwischen URL-Namen und Parameter-Namen sind unvermeidlich.
Unsinn. Sie sind vermeidbar, wenn man seine Bezeichner sorgfältig wählt.
Jedesmal, wenn ein neuer URL ins Web gestellt werden soll, wäre zu prüfen, ob es Kollisionen gibt.
Das ist auch nicht wahr. Mit der mod_rewrite-Methode kann man nur feste Umschreibungen vornehmen. Angenommen es sind drei Pfadteile auszuwerten, dann schreibt die RewriteRule diese Pfadteile auf drei Parameter mit genau definierten Namen um. Kommt eine URL hinzu, wird diese ebenfalls wieder auf genau diese drei Parameter mit ihren gleichbleibenden Namen umgeschrieben. Wo sollen da Kollisionen herkommen? Etwas mit Formularen, die per GET abgesendet werden? Nun, dann muss man die Namen seiner Formularelemente gegen genau drei andere Parameternamen prüfen. Welch ein Aufwand!!!einself
Es ergäbe sich eine unvermeidliche Abhängigkeit zwischen Konfiguration und Programmcode und ein Programmieraufwand, sowas zu vermeiden ist nicht vertretbar.
Wenn der Anwendungsfall ist, URLs mit einer immer gleichbleibenden Anzahl Pfadteile zu haben, dann ist die Abhängigkeit des Script von der RewriteRule kein Beinbruch. Es wäre eher zu fragen, ob es vertretbar ist, für diesen einfachen Fall einen flexiblen Auswertemechanismus zu schreiben.
Und wenn sich später die Anforderungen ändern? Den Fall betrachten wir später. Zunächst erst einmal gilt YAGNI. Wichtig ist nur, sich diese Möglichkeit nicht zu verbauen, sondern sein Script so zu schreiben, dass man später leicht den Routingmechanismus austauschen/anpassen kann.
Ach ...
Vorschlag: _ein_ URL, mehrere Sprachen.
[...] Anhand der Browsereinstellungen hinsichtlich der bevorzugten Sprache wird dann der entsprechende Content geliefert. Nicht vergessen, eine Default_Language festzulegen und dem Besucher die Möglichkeit zu geben, die Sprache unabhängig von den Browsereinstellungen ändern zu können.
Ergibt dann n+1 URL mit n=Anzahl der Sprachen und steht im Widerspruch zur ersten Empfehlung. Es sei denn, du meinst, man sollte die gewählte Sprache per Cookie übertragen - ist nicht unbedingt Suchmaschinen-Crawler-freundlich.
Lo!