Canni

HI.
Ich habe da mal ein Problem:
Ich habe ein Layout mit drei DIV-Containern. Einer für Navi, einer für Content und einer für Sonstiges. Die Dinger zu füllen ist ja kein Problem => include...
Jetzt will in der Navi per Link z.B. ein Gästebuch aufrufen, das im DIV-Container für Content angezeigt werden soll. Ich kriegs nicht hin . target='content' funktioniert nicht und ich würde ungern mit einem include in diesem Container und switches arbeiten.
Kann mir jemand einen Tip geben wie ich DIV-Container ( generell ) als Linkziel angeben kann?
Danke und Gruß

Mister Ad

Freeaak

das musst du schon mit switch machen. es sei denn du tust ein iframe in den content-container

__________________
"Wenn du nicht weißt, was du tust: Machs mit Eleganz!"

(Murphy's Gesetze)

XLB

Mit AJAX würd's wohl auch gehen ...

Canni

*grummel*
ich unterlag der Vorstellung, daß DIV-Container eine Erleichterung in Sachen Design darstellen sollen, aber bei dem was ihr hier so schreibt...
dann muß ich mich zwischen iFrames und switchen entscheiden. Kann mir eventuell noch jemand einen Rat geben was ( event. ) und warum vorzuziehen wäre? Ich tendiere ja leicht zum switchen, kann aber nicht wirklich sagen warum
. Danke.

Freeaak

der vorteil mit den switchen ist, dass du eindeutige urls hast. das ist nützlich zum direkten verlinken.

__________________
"Wenn du nicht weißt, was du tust: Machs mit Eleganz!"

(Murphy's Gesetze)

Basti

Hi.

Du kannst doch auch einfach die übergebenen Parameter (page=guestbook, ggf. entsprechend mit mod_rewrite umbiegen) auslesen und schauen, ob eine entsprechende Datei/Klasse/Modul existiert und dies/s dann einbinden. Wichtig dabei ist, dass du den Wertebereich genau prüfst, damit sich niemand z.B. deine Konfigurations-, Sitzungs- oder sonstigen Dateien einbinden kann.

Und ... "DIV-Container als Linkziel", "switch oder iFrame", ... du solltest dir nochmal ganz in Ruhe anschauen, was HTML ist, was PHP ist etc. PHP generiert einfach Ausgaben an den Browser. Ob das div-Container sind oder ein Bild von einem Schuhkarton, das liegt ausschließlich bei dir. Und ob du eine HTML-Tabelle für dein Layout misbrauchst oder einen div-Container nimmst hat doch mit der Anwendung, die den ganzen Mist fabriziert nichts zu tun.

Basti

Canni

Hi Basti.
Ich denke ich weiß halbwegs was HTML und PHP ist. Es ist auch wirklich egal was von was generiert wird. Was nicht egal ist was ( Daten zur Ansicht ) wie ( über Link oder ein include(switch/case) - nat. muß da auch irgendein Verweis drauf sein ) und woher ( z.B. Datenbank )wohin ( DIV, iFrame, Tabelle etc. ) kommt und wie dynamisch das Ganze sein soll und auch wie einfach oder kompliziert alles umstruckturiert werden kann. Und mit jedem neuen Link ( Navi ) brauche ich einen case mehr im PHP-Script um die Daten an der richtigen stelle ausgeben zu lassen.
Wenn man grad mal ein GB, eine Filmsammlung und eine Linksammlung zur Ansicht bringen will include ich das "Ausgabe"-Script mit den cases in dem DIV-Cont. und fertig ist der Lack.
Wenn ich aber ein größeres "Projekt" angehen möchte
( du hattest mir im PHP-Anfängerforum schon sehr nützliche Ansätze vermittelt - thx nochmal - z.B. zum Thema Benutzerverwaltung; das hier gehört zum gleichen "Projekt" )
muß ich mir schon mehr Gedanken über "Infrastruktur", das Wie, Woher, Wohin machen. Schon alleine wegen dem Überblick über das Projekt. Wenn ich mitten drin feststelle, das iFrames zwar an Anfang weniger Arbeit bedeutete und schnellere Ergebnisse brachte, ich später aber wenn um Sachen wir Administrierbarkeit und Skalierbarkeit der Inhalte geht vielleicht komplett umdenken und schreiben muß, ist das wirklich ärgerlich.
So, Schreiben bringt auch auf Ideen. Ich muß jetzt grad mal was ausprobieren .
Gruß
Canni

Basti

"switch oder iFrame" - beides ist doch absolut untauglich. Wie gesagt, lass das System selbst erkennen, was der Benutzer da will und ob eine entsprechende Komponente da ist, den Wunsch zu erfüllen.

Klar. Nur eben ist der Bezugspunkt "div-Container" einfach reichlich uninteressant. Wichtiger wäre zu fragen, ob verschiedene Komponenten ineinander geschachtelt werden sollen etc.

Vielleicht bringt dich hier was weiter:
http://java.sun.com/blueprints/patte...ositeView.html
http://c2.com/cgi/wiki?RecursiveModelViewController
http://www.javaworld.com/javaworld/j...21-hmvc_p.html

Wenn du deine Module derart in einen Baum hängst, dann hat eben jedes Modul verschiedene Möglichkeiten, wo welche Kinder eingehängt weden können und so kannst du die Requests so gestalten und durch die Controller durchreichen, bis irgendein Controller eben weiß, dass an einer bestimmten Stelle diese oder jene View ausgespuckt werden soll. Beziehungsweise wo diese Stelle dann genau ist, wird natürlich im Template oder, falls du z.B. nur mit Widgets arbeiten magst, eben in den entsprechenden View-Klassen.

Basti

Canni

äh... gibts das auch in PHP?

Basti

Klar, es gibt zig Frameworks, die das umsetzen in PHP umsetzen und auch viele Artikel darüber.

Aber das Prinzip ist immer ähnlich. Klar, im Web gibt es keine stehende Verbindung zum Benutzer und in PHP bleibt da die Anwendung zwischen den Requests nicht an laufen, weshalb man den Status eben in eine Session packen muss, wo nötig und die View-Objekte hier nichtmehr die Model-Objekte beobachten, sondern von den Controllern über Änderungen informiert werden (MVC2).

Ein Request wird vom ersten Controller angenommen und der schaut halt, ob er ihn bearbeiten kann, oder ob er ein Modul einbinden kann, der ihn bearbeiten kann (ggf. wird der Status auch aus der Session wieder hergestellt und ein Modul kennt bereits seine Kinder und weiß, wem der Request gilt). Anhand der Anfrage führt der Controller, dem sie gilt ggf. die nötigen Änderungen am Modell durch und entscheidet, welche Sicht angezeigt wird (oder gibt vielleicht auch ein Signal an seinenen Papa zurück, z.B. dass der Benutzer keine Rechte hat, die angefragte Aktion auszuführen oder einen Redirect etc.). Wo diese Sicht dann eingebunden wird weiß eben wieder Papa.

Eventuel kann man einem View-Objekt noch einen Kontext-Wert mitgeben, so dass eben eine Sicht "die letzten 10 Beiträge des Forums" anders dargestellt wird, wenn sie in der Marginalspalte der Startseite als kleine Infobox erscheint oder eben als Ergebnis einer Forenuche als Haupt-Content. Ich meine, in ezPublish ist sowas umgesetzt.

Aber ansonsten weiß die Komponente nichts davon, wo sie dann erscheinen soll, nur eben wie.

Und wenn es auch garkeine anderen Bereiche auf einer Seite gibt, auf die sich Änderungen durch einen Request primär beziehen, als eben quasi der "Hauptframe" (div *g), dann brauchst du den ganzen Krempel ja eh nicht zu berücksichtigen. Die Navigation baut sich selber zusammen in Abhängigkeit davon, was als Hauptinhalt angezeigt wird. In Frames gesprochen: Wenn eh alle Links auf das Hauptfenster zielen und es höchstens JS-Aufrufe gäbe, um die Navigation auf den neuen Inhalt einzustellen, dann kannst du (ohne Frames) die target-Angabe ja auch gleich vergessen.

Basti