| von subjective |
Ich meist auch nicht. Verdiene mein Geld ja auch damit ein CMS zu bauen. Die index.php hat dort 9 Zeilen, während der eigentliche Quellcode in einem Klassenframework liegt. Bei einem DB-basierten System ist die Aufteilung des Quellcodes ja nur noch von der Wiederverwendbarkeit und den Erweiterungsmöglichkeiten abhängig.
Allerdings habe ich dort ein ähnliches Konzept - nur halt auf Datenbankebene. Ich habe eine Hierarchie von "Seiten", bei welchen gespeichert wird, welches Template sie nutzen und welche Zusatzinhalte (Navigationen, Banner, ...) dazugehören.
|
| von Philipp Gérard |
subjective schrieb am 08.11.2004 11:08
Eine zentrale Indexdatei macht erst Sinn, wenn man die Inhalte nicht mehr im Dateisystem liegen hat. |
Sorry - dann habe ich vom falschen Thema geredet. Ich denke nicht mehr in Flat-file-Anwendungen |
| von subjective |
Bei mod_rewrite benötigst du eine Regel wie du die URLs umschreibst. Egal wie wenig Aufwand die Definition der Regeln für mod_rewrite darstellt - man muss es erst einmal können. Viele Leute fürchten RegEx und selbst Leute die sie kennen, kann der Apache 1.3 ziemlich Nerven kosten, bis man die Einschränkungen kennt (kein \d, max. 9 Backrefrences, ...). Die Regeln können sehr komplex werden - vor allem wenn man nicht die komplette Kontrolle über den Pfad übernehmen will. Zusätzlich kannst du für Links, welche du schreibst nicht mehr die $_SERVER Variablen verwenden. Außerdem gibt es auch noch Webserver ohne mod_rewrite.
Automatisch HTML-Dateien zu schreiben, ist meist nicht möglich, da heutige Seiten fast immer dynamische Elemente haben - man müßte also PHP-Dateien schreiben (Ich weiß das dies bei einigen CMS so läuft, aber wir redern hier ja von einfachen dateibasierten Konzepten).
Google indiziert zwar alles was es bekommen kann, jedoch werden auch die Pfade/Dateinamen in die Wertung mit einbezogen.
Layout das sich den Inhalt holt, ist nicht professionell, da es dem Konzept der Trennung von Layout und Anwendungslogik entgegensteht. Mit einer zentralen Indexdatei ignoriert man die Fähigkeiten des Dateisystem zur Strukturierung der Inhalte. Man kodiert dann diese Struktur einmal in der index.php und zusätzlich legt man noch mal einzelne Dateien mit den Inhalten ab - doppelte Information. Man umgeht die Funktionen des Webservers und muss z.B. 404-Fehlerbehandlungen selbst implementieren.
Man verliert außerdem Flexiblität. Wenn nämlich die einzelne Datei das Layout bestimmt, das sie sich holt, kann sie sich auch ein anderes holen. Sie kann eine völlig andere Logik implementieren ohne die anderen Seiten zu beeinflussen (globale Variablen).
Eine zentrale Indexdatei macht erst Sinn, wenn man die Inhalte nicht mehr im Dateisystem liegen hat. |
| von Philipp Gérard |
a) für schöne URIs ist mod_rewrite da.
b) wer das nicht hat lässt automatisch HTML-Dateien schreiben.
c) wer das nicht kann lernts (schleunigst).
d) Google mag fast alle URIs, der Inhalt zählt.
e) Alle anderen mögen nur richtig schöne URIs wie abc/def/seitenname.html
Ob man über eine index.php und zig. Templates die Inhalte verteilt, oder man lieber alles mehrfach macht sei dem Programmierer überlassen. Am schnellsten Programmiert ist die Variante mit weniger Quellcode, ergo die einzige Datei. |
| von Can |
| Wo bitte ist da großer Aufwand um "schöne" URLs hinzubekommen. Allein schon mit der Billig-Methode ModRewrite kann man das doch schon ganz gut lösen. Aber ich find die Inhaltsseiten vom Layout includen zu lassen viel professioneller, und flexibler ist das ganze auch noch!?? |
| von subjective |
Abgesehen spielen ja nicht nur Suchmaschinen eine Rolle - auch für Surfer sind lesbare Links ohne Parameter schöner - man erinnert sich eher daran, man kann sie einfacher abtippen, ...
Außerdem ist es eigentlich sogar weniger Arbeit wenn man mit einzelnen Dateien nutzt, welche sich den Inhalt holen. Jede Datei kann dann definieren, welches Layout sie aus der zentralen Datei holt, welche Zusatzinhalte, etc - man kann also in der Datei Informationen definieren, welche sonst zusätzliche Parameter benötigen würden und über Verzeichnisse kann man die Informationen auch noch gruppieren.
Datenbankgestützte Sachen wie Blog- oder CMS-Systeme treiben teilweise einen ziemlichen hohen Aufwand um wieder "schöne" URLs hinzubekommen. |
| von a-man |
habs jetzt ueberprueft...
google kennt die parameter, der rest nicht...
edit: kann man so nicht sagen, ich hab (kurz) yahoo und fireball getestet...
jetzt weiß ich wenigstens, was ich als naechstes bei meiner seite umstellen muss...
(thx) |
| von DukeXP |
a-man schrieb am 06.11.2004 18:45
@suchmaschinen kennen mitlerweile nicht schon die meisten solche parameter? (ich kenn mich da nicht aus...) |
Aus Sicht einer Suchmaschine handelt es sich dabei um eine einzige Seite. Da der Inhalt ständig variert wird sie über kurz oder lang aus dem Index verbannt oder erst gar nicht aufgenommen.
|
| von a-man |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14: |
switch($site) {
case 'start':
include('start.php');
break;
case 'news':
include('news.php');
break;
...
default:
include('404.php');
break;
}
|
sowas in der art...
du verwendest wahrscheinlich sowas:
@subjective
kannst du mir bitte erklaeren, warum dir das nicht so gefaellt/warum man da leicht fehler einbaut (mein 1. beispiel) ?
@suchmaschinen kennen mitlerweile nicht schon die meisten solche parameter? (ich kenn mich da nicht aus...) |
| von subjective |
Du läßt das Layout (index.php) den Inhalt holen. Mach es genau umgedreht - laß die einzelnen Inhaltsdateien sich das Layout holen.
Du hast ehh schon einzelne Dateien mit den Inhalten - einfach jeweils oben und unten ein Aufruf für header+footer - fertig. |
| von HoRnominatoR |
| was fuer ein bspl? du musst einfach nur mit file_exists() ueberpruefen, ob die datei auch exisitert. wenn jemand http :// oder aehnliches angibt, kann er auch externe dateien includen, optimal um den webspace zu loeschen, irgendwelche daten draufzuspielen, spammails zu versenden etc., oder halt einfach einzelne dateien benutzen und mit dateiunabhaengigen werten arbeiten. |
| von dee123 |
Na du bist gut...
Ic hab das komplette Layout fertig. Der "Rahmen" der Page ist die index.php, die alle anderen Dateien includet. Ist doch übersichtlich und elegant. Fehler kin der Programmierung sind sofort erkennbar, da nur das einzelne Modul meckert, nicht die ganze page.
Ich bin aber trotzdem noch nicht weiter mit meinem Problem.
Kannste mir nicht mal ein Beispiel in PHP zeigen??
Danke |
| von subjective |
Kein "Hammer" sondern logisch und richtig. PHP arbeitet auf Ebenene des Dateisystems - der Passwortschutz ist ein Feature des Apache.
Damit läßt sich dann zB über ein PHP-Script prüfen, ob ein angemeldeter User eine Datei bekommen darf. Man wrappt den Zugriff auf eine über den Webserver nicht erreichbare/oder gesperrte Datei durch ein PHP-Script.
Du beschreibst ein typisches Problem einer unsauberen Programmierung deinerseits. Der Fehler ist, das du die GET-Parameter nicht prüfst.
Ich bin persönlich kein Freund davon statt Dateinamen GET-Parameter zu verwenden und alle Aufrufe über eine zentrale "index.php" zu wrappen. Man handelt sich Sicherheitslücken ein, macht sich zusätzliche Arbeit und bekommt häßliche URLs mit schlechterer Wertung in den Suchmaschinen.
Warum läßt du nicht die einzelnen Dateien mit den Daten, sich aus einer zentralen Datei, das Layout holen. Damit benötigst du keine GET-Parameter mehr und bist flexibler. |
| von dee123 |
Hallo,
ich hab in einem geschützen Verzeichnis "mail" eine Datei namens mail.php liegen, mit der ich einen Newsletter an alle reg. User versende. Das Verzeichnis ist mit .htaccess und .htpasswd geschützt.
Jetzt kommt der Hammer:
Wenn ich die Datei folgendermaßen im Browser aufrufe, läuft sie einfach - ohne Passwortabfrage, wie man es von .htaccess gewohnt ist:
http://www.meineDom.de/index.php?site=mail/mail.php
mit dem Aufruf: http://www.meineDom.de/mail/mail.php kommt die normale Benutzer- und PW Abfrage.
wie kann das denn passieren ? wer kann mir helfen, daß beim o.g. Aufruf zuerst die Benutzer- un Passwd Abfrage kommt, bevor die Datei sich öffnet ?
---
Meine alte Signatur gefiel mir nicht mehr. Darum hab ich jetzt eine neue. |
