Wenn man immer dieselbe Navigation hat, wäre ein "<include src="top.html" /> oder <include src="unten+impressum.html" /> oder halt über X-include/xinclude auch schon mal nicht schlecht.
Das ist zwar nicht so "fancy" wie per javascript Teile nachladen/ändern, aber würde den Traffic schon mal mindern, was sich bei GSM/UMTS usw. schon bemerkbar macht.
Siga43297442 schrieb:
--------------------------------------------------------------------------------
> Wenn man immer dieselbe Navigation hat, wäre ein " oder oder halt über
> X-include/xinclude auch schon mal nicht schlecht.
>
> Das ist zwar nicht so "fancy" wie per javascript Teile nachladen/ändern,
> aber würde den Traffic schon mal mindern, was sich bei GSM/UMTS usw. schon
> bemerkbar macht.
gibt's schon, nett sich iframe.
iframe schrieb:
> gibt's schon, nett sich iframe.
Depricated.
iframe schrieb:
--------------------------------------------------------------------------------
> gibt's schon, nett sich iframe.
Iframes sind wie eine mini-page in LaTeX und eigene Objekte.
Mir reicht eher ein cpp-mäßiges #include.
Evtl auch sicherheits-abgesichert, so das man nur vom gleichen server laden darf.
dann wird keine werbung geladen und "content-klau" ist damit dann auch nicht möglich. ausser in gepatchten browsern aber da geht das jetzt ja auch schon.
iframes sind unbeliebt, weil M$ sie iirc sicherheitslückenmäßig implementiert hatte.
Warum inkludierst du die Seiten nicht einfach serverseitig?
es ging ihm darum traffic zu sparen (für umts etc).
da macht es dann wenig sinn, wenn der server die sachen zusammenstellt und dann an den client sendet.
Mir wären vernünftige tarife (siehe 3 in österreich mit einer echten umts-flat für 20€) lieber als solche workarounds...
blub schrieb:
--------------------------------------------------------------------------------
> es ging ihm darum traffic zu sparen (für umts etc).
> da macht es dann wenig sinn, wenn der server die sachen zusammenstellt und
> dann an den client sendet.
> Mir wären vernünftige tarife (siehe 3 in österreich mit einer echten
> umts-flat für 20€) lieber als solche workarounds...
Danke. Mal einer, der nicht ständig Widerworte abgibt sondern nachvollziehen kann, was andere wollen.
Du hast aber weiter die Latenz die nicht gut weggeht oder nur mit Geld und teuren Tarifen. Ich mach umts/gsm seit Jahren. Und da sind schlanke Seiten (oder multirequests oder preloading oder sonstwas und halt ein Cache) schon angenehmer. Man merkt einfach, wenn Seiten fetter sind oder viele Java-Scripte nachladen.
Die fetten Sites meidet man dann. Und macht viel mit RSS.
Mir ging es ums Laden aber auch ums Senden. Wenn man mehr als 5 Besucher hat, muss man gucken, das man nicht gekündigt wird. Und das die Besucher schnell bedient werden, wäre auch in meinem Interesse. Also würde ich wiederholende Elemente gerne nur einmal laden. Bei CSS macht man das ja eh und packt die CSS-Befehle nicht in jedes .html/.php-File. Das verstehen die Leute sie single-file-Sites mit embedded gifs haben wollen, dann komischerweise doch plötzlich. Mimikri heisst das. :-(
asdfesdf schrieb:
--------------------------------------------------------------------------------
> iframe schrieb:
> > gibt's schon, nett sich iframe.
> Depricated.
Davon steht aber nichts in der aktuellen HTML5-Fassung (Revision 1.2852.).
Irgendwie macht es Sinn, was du schreibst. Wenn es konkrete Einwände gegen den XMLHttpRequest gäbe, bsw. dass es Browser gäbe, die kein JavaScript ausführen können/wollen, wäre es gut, zumindest diese Funktionalität in alle Browser zu implementieren.
Aber dieses "client-side include" wäre eben kein vollwertiger Ersatz für den XMLHttpRequest. Man kann es mit dem XMLHttpRequest sogar komplett nachbilden. Es genügt ja, eine zusätzliche Funktion in einer js-Datei einzubinden, die diese ganzen include-Tags durchläuft und die entsprechenden Seiten nachläd. Diese Datei müsste nur ein einziges Mal pro Website heruntergeladen werden, da sich die Funktionalität ja nicht ändert.
Ultrasonic schrieb:
--------------------------------------------------------------------------------
> Irgendwie macht es Sinn, was du schreibst. Wenn es konkrete Einwände gegen
> den XMLHttpRequest gäbe, bsw. dass es Browser gäbe, die kein JavaScript
> ausführen können/wollen, wäre es gut, zumindest diese Funktionalität in
> alle Browser zu implementieren.
> Aber dieses "client-side include" wäre eben kein vollwertiger Ersatz für
> den XMLHttpRequest. Man kann es mit dem XMLHttpRequest sogar komplett
Das habe ich auch nicht gemeint. Objekte holen per .js für AJAX ist ok und Standards für sowas sind für pda/handies usw. auch sinnvoll um anwendungen in anderen guis laufen zu lassen als der offiziellen auf 1920x1050 optimierten Ajax-Webseite der Anwendung.
Mir gehts eher um halb-statische Seiten und Navigation und sowas. Und bei meinen Seiten ist .js nur zusätzlich. Wer es nicht nutzt, muss halt hier und da einmal mehr klicken oder sowas oder auf live-search verzichten sondern den text eingeben und return in der Suchmaske drücken. Aber ohne .js geht es halt auch so gut wie möglich.
> nachbilden. Es genügt ja, eine zusätzliche Funktion in einer js-Datei
> einzubinden, die diese ganzen include-Tags durchläuft und die
> entsprechenden Seiten nachläd. Diese Datei müsste nur ein einziges Mal pro
> Website heruntergeladen werden, da sich die Funktionalität ja nicht ändert.
Mit xml geht das auch vielleicht. In den dtds gibts includes iirc. oder halt x:include oder sowas was IE wohl dann wieder nicht kann. Also lieber Sachen nehmen, die IE6(der konnte schon xslt. Opera damals noch nicht.) kann.
Aber beispielsweise über Seiten-Kompression/Traffic-Sparen mit xml-Entities brauche ich hier mit niemandem zu diskutieren. Für die wächst der Traffic der eigenen Firma auf Bäumen und wenn hermes-Sendungsabfrage 10 Sekunden braucht, bis sie mal geladen ist, während DHL nach dem Klick sofort geladen wird, ist solchen Leuten das voll egal.
Ich hab .js ausgeschaltet und mag es nicht.
Unnötig. Da deine Navigationselemente 1x aufgerufen werden und dann nie wieder. Weil der restliche Kontent nachgeladen wird => Einsparung an traffic.
Du hast den Sinn hinter HTTPRequests nicht verstanden.
(X)HTML 5 ist a) noch keine fertige Empfehlung und b) ein Haufen Müll.
Frames sind im 4.01-Standard drin, weil der von 1999 ist und zu der Zeit Frames weit verbreitet waren. Heutzutage gibt es keinen wirklichen Grund mehr, Frames einzusetzen. Umso schlimmer, dass es die eingebetteten Frames wohl in den neuen Standard schaffen werden.
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Du hast den Sinn hinter dem Include nicht verstanden. Hierbei wäre der Einbau von immer gleichen Seitenteilen möglich, ohne Scripting implementieren zu müssen und ohne dass es der Benutzer erlauben muss.
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Ein derartiger "include" lässt sich via JS leicht umsetzen. Wenns ohne scripting gehen soll, frames/iframes. Ich sehe nicht warum es hier bedarf gäbe.
zum XMLHTTPRequest object: Es wird von allen gängigen browsern unterstützt und ist somit bereits quasi-standard. Jetzt geht es halt darum für die offizielle definition dem rechnung zu tragen.
Hmmpf schrieb:
--------------------------------------------------------------------------------
> Ein derartiger "include" lässt sich via JS leicht umsetzen. Wenns ohne
> scripting gehen soll, frames/iframes. Ich sehe nicht warum es hier bedarf
> gäbe.
Weil Du iframes/frames kein impressum nachladen darfst das muss immer vorkommen auch in include-freien-seiten.
also muss das include "mitten" in offenen klammern/tables nachladen usw.
usw.
usw....
Aber gewissen Leute finden fiese nicht bookmarkbare Frames ja ganz toll. oder fiese iframes.
...
aber gegen ein #influde wehren sie sich mit php-händen und ie-füßen...
kt
blub schrieb:
--------------------------------------------------------------------------------
> es ging ihm darum traffic zu sparen (für umts etc).
> da macht es dann wenig sinn, wenn der server die sachen zusammenstellt und
> dann an den client sendet.
... die daten auf den client, die dieser dann dort zusammen stellen kann? client include ist schwachsinn und erzeugt potentielle security löcher. da kann ich ja gleich in /tmp gott und der welt schreibrecht geben...
case schrieb:
--------------------------------------------------------------------------------
> ... die daten auf den client, die dieser dann dort zusammen stellen kann?
> client include ist schwachsinn und erzeugt potentielle security löcher. da
> kann ich ja gleich in /tmp gott und der welt schreibrecht geben...
Nur weil IE bei IFrames Fehler einbaut, ist das kein Grund.
Nur weil Kapitalismus/Kommunismus/FussballWetten/Sportschützen (teilweise) nicht funktionieren, ist das kein Grund, sie alle abzuschaffen.
Du includest ständig gif/jpg-Bilder und .css in fast jeder .html-Seite die auf öffentlichen Sites liegt. Willst Du das auch verbieten ?
Jedes Frame-Set included andere html-Seiten.
Du willst also Framesets deswegen verbieten,... ?
Ist schon klar, wer Internet-Ausdrucker berät.
Das gibt es doch schon,
mach ein include auf ein javascript, das nichts anderes macht als Respose.Write("....html-code...")
schon hast du, was du willst.
... wie kommen die daten auf den client die du includen willst?
Kommentare: 171 | letzter Beitrag 20:42 Uhr
Kommentare: 94 | letzter Beitrag 26.05. 19:45
Kommentare: 77 | letzter Beitrag 20:57 Uhr
Kommentare: 70 | letzter Beitrag 18:56 Uhr
Kommentare: 61 | letzter Beitrag 21:29 Uhr
E-Mail an news@golem.de
Der japanische Spieldesigner Goichi Suda - Fans sagen schlicht "Suda 51" - ist für schräge Actionspiele bekannt. Sein nächstes Werk schickt ein scheinbar braves Schulmädchen in den Kampf gegen Zombies.
Weitgehend unbemerkt hat der US-Händler Tigerdirect die ersten Chromebox-Systeme von Google ausgeliefert. Für 330 US-Dollar bekommt der Nutzer recht gute Hardware in Nettop-Form, die sehr viel leistungsfähiger ist als die des Chromebook mit ChromeOS.
Der neue Chef der Piratenpartei steht im Verteidigungsministerium unter Druck. Elektronische Kommunikation für seine Partei ist ihm in der Dienstzeit untersagt. "Es gibt Leute im Ministerium, die darauf warten, dass ich Fehler mache", sagte Schlömer.
Renesas ist nach Elpida der zweite schwer angeschlagene japanische Chiphersteller. Renesas, das Hitachi, Mitsubishi Electric und NEC gehört, macht Verlust und will seine größte Fabrik verkaufen.
RIM soll in den kommenden Tagen erneut einen massiven Stellenabbau ankündigen. "Ich habe herausgefunden, welche Teile ich in meinem Puzzle nicht mehr benötige", sagte Firmenchef Thorsten Heins.
Ein britisches Blog will erfahren haben, dass Facebook den norwegischen Browserhersteller Opera Software kaufen will. Beide Unternehmen wollen sich dazu nicht äußern.