1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › XMLHttpRequest auf dem…

Mir würde ein client-side include langen

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Mir würde ein client-side include langen

    Autor: Siga43297442 20.11.09 - 18:55

    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.

  2. Re: Mir würde ein client-side include langen

    Autor: iframe 20.11.09 - 18:58

    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.

  3. Re: Mir würde ein client-side include langen

    Autor: asdfesdf 20.11.09 - 19:44

    iframe schrieb:
    > gibt's schon, nett sich iframe.
    Depricated.

  4. Re: Mir würde ein client-side include langen

    Autor: Siga9985297247 20.11.09 - 19:53

    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.

  5. Re: Mir würde ein client-side include langen

    Autor: --- 20.11.09 - 20:30

    Warum inkludierst du die Seiten nicht einfach serverseitig?

  6. Re: Mir würde ein client-side include langen

    Autor: blub 20.11.09 - 20:49

    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...

  7. Re: Mir würde ein client-side include langen

    Autor: Siga4392374249 20.11.09 - 21:41

    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. :-(

  8. Re: Mir würde ein client-side include langen

    Autor: frameset 20.11.09 - 21:43

    asdfesdf schrieb:
    --------------------------------------------------------------------------------
    > iframe schrieb:
    > > gibt's schon, nett sich iframe.
    > Depricated.
    Davon steht aber nichts in der aktuellen HTML5-Fassung (Revision 1.2852.).

  9. Re: Mir würde ein client-side include langen

    Autor: Ultrasonic 21.11.09 - 05:34

    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.

  10. Re: Mir würde ein client-side include langen

    Autor: Siga4984297 21.11.09 - 10:57

    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.

  11. Re: Mir würde ein client-side include langen

    Autor: Tingelchen 21.11.09 - 12:28

    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.

  12. Re: Mir würde ein client-side include langen

    Autor: GodsBoss 21.11.09 - 12:51

    (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.

  13. Re: Mir würde ein client-side include langen

    Autor: GodsBoss 21.11.09 - 12:53

    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.

  14. Re: Mir würde ein client-side include langen

    Autor: Hmmpf 21.11.09 - 14:25

    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.

  15. Re: Mir würde ein client-side include langen

    Autor: Siga39472497 21.11.09 - 18:08

    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...

  16. apache server side includes... (kt)

    Autor: case 22.11.09 - 09:07

    kt

  17. und wie kommen...

    Autor: case 22.11.09 - 09:12

    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...

  18. Re: und wie kommen...

    Autor: Siga459742497 22.11.09 - 11:23

    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.

  19. Re: Mir würde ein client-side include langen

    Autor: nepumuk 22.11.09 - 13:49

    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.

  20. beantworte doch mal meine frage ...

    Autor: case 22.11.09 - 14:04

    ... wie kommen die daten auf den client die du includen willst?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Stadtwerke Herborn GmbH, Herborn
  2. Max Planck Institute for Human Development, Berlin
  3. Kiefel GmbH, Freilassing
  4. Stadtwerke München GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Data Scientist: Ein Mann, der mit Daten Leben retten will
Data Scientist
Ein Mann, der mit Daten Leben retten will

Senfgelbes Linoleum im Büro und weniger Geld als in der freien Wirtschaft - egal, der Data Scientist Danilo Schmidt liebt seinen Job an der Charité. Mit Ärzten entwickelt er Lösungen für Patienten. Die größten Probleme dabei: Medizinersprech und Datenschutz.
Ein Porträt von Maja Hoock

  1. Computerlinguistik "Bordstein Sie Ihre Erwartung!"
  2. OpenAI Roboterarm löst Zauberwürfel einhändig
  3. Faceapp Russische App liegt im Trend und entfacht Datenschutzdebatte

Wolcen im Test: Düster, lootig, wuchtig!
Wolcen im Test
Düster, lootig, wuchtig!

Irgendwo zwischen Diablo und Grim Dawn: Die dreckige Spielwelt von Wolcen - Lords Of Mayhem ist Schauplatz für ein tolles Hack'n Slay - egal ob offline oder online, alleine oder gemeinsam. Und mit Cryengine.
Ein Test von Marc Sauter

  1. Project Mara Microsoft kündigt Psychoterror-Simulation an
  2. Active Gaming Footwear Puma blamiert sich mit Spielersocken
  3. Simulatoren Nach Feierabend Arbeiten spielen

Threadripper 3990X im Test: AMDs 64-kerniger Hammer
Threadripper 3990X im Test
AMDs 64-kerniger Hammer

Für 4.000 Euro ist der Ryzen Threadripper 3990X ein Spezialwerkzeug: Die 64-kernige CPU eignet sich exzellent für Rendering oder Video-Encoding, zumindest bei genügend RAM - wir benötigten teils 128 GByte.
Ein Test von Marc Sauter und Sebastian Grüner

  1. Ryzen Mobile 4000 (Renoir) Lasst die Ära der schrottigen AMD-Notebooks enden!
  2. HEDT-Prozessor 64-kerniger Threadripper schlägt 20.000-Dollar-Xeons
  3. Ryzen Mobile 4000 AMDs Renoir hat acht 7-nm-Kerne für Ultrabooks

  1. Gigafactory: Grüne kritisieren Grüne Liga wegen Baumfällstopp für Tesla
    Gigafactory
    Grüne kritisieren Grüne Liga wegen Baumfällstopp für Tesla

    Tesla hat Informationen zum geplanten Werk in Brandenburg veröffentlicht, denen zufolge bis zu 12.000 Menschen in der Gigafactory Berlin Brandenburg arbeiten sollen. Derweil gehen die Grünen Umweltschützer an, die einen Rodungsstopp veranlasst haben.

  2. SUV: Cadillac stellt erstes Elektrofahrzeug im April vor
    SUV
    Cadillac stellt erstes Elektrofahrzeug im April vor

    Cadillac will sein erstes Fahrzeug, das rein elektrisch angetrieben wird, im April 2020 zeigen. Es wird sich um einen SUV handeln.

  3. Digitalkamera: Panasonic entwickelt Sucher für Farbenblinde
    Digitalkamera
    Panasonic entwickelt Sucher für Farbenblinde

    Panasonic hat einen elektronischen Kamerasucher entwickelt, mit dem farbblinde Menschen genauso sehen können wie Normalsichtige.


  1. 07:58

  2. 07:32

  3. 07:12

  4. 18:22

  5. 18:00

  6. 17:45

  7. 17:30

  8. 17:15