Konzeption /Website-Aufbau

[elrt]

Guten Abend,

zurzeit mache ich mir Gedanken über die bisherige Struktur meiner Websites.

Bis jetzt hatte ich immer meine Klasse Menü.
Diese Klasse hat die Navigation generiert und je nach Klick eine gewisse
Unterseite(subpfad) ausgewählt.

Diese Unterseite habe ich dann in meinem index-Skript über die public Variable Menü->subpfad aufgerufen.

Da ich meine Websites auf ein neues Level bringen will, bin ich mir
nicht mehr sicher, ob dieser Ansatz elegant ist.

Ich habe im Internet einiges gesucht, aber solche Dinge sind schwer
zu finden ...
Habt ihr generell Links , wo nicht nur PHP beigebracht wird,sondern eher
der Aufbau und die Verknüpfung von Klassen/Funktionen innerhalb einer Website?

Habt ihr irgendwelche Tips?

Danke
Gruß Robert

[nikosch]

Das ist verschieden. PHP stellt ja selbst auch schon eine Abstrahierung des Viewprozesses dar. Aber zumindest bestimmte Module wie Formulare machen sich gut mit MVC Umsetzung.

[elrt]

Hey nikosch,
danke für deine Tips...

werde jetzt so etwas wie eine Klasse Controlling entwerfen, die alles steuert.
Ich werde sie so allgemein wie möglich programmieren, dass ich sie auch für andere Projekte benutzen kann...

Da du ja gerade Controlling ansprichst... entwickelst du deine Seiten im MVC-Pattern ?


Gruß Robert

[nikosch]

Wie machst du das, wenn du eine interne Seite aufrufst ?
Benutzt du dann GET-Parameter oder etwas anderes?

Klar, GET, ganz normal. Die URL ist zumindest im Browser-Client-Kontext das normale Verfahren. Auch das (bzw. Deine Sorge) zeigt, dass das Menü damit nichts zu tun hat. Seiten, die man nur im Menü nicht findet basieren auf „security through obscurity“, was aber kein Ersatz für eine Zugriffskontrolle ist. Für diese wiederum ist genau genommen nicht die Art relevant, wie der Inhalt jetzt angefordert wird. Um es anders zu sagen: Wenn Du eine Nuss-Allergie hast, ist es nicht wichtig, ob Du die Nüsse aus der Dose isst, im Restaurant im Essen hast oder Deine Freundin Dir eine Nusspraline in den Mund steckt. Entscheidend ist, dass spätestens Dein Gaumen erkennen sollte, dass da Nuss drin ist.

Du hast also jetzt schon 3 Komponenten:

1) Das Menü bietet (wie im Restaurant) mögliche Ansprungpunkte für den Nutzer an. Es ist natürlich sinnvoll, aber nicht hinreichend, Adressen nicht verfügbarer Inhalte auszublenden. Genauso ist es unnötig, alle verfügbaren Seiten im Menü abbilden zu müssen.
2) Das Controlling bildet einen Menüpunkt, eine URL oder sonstige Eingaben (z.B. einen Defaultwert auf die Startseite) auf eine konkrete Seite ab.
3) Eine Zugriffskontrolle prüft auf der jeweiligen Seite, ob der Nutzer sie anfordern durfte und wenn nicht (Egal - Er hats gemacht) verhindert sie als letzte Instanz den Zugriff. So kann sie bspw. das Controlling auffordern, eine Fehlerseite anzufordern. Im Normalfall reicht für ein einfaches Zugriffssystem nur private Seiten zu prüfen.

Was hier beschrieben wird ist gerade in der OOP ein wichtiges Paradigma - jedes Objekt oder Modul hat seine Aufgabe. Damit bleibt klar, was durch wen passiert (fehl die Zugriffskontrolle dann kann der Nutzer definitiv die Seite sehen, wenn sie angefordert wird) und die Funktionalität bleibt austauschbar.

[ChrisB]

Bei GET-Parametern habe ich immer die Sorge, dass man durch Manipulation der URL eine interne Seite aufrufen kann...

Dafür validiert man solche Daten ja, anstatt sie ungeprüft für sowas zu verwenden.

[elrt]

Jop, da hast du in der Tat was angestoßen

Ich rätsel immer noch, wie man eine elegante Methode entwickelt, um
eben diese internen Seiten in GET-Parameter einbindet...


Wie machst du das, wenn du eine interne Seite aufrufst ?
Benutzt du dann GET-Parameter oder etwas anderes?
Bei GET-Parametern habe ich immer die Sorge, dass man durch Manipulation
der URL eine interne Seite aufrufen kann...



Gruß Robert

[nikosch]

Hihi, habe ich wohl was angestoßen. Mit nem Link kann ich nicht dienen, aber mit ein paar Hinweisen.

Wie schon im anderen Thread gesagt: Das Menü sagt erstmal nichts über möglichen ansteuerbaren Seiten (ich nenne das Controlling) aus. Im Prinzip sind auch GET-Parameter mit Pages denkbar, die in keinem Menü stehen, mehrere Menüs mit überschneidenden Seitenzielen etc. In CMS wird zwar oft die Struktur des Menüs an die Websitestruktur gebunden, das mag aus Gründen der Inhaltspflege auch sinnvoll sein, ich halte das jedoch für einen Fehler.

IMHO sollte das Controlling ein spezialisiertes Objekt sein, das austauschbar auf Grundlage von Parametern eine Eingabe auf einen Scriptpfad abbildet. Dabei
- kann die Liste der Abbildungen bspw. DB-verwaltet sein
- kann eine fehlende Angabe eine Fehlerseite liefern
- kann eine fehlende Angabe auf eine allgemeinere Angabe aufgelöst werden: Services/Haareschneiden/ bspw. auf Services/, wenn Haareschneiden mal nicht verfügbar ist
- kann eine Angabe auch eine Weiterleitung darstellen, die man dann nicht mehr über HTTP-Redirect veranstalten muss, sondern einfach als Include eines Ersatzinhalts
- sollte das Controlling „manuell“ auf eine bestimmte Seite setzbar sein. Auf spezialisierten Seiten wie Formularverarbeitung kannst Du damit bspw. andere Inhalte anfordern

Menüobjekte kannst Du mit dem aufgelöstem Pfad des Controllings „füttern“, um bspw. eine Anzeige der aktiven Seite zu erzeugen. Hier liegt allerdings auch der Knackpunkt: Wenn Du verschiedene Kontrollen für Menü- und Inhaltsstruktur verwendest, kann eine Menüstruktur potentiell auch von der echten Seitenstruktur abweichen:

example.com/Services/Haarschneiden

sagt so gesehen nur aus, dass der Menüpunkt - falls vorhanden - Haarschneiden aktiv ist. Ob das Menü überhaupt einen Überpunkt Services bietet, ist dann eine Frage der Menüstruktur.