Javascript/Ajax: Bilder -> vergrößerte Ansicht

[maceis]

Hallo zusammen,

ein vorab: ich hab mit Javascript erst sehr wenig gemacht und stelle mich da vielleicht im Augenblick noch etwas unbeholfen an.

Ich betreue eine Website mit einer Seite, die einige relativ kleine Bilder enthält (ca. 270 x 180).
Ich habe folgende Ziel.
Schritt 1:
Nun möchte ich ein kleines Script einbauen, das mir die Bilder etwas vergrößert darstellt, aber ohne großen Aufwand, keine Diashow, weiterklicken etc.
Schritt 2:
Auf einer ähnlichen Seite soll das dann dahingehend ausgebaut werden, dass man durch eine geringe Zahl von Bildern durchklicken (Vor, Zurück, Sprung zu Bild n) kann und zu jedem Bild ein kleiner Text mit eingeblendet wird. Insgesamt sind es nicht mehr als 6-8 Bilder.

Ich denke, das könnte mit Ajax gemacht werden, habe aber damit noch keine Erfahrung und bräuchte einen kleinen Schubs in die richtige Richtung. Was die Sache evtl. etwas erschwert, ist, dass die Seiten mehrsprachig dynamisch mit Perl generiert werden.

Danke und Gruß
maceis

 

[dms]

Hi maceis,
das könnte man mit AJAX lösen, ja. Aber so wie sich das anhört wäre etwas wie die lightbox 2 oder ein Mod davon, die lytebox recht gut dafür geeignet. Hält den Aufwand um einiges niedriger als wenn Du mit AJAX was bastelst.

 

[_ebm_]

Wenn du die Bilder nachladen willst (das meinst du doch mit Ajax?), schau dir mal Mootools an. Dazu noch ein gutes Tutorial

Damit hab ich bisher alles erschlagen können, was mit Web 2.0 zutun hatte.

 

[scope]

Hi maceis,
das könnte man mit AJAX lösen, ja. Aber so wie sich das anhört wäre etwas wie die lightbox 2 oder ein Mod davon, die lytebox recht gut dafür geeignet. Hält den Aufwand um einiges niedriger als wenn Du mit AJAX was bastelst.

Entweder sowohl das von dir vorgeschlagene und das vom Autor erfragte ist AJAX — oder keins von beidem!

Was nun richtig ist, das ist ein wenig Definitionssache.Ich würde das Anzeigen von Bildern in größerer Version mit Javascript noch nicht als AJAX bezeichnen.

 

[maceis]

@dms
Genau das was ich im Augenblick gesucht habe. Vielen Dank

@_ebm_
Ich bin dabei mich in die Thematik einzuarbeiten. Vielen Dank für Deine Links. Die werden mir sicher noch hilfreich sein.

 

[_ebm_]

Was nun richtig ist, das ist ein wenig Definitionssache.Ich würde das Anzeigen von Bildern in größerer Version mit Javascript noch nicht als AJAX bezeichnen.

Ja, für mich ist das eher der Einsatz von XMLHTTPRequest... Darum fragte ich ja, ob das Nachladen der Bilder vom Server gemeint ist.

 

[Saugkraft]

Hallo zusammen,

ein vorab: ich hab mit Javascript erst sehr wenig gemacht und stelle mich da vielleicht im Augenblick noch etwas unbeholfen an.

Echt? Hätte ich nicht gedacht. Du bist doch sonst so ein Programmiercrack.

Sehr schön für die Bilderanzeige sind Simpleviewer und Postcardviewer.

Das sind beides kostenlose, flashbasierte Viewer, die mit ein paar kleinen Einstellungen out-of-the-box funktionieren und sehr ansehnlich sind. Passen zwar nicht für jeden Einsatzzweck, ein Blick lohnt sich aber in jedem Fall.

Und wenn dir lightbox zusagt, dann schau dir mal greybox an. Das Skript kann noch mehr als lightbox (lightbox kann nämlich nur Bilder anzeigen). Mit Greybox kannst du auch Webseiten und andere Inhalte darstellen.

 

[maceis]

Nun ja, jetzt übertreib mal nicht .
Flash möchte ich hier nicht einsetzen; vielleicht ein andermal.

Noch zwei Frage zu lightbox 2 (gefällt mir für meinen Zweck im Augenblick am besten).
- Wie portable ist das Ganze? Werden da ältere Browser (IE5 etc.) auch vernünftig unterstützt?
- in den IE, die ich bisher getestet habe und auch in FF wird das Bild am oberen Rand der Seite angezeigt. Nur in Safari erscheint das Bild angenehm etwa 2cm vom oberen rand abgerückt. Kann man da vielleicht was machen, dass das auch in anderen Browser so ist?

 

[dms]

Entweder sowohl das von dir vorgeschlagene und das vom Autor erfragte ist AJAX — oder keins von beidem!

Was nun richtig ist, das ist ein wenig Definitionssache.Ich würde das Anzeigen von Bildern in größerer Version mit Javascript noch nicht als AJAX bezeichnen.

Das Nachladen von Bildern hat im Falle der lightbox/lytebox nichts mit AJAX zu tun. AJAX steht für "Asynchronous JavaScript and XML" und hier ist keinerlei XML im Sinne von XMLHttpRequest im Spiel. AJAX ist aber eine Möglichkeit hierfür, nämlich dann wenn man die URLs und Beschreibungstexte der Bilder nicht beim initialen laden der Seite, sondern nachträglich, übermitteln möchte.

Scheint ein weitverbreitetes Misverständnis zu sein, dass alles was nachträglich im Dokument verändert wird als AJAX bezeichnet wird. AJAX heisst nicht "nachladen" sondern ist ein Protokoll dass Anfrage und Antwort in einem XML-Envelop voraussetzt.

@maceis
Eigentlich sollten die Bilder in allen Browsern 73.4px* von der oberen Bildschrimkante abstehen. Vlt. hast Du etwas auf Deiner Seite dass das speziell zerhaut? Funktionieren die Beispiele auf der Entwicklerseite denn ebenfalls wie von Dir beschrieben?
Zu älteren Browsern: IE5 wird nicht ganz so chique aussehen, der kann ja noch keine Transparenzen, wenn ich mich recht erinnere. Kannst es ja mal testen. Falls Du's noch nicht kennen solltest: Multiple IE

* Edit: Der Wert wird dynamisch, abhängig von der Fensterhöhe, gesetzt.

 

[_ebm_]

in den IE, die ich bisher getestet habe und auch in FF wird das Bild am oberen Rand der Seite angezeigt. Nur in Safari erscheint das Bild angenehm etwa 2cm vom oberen rand abgerückt. Kann man da vielleicht was machen, dass das auch in anderen Browser so ist?

Was Margin und Padding angeht, verhalten sich die Browser eh total anders. Ich setze die für die Seite immer erstmal global zurück (*{margin:0px;padding:0px;}) und setze sie dann für die Elemente nach meinem Gusto. Damit bekomme ich zumindest was Abstände angeht ein einigermassen einheitliches Verhalten hin. Ansonsten gibt es noch die Möglichkeit, den Browser abzufragen und dann unterschiedliches CSS einzubinden. IE5 ist aber ein ganz schlimmer Finger (wie Netscape 4 auch). Musst du die noch unterstüzten? Ich hab jetzt keine Ahnung, wie die Durchdringung ist. Ich optimiere nur noch für FF, IE6/7, Safari >=2.

 

[maceis]

@dms: Im Grundsatz weiß ich schon, was Ajax bedeutet. Hab nur noch nie was damit gemacht, was sich wohl demnächst ändern wird .

@_ebm_
Die globale Zurücksetzung mache ich auch immer. Problem ist manchmal, dass IE die Breiten anders definiert. Hat aber jetzt - glaube ich - nichts mit dem hier beschriebenen Effekt zu tun. Ich werde mir das am WE nochmal genauer ansehen.

Jedenfalls bin ich angenehm überrascht, dass sich so eine schöne Geschichte innerhalb weniger Minuten implementieren lässt. Hier kam mir auch meine dynmaische Seitengenerierung mit Perl sehr entgegen, weil ich insgesamt nur fünf Zeilen in den html-Templates ändern/ergänzen musste .

 

[Saugkraft]

Musst du die noch unterstüzten? Ich hab jetzt keine Ahnung, wie die Durchdringung ist.

Mit Sicherheit (oder beim IE 5 auch ohne Sicherheit ) nicht sehr hoch. Hier gibt's ne Statistik vom W3C.

Kommt halt immer auf den Nutzerkreis an. Für den täglichen Gebrauch würde ich mir nicht die Mühe machen, für den IE 5 zu optimieren. Irgendwann muss selbst der letzte Upgradegegner mal erkennen, dass es Zeit für halbwegs aktuelle Software ist. Schon im eigenen Interesse.

Allerdings gibt es mit Sicherheit Leute, die die Gurke noch einsetzen. Und wenn man (ist weit hergeholt, verdeutlicht aber gut die Überlegung) eine Anleitung zum Upgrade von IE 5 auf IE 7 ins Netz stellt, sollte die eben auch im IE 5 anständig aussehen. Schad ja nix, sich an Standards zu halten.

Hab nur noch nie was damit gemacht, was sich wohl demnächst ändern wird .

Dann geb ich dir jetzt schonmal nen Tipp. Wenn du mit XMLHTTPRequest arbeitest, sende den Request immer mit POST statt mit GET. In den meisten Tutorials ist GET angegeben.

Der IE hat die perfide Eigenart, den nachgeladenen Code aus dem Cache zu holen wenn man mit GET arbeitet. Mit POST lädt er immer die aktuelle Version. Wenn man nicht mit dem IE entwickelt, fällt einem das meist ziemlich spät auf und man sucht sich nen Wolf nach der Ursache.

 

[dms]

Hier gibt's ne Statistik vom W3C.

Meine Theorie dazu: Die Zahlen stimmen nicht. Ich bin mir sicher dass die Entwickler sich Ihre Statistiken alle selbst zerschiessen indem sie Ihre Seiten mit Urzeit-Browsern testen. Ein ewiger Kreislauf. Erst tausend mal testen und optimieren bis es auf Browser X passt, dann in die Statistiken schauen und erschreckt feststellen dass ja sooo viele Nutzer noch Browser X nutzen.

 

[Saugkraft]

Das ist natürlich möglich. Mit Sicherheit gibt es auch noch einige Tools (Web-Grabber, Download-Manager, etc.), die sich als IE 5 identifizieren.

Allerdings hab ich (vor einigen Monaten bei uns in der Uni) tatsächlich noch einen ganzen Computerpool mit dem IE 5.5 gesehen. Ich bin beinah aus den Socken gekippt. Gerade da wo sonst so auf Sicherheit und Standards geachtet wird, setzt man einen Browser ein, der mehr Löcher hat als ein Schweizer Käse und zu nix kompatibel ist.

Insofern glaube ich schon, dass der IE 5 durchaus noch im Umlauf ist.

Außerdem gibt es ja noch diverse Self-Made-Browser wie die Krücken von T-Online und AOL. Wenn ich nicht irre, basiert der T-Online Browser auch auf dem IE 5. Und den setzen garantiert noch einige ein.

 

[_ebm_]

Der IE5 wird noch überall dort installiert sein, wo ein Windows älter als XP installiert ist und der Nutzer keine Updates installiert. Das betrifft 99% alle Windows 95,98,ME,2k Installationen in Privathaushalten, da es dort kein Auto Update gab bzw dieses nicht standardmässig aktiviert ist. Mehr als 2% aller aktiven Websurfer wird das aber nicht ausmachen.

Außerdem gibt es ja noch diverse Self-Made-Browser wie die Krücken von T-Online und AOL. Wenn ich nicht irre, basiert der T-Online Browser auch auf dem IE 5. Und den setzen garantiert noch einige ein.

Die setzen die Browserengine ein, die in Windows installiert ist. Die ist nur eine Komponente und lässt sich überall einblenden. Outlook und MSHelp nutzen die zb auch.

 

[tulix]

Der IE hat die perfide Eigenart, den nachgeladenen Code aus dem Cache zu holen wenn man mit GET arbeitet. Mit POST lädt er immer die aktuelle Version. Wenn man nicht mit dem IE entwickelt, fällt einem das meist ziemlich spät auf und man sucht sich nen Wolf nach der Ursache.

Abhilfe schafft hier, einfach eine Zufallszahl oder irgendetwas einmaliges mit in den Querystring zu schreiben bzw. hinten anzuhängen.

Maceis hat geschrieben, dass er mit Perl arbeitet. Evtl. lohnt sich ein Blick in CGI::Ajax (http://search.cpan.org/~bct/CGI-Ajax-0.701/lib/CGI/Ajax.pm).
Ein recht einfaches, aber für kleinere Sachen ausreichendes Ajax Framework.

Dort gibt es für oben genannten Problem auch den Parameters [no-cache], der dafür sorgt, dass sich ein Browser den Code nicht aus dem Cache holt, sondern wirklich vom Server nachlädt.

 

[_ebm_]

Dort gibt es für oben genannten Problem auch den Parameters [no-cache], der dafür sorgt, dass sich ein Browser den Code nicht aus dem Cache holt, sondern wirklich vom Server nachlädt.

Ein <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="no-cache"> im Header der Seite bewirkt das gleiche (Würd mich nicht wundern, wenn das Script das sogar setzt)

 

[tulix]

Aber das meta-Tag gilt doch für ein einzelnes Dokument.

Wenn Du per Ajax einen Teil der Seite nachlädst, dann ist dieser kleine Teil aus Sicht des Browsers ein eigenständiges Dokument. Im Normalfall kann man in diesen AJAX-Komponenten aber keine Metatags unterbringen, weil sie ja irgendwo in den Body-Bereich geladen werden - nicht in den head-Bereich.

Daher bin ich mir ziemlich sicher, dass ein Meta-Tag das Cache-Problem für Elemente, die per Ajax nachgelanden werden, nicht löst. Allerdings habe ich es auch noch nicht getestet.

Der Parameter [no-cache] bei CGI::Ajax erzeugt kein Meta-Tag. Er erzeugt einen zusätzlichen PArameter im querystring, der eine lange Zufallszahl enthält.

 

[_ebm_]

Ahja, hast recht, es ging ja ums AJAX-Query.

 

[Saugkraft]

Abhilfe schafft hier, einfach eine Zufallszahl oder irgendetwas einmaliges mit in den Querystring zu schreiben bzw. hinten anzuhängen.

Das kann funktionieren, ebenso die No-Cache Variante. Ich hab aber in der Praxis erlebt, dass es in bestimmten Fällen nicht funktioniert.

Ich hab das HTTP RFC nicht vollständig verstanden, aber wenn ich nicht irre reicht no-cache alleine nicht aus. Der Client ist dadurch nur gezwungen, beim Server anzufragen ob es eine neuere Version der Seite gibt. Was, wenn der Server das verneint obwohl Änderungen vorhanden sind?

In meinem Fall waren es Inhalte von Formularfeldern (aus einer Datenbank) die nicht aktualisiert wurden. no-cache, response.expires = -1 haben keinen Effekt gezeigt. Warum auch immer.

myReq.setRequestHeader(”If-Modified-Since”, “Thu, 1 Jan 1970 00:00:00 GMT”);
myReq.setRequestHeader(”Cache-Control”, “no-cache”);

scheint zu funktionieren, verlassen will ich mich darauf aber nicht.

Der IE bewegt sich hier ja im Rahmen der Standards. GET Anfragen dürfen grundsätzlich gecached werden. POST Anfragen nicht.

Firefox ist bei AJAX jedenfalls deutlich leichter zu handhaben. Zum Beispiel auch wenn der User während die Abfrage läuft, die Übertragung abbricht. Bei FF kein Problem, bei dem IE musst man den Abbruch abfangen.