Anzeige der URL weitgehend unterdrücken?

[suicide]

Hi

Zur Zeit bestehen meine Navigationen immer aus einer index-seite in welche einen bestimmter inhalt  bei einem bestimmten index anzeigt (mit einem switch($index)). Bei "case 1:" wird dann z.B. die home.php included.

Ich linke sozusagen immer wieder auf die index.php mit einem anderen $index-Wert. Gibt es eine Möglichkeit die Anzeige der URL nach der stammseite zu unterdrücken?
Sprich: der user ist auf "http://www.root.com" aber er befindet sich tatsächlich auf "http://www.root.com?index=2"

Wie steht es mit alternativer Navigation? (ich möchte hier jetzt nichts von frames hören)

Danke
sui

[Cheatah]

Hi,

Sprich: der user ist auf "http://www.root.com" aber er befindet sich tatsächlich auf "http://www.root.com?index=2"

entweder stellst Du sämtliche Links usw. auf POST-Formulare um, oder Du verwendest ein Frameset. Aber warum um alles in der Welt willst Du mit evtl. erheblichem Aufwand die Qualität Deiner Site derartig verringern?

Wie steht es mit alternativer Navigation? (ich möchte hier jetzt nichts von frames hören)

Gut, Frames sind nämlich in aller Regel schlecht[tm] :-)

Du kannst Dich ein wenig mit Serverkonfiguration (z.B. Apache: mod_rewrite) beschäftigen. Es ist möglich, auch bei der URL "http://www.root.com/irgendein/pfad/zur/datei.html" Deine /home.html [1] zu verwenden. Was dann eigentlich angefordert wurde, findest Du im Environment (phpinfo(), Zugriff über getenv()).

Cheatah

[1] Es ergibt keinen Sinn, HTML-Ressourcen anders als auf ".html" oder ggf. ".htm" enden zu lassen. Für den User ist es extrem uninteressant, ob jemals PHP involviert war.

[Michael Schröpl]

Hi Cheatah,

[1] Es ergibt keinen Sinn, HTML-Ressourcen anders
als auf ".html" oder ggf. ".htm" enden zu lassen.
Für den User ist es extrem uninteressant, ob jemals
PHP involviert war.

Du hattest das schon mal gepostet.

Deshalb jetzt meine Frage darauf:

Angenommen, Du hast eine Site mit vielen hundert
Dokumenten. Diese haben eine ganze Reihe verschiedener
Endungen, aber die meisten von ihnen erzeugen HTML.

Die diversen Endungen sind allerdings notwendig (denke
ich), weil die Dokumente von ganz unterschiedlichen
Handlern verarbeitet werden. Eine Endung ist sogar
zwingend vorgegeben, weil ein Handler (ein Fremdpro-
dukt) sich weigert, Dokumente mir anderen als ihm be-
kannten Endungen zu verarbeiten.
Und innerhalb beliebiger von fast 100 Verzeichnissen
(ein schöner, tiefer, strukturierter Baum) befinden
sich wild durcheinander Dokumente aller möglichen
Typen und Endungen - weil diese Dokumente nicht nach
ihrem Typ, sondern nach ihrer inhaltlichen Zusammen-
gehörigkeit geordnet sind. So ähnlich wie der Baum von
SelfHTML8 eben.
(Aus dem Ablageort einer CSS-Datei kann man z. B.
schließen, auf welche Menge von Dokumenten ihr Inhalt
Auswirkungen haben darf - mit diesem Wissen läßt sich
der Inhalt solcher Dateien sehr schön einfach warten.)

Wie bekomme ich nun für eine solche Site Dein Ideal
der einheitlichen Endung *.html?
Ich sehe nicht, wie ich die jeweils richtige Endung
erraten könnte (sie dann mit mod_rewrite entsprechend
abzubilden, das wäre das kleinere Problem).

Die einzige Lösung, die ich sehen würde, wäre eine
Rewrite-Konfiguration, welche _jede_ einzelne Datei
der gesamten Domain individuell umschreibt.
Das sind aber wie gesagt viele hundert Dateien - und
es arbeiten mehrere Leute an diesem Baum, die ständig
neue Dateien erzeugen, aber alle keine Apache- Konfi-
guration und keine Rewrite-Rules beherrschen.
Und es wäre auch untragbar, wenn diese Leute jeweils
an derselben Apache-Konfigurationsdatei herum pfuschen
würden. '.htaccess' wiederum scheidet aus anderen
Gründen aus (u. a. Performance).

Wie würdest Du in einer solchen Situation einheitliche
Endungen hinkriegen?
Denn die Ästhetik Deiner Idee sehe ich ja durchaus ein
... aber die praktische Umsetzbarkeit in einem realen
Umfeld sehe ich irgendwie nicht ...

Viele Grüße
      Michael

[Cheatah]

Hi,

Du hattest das schon mal gepostet.

immer wieder gern ;-)

Die diversen Endungen sind allerdings notwendig (denke
ich), weil die Dokumente von ganz unterschiedlichen
Handlern verarbeitet werden.

Darauf gibt es zwei mögliche Antworten:

1.) Nein.
2.) Ja - aber das tut nichts zur Sache. Wie Du die _Datei_ nennst ist für die URL völlig unerheblich. _Dort_ hat ".html" zu stehen; und zwar auch dann, wenn serverlokal eine Datei namens (z.B.) "bla.html.php" steht.

Die richtige Datei und/oder den richtigen Handler (bzgl. Antwort 1) auszuwählen ist eine Sache der Serverkonfiguration.

Und innerhalb beliebiger von fast 100 Verzeichnissen
(ein schöner, tiefer, strukturierter Baum) befinden
sich wild durcheinander Dokumente aller möglichen
Typen und Endungen - weil diese Dokumente nicht nach
ihrem Typ, sondern nach ihrer inhaltlichen Zusammen-
gehörigkeit geordnet sind. So ähnlich wie der Baum von
SelfHTML8 eben.

Hm. Ich weiß nicht genau, ob ich mir das ganze jetzt richtig vorstelle; im Grunde ist das Problem der "index.php" und "main.shtml" meistens auf Faulheit[1] bei der Konfiguration zurückzuführen - Kenntnis der Problematik vorausgesetzt. Und jeder, der dies oder meine vorherige Antwort gelesen hat, _hat_ jetzt diese Kenntnis ;-)

[1] Das betrifft auch die Faulheit, entsprechende Dinge (nicht) erlernen zu wollen :-)

(Aus dem Ablageort einer CSS-Datei kann man z. B.

[...]

Wie bekomme ich nun für eine solche Site Dein Ideal
der einheitlichen Endung *.html?

Für CSS-Ressourcen sollte die Endung nicht wirklich ".html" lauten :-) Ich hoffe aber, mein Beispiel oben in Antwort 2 gibt genügend Hinweise auf eine praktische Umsetzungsmöglichkeit.

Ich sehe nicht, wie ich die jeweils richtige Endung
erraten könnte (sie dann mit mod_rewrite entsprechend
abzubilden, das wäre das kleinere Problem).

Auch in mod_rewrite kannst Du Filetests durchführen.

Die einzige Lösung, die ich sehen würde, wäre eine
Rewrite-Konfiguration, welche _jede_ einzelne Datei
der gesamten Domain individuell umschreibt.

Oder eine strenge Nomenklatur, wenn Du diesen Weg gehen möchtest. Das ist meistens einfacher, aber nicht immer nötig oder sinnvoll.

Und es wäre auch untragbar, wenn diese Leute jeweils
an derselben Apache-Konfigurationsdatei herum pfuschen
würden. '.htaccess' wiederum scheidet aus anderen
Gründen aus (u. a. Performance).

Nein, sicher nicht :-) Allerdings ist sowas ein klassischer Fall für ein gutes, individuell zugeschnittenes CMS.

Cheatah

[Michael Schröpl]

Hi Cheatah,

2.) Ja - aber das tut nichts zur Sache.
Wie Du die _Datei_ nennst ist für die URL völlig
unerheblich. _Dort_ hat ".html" zu stehen; und
zwar auch dann, wenn serverlokal eine Datei
namens (z.B.) "bla.html.php" steht.

Okay - also Negotiation. Muß ich mir an dieser Stelle noch mal genauer ansehen. Ich fürchte aber, selbst das wird nicht funktionieren, weil der Handler mit PATH_TRANSLATED arbeitet und furchtbar picky ist, wenn nicht alles nach seiner Nase geht.

[1] Das betrifft auch die Faulheit, entsprechende
Dinge (nicht) erlernen zu wollen :-)

So schlimm schätzt Du micht ein? Aua, aua ...

Auch in mod_rewrite kannst Du Filetests durchführen.

Hm - also das swiss army knife mit einbinden.
Alleine dadurch wächst mein Apache um knapp 50% ...

Nein, sicher nicht :-) Allerdings ist sowas ein
klassischer Fall für ein gutes, individuell
zugeschnittenes CMS.

Wobei der "Content" meiner Seiten allerdings wiederum Programme sind, in der proprietären Programmiersprache dieses Handlers ... und diese Programme laufen vorher durch einen "Präcompiler" (ein Perl-Skript von mir), welcher alles heraus nimmt, was Kommentar oder Lesbarkeits-Formatierung angeht (das kann der Handler nämlich nicht) - dies allerdings nicht on the fly, sondern statisch auf der Maschine.
Da müßte das CMS eine ganze Menge können. Und so etwas zu schreiben, kriege ich nicht genehmigt ...

Viele Grüße
      Michael

[Cheatah]

Hi,

Okay - also Negotiation.

jupp.

Ich fürchte aber, selbst das wird nicht funktionieren, weil der Handler mit PATH_TRANSLATED arbeitet und furchtbar picky ist, wenn nicht alles nach seiner Nase geht.

Wenn ich Deine Einwände hier so lese, komme ich zu dem Schluss, dass Du ziemlich schlecht programmierte Software zu benutzen hast... was natürlich immer ein Problem ist. Kann sein, dass es in Deinem Fall also "geht halt nicht anders" heißen muss. Wenn das nächste Mal über die zu verwendende Software geredet wird, kann/sollte man das beachten... denn im Grunde müssen solche Sachen in die Planungsphase mit einbezogen werden.

[1] Das betrifft auch die Faulheit, entsprechende
Dinge (nicht) erlernen zu wollen :-)

So schlimm schätzt Du micht ein? Aua, aua ...

Nein, ich habe meine Antwort allgemein gemeint, und nicht auf Deinen Spezialfall bezogen. Sorry, wenn ich das missverständlich ausgedrückt habe.

Auch in mod_rewrite kannst Du Filetests durchführen.
Hm - also das swiss army knife mit einbinden.

Ist nur _eine_ Idee. Apache bietet viele andere Möglichkeiten - Content Negotiation beispielsweise auch. Und wer es _ganz_ individuell haben möchte, der baut sich halt sein eigenes Servermodul.

Nein, sicher nicht :-) Allerdings ist sowas ein
klassischer Fall für ein gutes, individuell
zugeschnittenes CMS.

Wobei der "Content" meiner Seiten allerdings wiederum Programme sind, in der proprietären Programmiersprache dieses Handlers ...

Darum ja auch "individuell zugeschnitten". Es gibt nichts, was man nicht über ein spezielles CMS einstellen könnte. Ja, das kostet allerdings nicht unerheblichen Aufwand :-)

Cheatah

[Michael Schröpl]

Hi Cheatah,

Ich fürchte aber, selbst das wird nicht
funktionieren, weil der Handler mit
PATH_TRANSLATED arbeitet und furchtbar picky
ist, wenn nicht alles nach seiner Nase geht.
Wenn ich Deine Einwände hier so lese, komme ich
zu dem Schluss, dass Du ziemlich schlecht
programmierte Software zu benutzen hast...

Der Kandidat hat hundert Punkte und eine aufblasbare Waschmaschine.

Wenn das nächste Mal über die zu verwendende
Software geredet wird, kann/sollte man das
beachten...

Tja, mit natürlichen Zahlen wirst Du diesem Problem leider nicht gerecht.

denn im Grunde müssen solche Sachen in die
Planungsphase mit einbezogen werden.

Schönes Wort, das ... aber ... hm ...

Apache bietet viele andere Möglichkeiten -
Content Negotiation beispielsweise auch.

Die gefällt mir von allen beschriebenen am besten (auch wenn ich natürlich im Moment nicht mal mod_negotiation mit eincompiliert habe, mein Apache ist doch eher "mager").
Ich denke, meine proprietären Endungen durch eine negotiation mit genau einer Alternative zu verstecken, wäre machbar.

Ich sehe allerdings in meinem Einsatzfall wirklich nicht den Vorteil - weil es eben kein WWW-Produkt ist und keine stabilen URLs benötigt. Die Benutzer haben keine Bookmarks - sie könnten damit überhaupt nichts anfangen. (Es steckt viel zuviel in der Frameset-Architektur der Anwendung drin, was alleine gar nicht funktionieren würde.)
Würde ich bei einem WWW-Portal arbeiten, dann ginge ich mit Deiner Argumentation konform - so jedoch würde es mich in erster Linie Performance kosten, ohne daß ich dabei irgendwas gewinne.

Und wer es _ganz_ individuell haben möchte, der
baut sich halt sein eigenes Servermodul.

"Dürfen" heißt das Zauberwort. "Mögen" würde ich schon ... das besagte CGI-Skript würde als Apache-Modul viel eleganter arbeiten, aber sein Autor weigert sich, den Apache als Voraussetzung zu akzeptieren ...

Viele Grüße
      Michael

[furchtbar]

Moin,

Wie bekomme ich nun für eine solche [tief verschachtelte]
Site Dein Ideal der einheitlichen Endung *.html?

Das ist genauso schlecht wie jede andere arbiträre Endung (php, shtml, cgi und was es nicht alles gibt). TimBL sagt, man soll die eingesetzte Technologie nicht im URI offenlegen. Stellt euch vor, ihr erzeugt etwas dynamisch mit Perl, also habt ihr höchstwahrscheinlich einen URI, der /cgi-bin/ enthält. Wenn die Technologie geändert wird (im schnelllebigen Web passiert das sehr oft), dann geht der URI kaputt - eine mittlere Katastrophe. Dito mit Dokumentendungen. Firma stellt von asp auf php um (oder umgekehrt), plumps rutscht sie im Googleranking nach unten - alle URI kaputt.

Braust auf w3.org umher, keines der HT-Dokumente oder Inlinebildern hat Endungen. Bei den dynamischen Seiten (den Validatoren!) ist nicht zu sehen, ob das nu Perl oder Python oder C via CGI ist oder eine präprozessierte Skriptingsprache. So muss das sein. Die URI werden noch in Jahrzehnten valide sein. :)

Ich sehe nicht, wie ich die jeweils richtige Endung
erraten könnte (sie dann mit mod_rewrite entsprechend
abzubilden, das wäre das kleinere Problem).

Das brauchst du nicht. Einfach mod_negotiation einkompilieren (ist defaultmäßig sowieso an). Zur Performancesteigerung evtl. die Direktive CacheNegotiatedDocs aufnehmen. Mehr ist nicht zu tun.

Die Dokumente verlinken jetzt lediglich auf Basisnamen. Beispiele:
<a href=foo> findet foo.php
<img src=bar> findet bar.png
<iframe src=quux> findet quux.html
@import "../style"; findet ../style.css

Der Clou: du kannst die Bilder als svg, png und gif gleichzeitig anbieten, Apache serviert dem User Agent automatisch das passende, je nachdem, was der UA sagt, was er verkraften könne.

Mehr Tipps zum Thema, wie man einen Webserver mit Verstand betreibt: http://www.w3.org/Provider/Style/

[Michael Schröpl]

Hi,

Site Dein Ideal der einheitlichen Endung *.html?
TimBL sagt, man soll die eingesetzte Technologie
nicht im URI offenlegen.

wenn die eingesetzte "Technologie" von mir wäre, würde
ich es ja auch nicht tun ...

Stellt euch vor, ihr erzeugt etwas dynamisch mit
Perl, also habt ihr höchstwahrscheinlich einen URI,
der /cgi-bin/ enthält. Wenn die Technologie geändert
wird (im schnelllebigen Web passiert das sehr oft),
dann geht der URI kaputt - eine mittlere
Katastrophe.

Das umgehe ich ja schon dadurch, daß ich via "Action"
meine CGI-Skripts an die Endungen binde. Wenn sich da
der Interpreter ändert, geht kein URI kaputt.

plumps rutscht sie im Googleranking nach unten -
alle URI kaputt.

Berechtigter Einwand, trifft auf uns aber nicht zu.
(Google darf unsere Seiten sowieso nicht sehen, und
könnte mit den volldynamischen Inhalten auch kaum
etwas anfangen.)

Braust auf w3.org umher, keines der HT-Dokumente
oder Inlinebildern hat Endungen.
Bei den dynamischen Seiten (den Validatoren!) ist
nicht zu sehen, ob das nu Perl oder Python oder C
via CGI ist oder eine präprozessierte
Skriptingsprache. So muss das sein. Die URI werden
noch in Jahrzehnten valide sein. :)

Schön, ja.

Ich sehe nicht, wie ich die jeweils richtige
Endung erraten könnte (sie dann mit mod_rewrite
entsprechend abzubilden, das wäre das kleinere
Problem).
Das brauchst du nicht. Einfach mod_negotiation
einkompilieren (ist defaultmäßig sowieso an).
Zur Performancesteigerung evtl. die Direktive
CacheNegotiatedDocs aufnehmen. Mehr ist nicht zu
tun.

Doch. Nämlich alle Anwendungen wegwerfen und neu
schreiben. Was nicht geht, weil die Anwendungen
nicht von uns sind. I lose.

Die Dokumente verlinken jetzt lediglich auf
Basisnamen.

Geht nicht. Die Anwendung generiert ihre Links selbst.
Ich habe keinerlei Einfluß darauf. I lose.

Der Clou: du kannst die Bilder als svg, png und gif
gleichzeitig anbieten, Apache serviert dem User
Agent automatisch das passende, je nachdem, was der
UA sagt, was er verkraften könne.

Schau Dir mal an, wer hier den Feature-Artikel über
Content Negotiation geschrieben hat.
_Das_ ist nicht mein Problem ...

Mehr Tipps zum Thema, wie man einen Webserver mit
Verstand betreibt: http://www.w3.org/Provider/Style/

Vielen Dank für die Blumen ... ;-)

Viele Grüße
      Michael

[Cheatah]

Hi,

wenn die eingesetzte "Technologie" von mir wäre, würde
ich es ja auch nicht tun ...

die _Entscheidung_, welche Technologie verwendet wurde, stammt doch von Dir, oder? ;-)

Das umgehe ich ja schon dadurch, daß ich via "Action"
meine CGI-Skripts an die Endungen binde. Wenn sich da
der Interpreter ändert, geht kein URI kaputt.

Auch wenn sich die Schnittstelle ändert - von CGI zu PHP beispielsweise?

Cheatah

[Michael Schröpl]

Hi Cheatah,

wenn die eingesetzte "Technologie" von mir wäre,
würde ich es ja auch nicht tun ...
die _Entscheidung_, welche Technologie verwendet
wurde, stammt doch von Dir, oder? ;-)

Die Einscheidung, das besagte "störrische" CGI-Skript einzusetzen, stammt nicht von mir, nein.
Es gibt allerdings keinerlei denkbare Alternative (die weniger als 5 Mannjahre kosten und von der Geschäftsleitung genehmigt werden würde).
Das Skript ist wesentlich unverzichtbarer als beispielsweise der verwendete Webserver - _den_ dürfte ich notfalls wechseln (den Teufel werde ich tun ... ;-).

Das umgehe ich ja schon dadurch, daß ich via
"Action" meine CGI-Skripts an die Endungen
binde. Wenn sich da der Interpreter ändert,
geht kein URI kaputt.
Auch wenn sich die Schnittstelle ändert - von CGI
zu PHP beispielsweise?

Ich habe keine Ahnung, wie PHP funktioniert - aber was, was ich davon bisher gesehen habe, scheint so zu funktionieren, daß PHP an MIME-Typen gebunden wird.
Und MIME-Typen wiederum kann ich mit AddType an Endungen binden - reicht das nicht?

Ich sehe aber auch keine "Gefahr", jemals eine so offene Technologie wie PHP zu bekommen. Dazu ist das verwendete Produkt viel zu radikal closed source.

Viele Grüße
      Michael