Wie löse ich folgende Aufgabenstellung

[Christian999]

Hallo
Da ich schon etwas länger weg vom Thema bin und nun wieder in HTML einsteigen möchte hätte ich als Frage, wie meine Aufgabenstellung heutzutage "normalerweise" umgesetzt wird.

Als Referenzseite nehme ich mal expedia.de her.

Ich möchte, wie dort auch bestimmte Bereiche (Logo oben, Navigation, untere "Copyright" LEiste sowie rechts die "aktuellen Angebote" gleich lassen, sprich, nicht auf jeder unterseite neu laden.
Ändern soll sich natürlich der "Hauptbereich", in dem jeweils die Inhalte des jeweiligen Menüpunkts angezeigt werden...

Anno dazumal waren hierfür Frames der Klassiker, aber ich denke, diese Technik ist eher "out".
Kann ich sowas auch mit Layern lösen?
Hier entzieht sich mir aber die Vorstellungskraft, denn wenn ich im Menü auf einen Link klicke, kann ich meinem Verständnis nach, wenn ich nur mit Layern arbeite, Layer aus und einblenden...
Das Problem hierbei ist, ich kann ja nicht alle Inhalte auf eine html Seite packen...
Navigiere ich in einem Menü ohne Frames, dann wird doch automatisch die komplette Seite neu geladen, oder ?

Für Denkanstösse und Tipps wäre ich sehr dankbar...

lG
Christian

[diso]

div-conntainer!nicht layer.soewtas gibt es nicht.

in deinem fall kommen mehrere Lösungen in betracht.

einen Iframe einbinden wäre wohl für dich die einfachste.

das ein- und ausblenden schaffst du mit javascript.mittlerweile haben sich auch tolle frameworks (wie jQuery) entwickelt, mit denen nur wenig codeaufwand nötig ist um solche effekte zu erziehlen.

viele grüße

[Gunnar Bittersmann]

@@diso:

einen Iframe einbinden wäre wohl für dich die einfachste.

Um dieselben Nachteile wie bei Frames zu haben?

das ein- und ausblenden schaffst du mit javascript.mittlerweile haben sich auch tolle frameworks (wie jQuery) entwickelt, mit denen nur wenig codeaufwand nötig ist um solche effekte zu erziehlen.

Auch bei AJAX-Lösungen: Die Inhalte sind nicht über einen ihnen eigenen URI aufrufbar.* Schlecht.

Live long and prosper,
Gunnar

* Es sei denn, man ändert beim Austauschen von Inhalten auch den URI (fragment identifier, query).

[diso]

@gunnar: zu beiden posts, er suchte nach einem Lösungsweg um keinen reload der seite zu haben.diese habe ich ihm aufgezeigt.

ob diese in irgendw hinsichten (seo, w3c-spezifikationen) die besten lösungen sind, sagte ich nicht.

[suit]

ob diese in irgendw hinsichten (seo, w3c-spezifikationen) die besten lösungen sind, sagte ich nicht.

hier hast du ein glas wohlschmeckendes gesöff - dass es in der tat 20% alkohol enthält sag ich dir nicht, wenn du dann stockbesoffen in der ecke liegst, mach nicht mich dafür verantwortlich sondern die alkopop-hersteller

[diso]

bitte?

ich verstehe nicht worauf du hinaus möchtest.

[suit]

ich verstehe nicht worauf du hinaus möchtest.

wenn du jemandem eine lösung vorsetzt, speib' sie nicht einfach raus sondern erkläre auch warum du diese lösung wählst: vor UND nachteile

wir sind keine autoverkäufer, die die eigene lösung als beste verkaufen wollen sondern möchten lösungsvorschläge anbieten, die fragesteller mit gesundem menschenverstand selbst abwägen kann um dann aus ihnen zu wählen - zumindest sehe ich das so

ich hab kein problem jemandem eine schlechte lösung vorzuschlagen, nur sag ich das dazu (auch mehrfach, wenn ich denke der fragesteller kann die konsequenzen nicht abschätzen kann)

natürlich muss man ab und an leute "anrennen" lassen - aber sie ins verderben rennen lassen halte ich für fahrlässig

[Christian999]

div-conntainer!nicht layer.soewtas gibt es nicht.

in deinem fall kommen mehrere Lösungen in betracht.

einen Iframe einbinden wäre wohl für dich die einfachste.

das ein- und ausblenden schaffst du mit javascript.mittlerweile haben sich auch tolle frameworks (wie jQuery) entwickelt, mit denen nur wenig codeaufwand nötig ist um solche effekte zu erziehlen.

viele grüße

D.h. es laden sich nicht alle Bereiche neu, und ich springe trotzdem auf eine eigenständig andere html Seite ?

Sprich, jeder Menüpunkt hat seine eigene html seite ?

If so, wäre das meine Lösung, thx ;)

lG
Christian

[suit]

D.h. es laden sich nicht alle Bereiche neu, und ich springe trotzdem auf eine eigenständig andere html Seite ?

nein, du lädst nur in einem schaufenster eine dokument, alleingestellt keinen bezug zum anderen dokument hat oder lädst ressourcen von irgendwo her (datenbank, statische dokumente) die du dann ins dom des dokuments einfügst

Sprich, jeder Menüpunkt hat seine eigene html seite ?

1x ja (schlechte idee), 1x nein (noch schlechte idee)

[Gunnar Bittersmann]

@@Christian999:

Das Problem hierbei ist, ich kann ja nicht alle Inhalte auf eine html Seite packen...

Warum nicht?

Die Schwiergkeit, gleichbleibende Inhalte in jede Seite einzubauen, ist lösbar.

Navigiere ich in einem Menü ohne Frames, dann wird doch automatisch die komplette Seite neu geladen, oder ?

So isses. Wo ist das Problem?

Live long and prosper,
Gunnar

[Christian999]

@@Christian999:

Das Problem hierbei ist, ich kann ja nicht alle Inhalte auf eine html Seite packen...

Warum nicht?

Die Schwiergkeit, gleichbleibende Inhalte in jede Seite einzubauen, ist lösbar.

Navigiere ich in einem Menü ohne Frames, dann wird doch automatisch die komplette Seite neu geladen, oder ?

So isses. Wo ist das Problem?

Live long and prosper,
Gunnar

Nun, das Problem dabei ist, dass ich praktisch das Neuladen der Seite, mit dem dami verbundenen, sichtbaren, kurzen neuladen, für einige TEile der Seite vermeiden will.
Es soll wirklich, wie bei Frames, nur der Main-Teil neu geladen werden(siehe Expedia Seite).
Alle Frames in eine Seite packen? Ist das elegant ? Verzeih meine naive Frage, ich bin leider wirklich schon lange weg vom Thema und vielleicht stehe ich auf der Leitung...

lG
Christian

[EKKi]

Mahlzeit Christian999,

Nun, das Problem dabei ist, dass ich praktisch das Neuladen der Seite, mit dem dami verbundenen, sichtbaren, kurzen neuladen, für einige TEile der Seite vermeiden will.

Nochmal die Frage: warum?

Es soll wirklich, wie bei Frames, nur der Main-Teil neu geladen werden(siehe Expedia Seite).

Warum willst Du Deinen Benutzern die Information, auf welcher Seite sie sich gerade wirklich befinden, vorenthalten?

MfG,
EKKi

[Christian999]

Warum willst Du Deinen Benutzern die Information, auf welcher Seite sie sich gerade wirklich befinden, vorenthalten?

Ich will sie ihnen doch nicht vorenthalten.
Ich finde es einfach extrem "unruhig", wenn sich die seite komplett neu lädt.

[suit]

Ich will sie ihnen doch nicht vorenthalten.

das tust du aber dann damit (siehe mein post)

Ich finde es einfach extrem "unruhig", wenn sich die seite komplett neu lädt.

wie schon erwähnt: standardverhalten deines browsers, falscher browser (siehe mein post)

[Christian999]

Ich will sie ihnen doch nicht vorenthalten.
das tust du aber dann damit (siehe mein post)
Ich finde es einfach extrem "unruhig", wenn sich die seite komplett neu lädt.
wie schon erwähnt: standardverhalten deines browsers, falscher browser (siehe mein post)

damit willst du sagen, meine "beispielseite" expedia.de ist

1. nicht zeitgemäß
2. technisch schlecht gelöst und
3. kann mir niemand tipps geben, wie ich es trotzdem hinbekomme.

[suit]

damit willst du sagen, meine "beispielseite" expedia.de ist

vorweg, ich hab sie mir vorher garnicht angesehen

1. nicht zeitgemäß

das hab ich nicht gesagt - ich habe gesagt, dass das austauschen der inhalte ohne neuladen der kompletten seite als alleinige anforderung nicht genügt - deine beispielseite tut das aber ohnehin garnicht

zudem funktioniert die seite ohne javscript nicht (kein einziger link ist klickbar)

2. technisch schlecht gelöst und

527 Errors, 102 warning(s)
funktioniert ohne javascript nicht
unübersichtlich
gespickt mit barrieren

• da das aber keine seitenbewertung werden soll, werd ich jetzt damit aufhören - zusammenfassend: nimm diese seite weder visuell noch technisch als vorbild

3. kann mir niemand tipps geben, wie ich es trotzdem hinbekomme.

dir wurde von gunnar bereits gesagt, wie man quelltexte auslagern kann

erstelle zuerst ein html-template (barrierefrei, technisch einwandfrei) und kümmere dich dann ums auslagern der quelltexte (ohne javascript und frames), wenn das geschafft ist, formatiere deine seite mit css und befülle sie

danach kannst du mit javascript (wenn du unbedingt meinst) die "meine seite darf sich nicht jedes mal neu laden"-sache umsetzen - das ist nur dekoration, ein zusatzfeature - aber keineswegs grundanforderung

wenn man ordentliches html und css geschrieben hat, sind die ladezeiten ohnehin sehr gering und dieser "weiss-flacker-effekt" oder was auch immer ist auch in schlechten browsern kaum wahrnehmbar

[levu]

Hallo,

527 Errors, 102 warning(s)

Ich hab ein FF-Plugin, das checkt auch den mittels JS erzeugten Code und das kommt auf 950 Fehler und 78 Warnungen! Schon sauber, da werden die Frontpage-Entwickler neidisch!

mfg, Flo

[molily]

2. technisch schlecht gelöst und
   527 Errors, 102 warning(s)

Ach was. 99% davon scheinen vergessene maskierte &-Zeichen in URIs. Das hat dort einfach System. Und weil der Validator irgendwas nicht rallt, erkennt er zudem folgende Entity-Referenzen nicht, was die Fehleranzahl verdoppelt.

Expedia macht also ca. einen Fehler. Einen Fehler, den man auf Milliarden anderer Sites auch finden wird und der die Funktionsfähigkeit überhaupt nicht beeinträchtigt. Expedia würde um kein Stück technisch besser werden, wenn sie diesen Fehler beseitigen würden. Selbst wenn sie dann validen Code erreichen würde, wäre die Seite noch »technisch schlecht gelöst«.

Ich frage mich immer, wie Profis hier im forum, die es besser wissen sollten, Validator-Ergebnisse und insbesondere die Fehleranzahl zu Argumenten machen. Das war, ist und bleibt ohne Sinn und Aussagekraft.

Mathias

[suit]

Selbst wenn sie dann validen Code erreichen würde, wäre die Seite noch »technisch schlecht gelöst«.

ich hab doch gesagt, dass die seite technisch schlecht gelöst ist, da sie ohne javascript nicht funktioniert

Ich frage mich immer, wie Profis hier im forum, die es besser wissen sollten, Validator-Ergebnisse und insbesondere die Fehleranzahl zu Argumenten machen. Das war, ist und bleibt ohne Sinn und Aussagekraft.

die fehleranzahl ist nicht relevant - nachdem aber jeder abweichung von den vorgaben der dtd durch die fehlerkorrektur des browsers korrigiert werden muss oder erraten muss, kostet das wesentlich mehr rechenzeit als ohne fehler - und bei der menge spielt das in der tat eine rolle

dass kaputte entity-referenzen nicht so tragisch sind, halte ich für ein gerücht

<a href="http://example.com/index.php?foo=bar&copy=baz">weee</a>  

im übrigen ließen sich 50% der fehler durch das entfernen des unsinnigen "<script></script>" vor der dtd beheben

[molily]

nachdem aber jeder abweichung von den vorgaben der dtd durch die fehlerkorrektur des browsers korrigiert werden muss oder erraten muss, kostet das wesentlich mehr rechenzeit als ohne fehler

Es braucht doch nicht mehr Rechenzeit, eine Nicht-Entity-Referenz von einer echten zu unterscheiden. Das ist ein und dieselbe Parserroutine. Ob die nun bei einem & das nächste ; suchen muss und schaut, ob ein entsprechender Entity existiert, oder beim folgenden = schon merkt, dass daraus keine Entity-Referenz mehr wird, gibt wahrlich keinen Ausschlag.

Was andere Fehler angeht, so kann es durchaus sein, dass der Parser einige Extrarunden drehen muss, um aus Verschachtelungsfehlern ein sauberes DOM zu bauen (oder ein unsauberes wie in vielen Browsern, dass den kaputten Code auch wieder der Baumlogik repräsentiert). Die paar Millisekunden, die dafür draufgehen, dass der Parser das tut, wofür er optimiert ist, nämlich fehlertolerant jeden Müllcode noch zu schlucken, fallen aber sicher nicht ins Gewicht und bleiben unmerklich. Schwerer wiegt, dass CSS und JavaScript schwer mit einem kaputten bzw. nicht vorhersehbaren DOM zusammenarbeiten.

<a href="http://example.com/index.php?foo=bar&copy=baz">weee</a>

Klar gibt es Fallstricke, wenn man sich auf Browserquirks verlässt. Hier schlägt dann lustigerweise noch mehr Browserquirks zurück. Wer mit den Schmuddelkindern spielt, darf später nicht jammern.

im übrigen ließen sich 50% der fehler durch das entfernen des unsinnigen "<script></script>" vor der dtd beheben

Du meinst, es ließen sich 50% der Validatormeldungen unterbinden. Was mit Fehlerbehebung erstmal wenig zu tun hat...

Mathias

[suit]

im übrigen ließen sich 50% der fehler durch das entfernen des unsinnigen "<script></script>" vor der dtd beheben

Du meinst, es ließen sich 50% der Validatormeldungen unterbinden. Was mit Fehlerbehebung erstmal wenig zu tun hat...

richtig, genau so herum ;) an dem muss ich noch arbeiten

[suit]

zitiere bitte sinnvoll

Nun, das Problem dabei ist, dass ich praktisch das Neuladen der Seite, mit dem dami verbundenen, sichtbaren, kurzen neuladen, für einige TEile der Seite vermeiden will.

wieso? das ist ein ganz normales verhalten welches der benutzer gewöhnt sein sollte - es ist ein indiz dafür, dass die seite tatsächlich neu geladen wird

im übrigen: wenn dich das stört, wechsle den browser - kthml/webkit oder presto zeigen den effekt nicht (bzw nicht so stark)

Es soll wirklich, wie bei Frames, nur der Main-Teil neu geladen werden(siehe Expedia Seite).

das ist ein zusatzfeatue, aber kein primärziel - stelle zuerst sicher, dass die andere variante funktioniert

Alle Frames in eine Seite packen? Ist das elegant ? Verzeih meine naive Frage, ich bin leider wirklich schon lange weg vom Thema und vielleicht stehe ich auf der Leitung...

wie mir scheint, warst du nie richtig beim thema, denn frames waren schon immer out - die hätten eigentlich nie in irgend eine html-empfehlung kommen dürfen, aber irgend ein irrer bei netscape hat das wohl durchgedrückt

[molily]

Anno dazumal waren hierfür Frames der Klassiker, aber ich denke, diese Technik ist eher "out".

Warum sollen sie out sein?
Es ist für dieses Vorhaben immer noch die beste Lösung.
iframes oder das Nachladen von Inhalten mit JavaScript/XMLHttpRequest bringt im Grunde ähnliche, wenn nicht sogar weitreichendere Probleme mit sich. Genauso wie bei Frames muss man sich einen abbrechen, um die Site halbwegs benutzbar und zugänglich zu machen.

Für Denkanstösse und Tipps wäre ich sehr dankbar...

Wenn du dir nicht ernsthaft einen Haufen von Problemen einhandeln willst, versuche es mit einem klassischen Reload des ganzen Dokuments. Den aber solltest du bewusst wählen:

• Verringere die Größe des Quellcodes. Nutze ausgelagertes CSS und JavaScript.
• Verringere die Anzahl der »feststehenden« Elemente. Du musst keine ellenlange Navigationsleiste einbinden, und aktuelle Angebote in eine Seitenleiste zu quetschen hat auch nicht immer Vorteile.
• Liefere deine Seiten wenn möglich GZip-komprimiert aus, sorge für eine gute Serveranbindung für die Zielgruppe und sorge für Caching der Bilder. Dann lädt die Seite auch schnell. Die Ladegeschwindigkeit kannst du z.B. mit YSlow messen.

Mathias