nicht angemeldet
mod_rewrite oder path_info?
Hallo =)
Bisher benutze ich folgendes:
Pfad:
http://localhost/index.php/var/
dabei wird die index.php aufgerufen und die variable var zum anzeigen bestimmter inhalt verwendet.
jetzt möchte ich auch noch die sprache über die url mitgeben, und eventuell den "index.php"-part fallen lassen, da eh immer nur die index.php aufgerufen wird.
das ganze soll dann ungefähr so aussehen:
http://localhost/de/var
wie kann ich das machen?
lg, jens
-
Hi!
http://localhost/index.php/var/
dabei wird die index.php aufgerufen und die variable var zum anzeigen bestimmter inhalt verwendet.Das ist keine Variable, URLs sind keine Programmiersprache.
jetzt möchte ich auch noch die sprache über die url mitgeben, und eventuell den "index.php"-part fallen lassen, da eh immer nur die index.php aufgerufen wird.
http://localhost/de/var
wie kann ich das machen?Mit mod_rewrite so umschreiben, das der Teil, wofür hier stellvertretend /de/var steht, an /index.php angehängt wird. Im Script kannst du dann die PATH_INFO auswerten. Alternativ kannst du auch die beiden Werte zu einem Query-String umschreiben, aus dem PHP dann Werte für $_GET generiert. Dies eignet sich aber nur für feste Strukturen, mit PATH_INFO ist man da felxibler (hat aber auch etwas mehr Arbeit beim Auseinandernehmen).
Lo!
-
Moin!
Mit mod_rewrite so umschreiben, das der Teil, wofür hier stellvertretend /de/var steht, an /index.php angehängt wird. Im Script kannst du dann die PATH_INFO auswerten. Alternativ kannst du auch die beiden Werte zu einem Query-String umschreiben, aus dem PHP dann Werte für $_GET generiert. Dies eignet sich aber nur für feste Strukturen, mit PATH_INFO ist man da felxibler (hat aber auch etwas mehr Arbeit beim Auseinandernehmen).
Würde ich beides nicht tun.
Rewriting auf /index.php (sofern die Ressource auf dem Server nicht existiert) vornehmen. Dort dann die angeforderte URL parsen - alle Infos stehen in $_SERVER zur Verfügung (z.B. REQUEST_URI), das Vermischen von URL-Pfaden mit GET-Parametern halte ich für sehr schlecht. PATH_INFO wäre ebenfalls nicht wirklich gut brauchbar - der Zustand besteht ja bereits jetzt.
Wenn einem das Rewriting nicht gefällt: Apache ab Version 2.2 kriegt dieses Verhalten auch so hin. http://httpd.apache.org/docs/2.2/mod/mod_dir.html#fallbackresource.
- Sven Rautenberg
-
Moin,
[..] 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.
Begründung, warum das schlecht ist: Konflikte zwischen URL-Namen und Parameter-Namen sind unvermeidlich. Jedesmal, wenn ein neuer URL ins Web gestellt werden soll, wäre zu prüfen, ob es Kollisionen gibt. Es ergäbe sich eine unvermeidliche Abhängigkeit zwischen Konfiguration und Programmcode und ein Programmieraufwand, sowas zu vermeiden ist nicht vertretbar.
Noch besser: Die Liste der Parameter auf URLs privatisieren, d.h., URL-selektive Parameter, dann bleibt der Code auch überschaubar und die programmiertechnische Festlegung der Parameternamen ist nicht nur unabhängig vom URL-Namen sondern auch unabhängig von Parameternamen, die an anderen URLs verwendet werden.
Hotti
-
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!
-
hi,
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
Denk mal ein bischen weiter: Das Script soll aus der Hand gegeben werden, Programmierer und Anwender kennen sich nicht. Soll ein Anwender jedesmal, wenn er einen neuen URL konfigurieren möchte, den Programmierer fragen, ob es auch keine Kollisionen mit Parameternamen gibt? Die Frage ist selbsterklärend ;)
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
Nein. Es gibt einen URL, nur der Inhalt wird ggf. in verschiedenen Sprachen ausgeliefert.
Hotti
-
Hi!
Das Script soll aus der Hand gegeben werden, Programmierer und Anwender kennen sich nicht. Soll ein Anwender jedesmal, wenn er einen neuen URL konfigurieren möchte, den Programmierer fragen, ob es auch keine Kollisionen mit Parameternamen gibt? Die Frage ist selbsterklärend ;)
Wozu sollte er eine neue URL erstellen, wenn nicht um etwas Vorhandenes zu erweitern oder etwas neues zu erstellen? Dazu ist es zwingend notwendig, sich mit dem System auszukennen. Das Konfliktpotential ergibt sich dann aufgrund der Sorglosigkeit des Anwenders, und nicht prinzipiell. Gegen Inkompetenz hilft auch kein noch so ausgeklügeltes System.
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
Nein. Es gibt einen URL, nur der Inhalt wird ggf. in verschiedenen Sprachen ausgeliefert.Und wie genau soll das passieren? Wie soll es gehen, "die Sprache unabhängig von den Browsereinstellungen ändern zu können", wenn nicht über eine andere URL?
Lo!
-
-
-
-
-
-
hi,
jetzt möchte ich auch noch die sprache über die url mitgeben, und eventuell den "index.php"-part fallen lassen, da eh immer nur die index.php aufgerufen wird.
Vorschlag: _ein_ URL, mehrere Sprachen.
wie kann ich das machen?
URLs zweckmäßig verwalten. Rewrite legt jeden Requested URL auf index.php um, dieses Script schaut in eine Tabelle und bekommt die Eigenschaften zum URL geliefert, z.B. die Sprachen, in denen der URL verfügbar ist (en, de). 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.
Hotti