nicht angemeldet
Content Slider mit JavaScript (ohne jQuery)
Gunnar BittersmannHallo zusammen!
Ich suche Beispiele für einen horizontalen Content Slider mit je einem Link (Pfeil) links und rechts ohne jQuery.
Beispielsweise, um den Inhalt einer Liste zu durchwandern.
Ich habe mich das letzte halbe Jahr in die Theorie von JavaScript eingelesen und auch schon einfachere Übungsbeispiele gelöst.
Mir geht es um das Lernen, wie die Dinge arbeiten, deshalb möchte ich keine vorgefertigten Plugins oder ähnliches verwenden.
Eine stundenlange google-Suche hat nichts gebracht.
Das benötigte HTML-Markup bzw. die CSS stellen kein Problem dar.
Eine der Kernfragen lautet: Mit welchen Techniken kann man Elemente schrittweise nach beiden Seiten bewegen.
Kennt vielleicht jemand gute Beispiele dazu?
Lieben Gruß
typograph
P.S.: Ich habe versucht, mit meinem bescheidenen Wissen selbst einen ContentSlider zu erstellen:
Mein ContentSlider
Ich habe das Intervall absichtlich mit sehr großen Zeiteineiten definiert.
Die Funktion ist absolut nicht ausgereift:
- Es ruckelt beim Verschieben der Liste, da nach dem ersten Verschieben vor jeder Bewegung in die gewünschte Richtung eine kleine Gegenbewegung in die andere Richtung ausgeführt wird (deshalb das große Intervall).
- Vom letzten Listenelement soll auch wieder zum ersten Listenelement "geblättert" werden und umgekehrt.
- Bei Doppelklick eines Pfeiles stoppt das Intervall nicht mehr.
- Wie lässt sich solch eine Funktion schreiben, um sie universal einsetzen zu können (unabhängig von der Breite der Liste)?
-
Ich suche Beispiele für einen horizontalen Content Slider mit je einem Link (Pfeil) links und rechts ohne jQuery.
Aber dort kannst du ja mal nachsehen, wie es gelöst wurde.
Eine stundenlange google-Suche hat nichts gebracht.
http://forum.jswelt.de/javascript/49355-suche-horizontalen-div-slider.html#post310112
-
http://forum.jswelt.de/javascript/49355-suche-horizontalen-div-slider.html#post310112
Nach kruzem Überfliegen vom Code würde ich dringend davon abraten.
Zum ersten ist der Code hinsichtlich OOP eine Katastrophe.
Zum anderen deuten einige Dinge (wie z.B. setTimeout) auf veralteten Code hin.-
Hallo,
Zum anderen deuten einige Dinge (wie z.B. setTimeout) auf veralteten Code hin.
Wie meinst du das? Also speziell das setTimeout! Was würdest du verwenden?
Viele Grüße
Siri-
Wie meinst du das? Also speziell das setTimeout! Was würdest du verwenden?
Ich würde sowieso mit CSS an die Transtitions rangehen. Habe aber gerade nicht Zeit ausfühlich auf die Frage von typograph zu antworten.
Aber wenn schon Animationen mit Javascript, dann bitte mit requestAnimationFrame [mdn]. setTimeout höchstens als Fallback.
-
Ich würde sowieso mit CSS an die Transtitions rangehen. Habe aber gerade nicht Zeit ausfühlich auf die Frage von typograph zu antworten.
Transtitions haben den Nachteil, das ein gewisser nicht näher genannter Browser sie nicht unterstützt.
-
Ich würde sowieso mit CSS an die Transtitions rangehen. Habe aber gerade nicht Zeit ausfühlich auf die Frage von typograph zu antworten.
Transtitions haben den Nachteil, das ein gewisser nicht näher genannter Browser sie nicht unterstützt.
Und das war auch nicht das Anliegen des OP.
Ich habe mich das letzte halbe Jahr in die Theorie von JavaScript eingelesen und auch schon einfachere Übungsbeispiele gelöst.
Mir geht es um das Lernen, wie die Dinge arbeiten, deshalb möchte ich keine vorgefertigten Plugins oder ähnliches verwenden.Er will es "nur" verstehen! Alles andere wäre auch verschwendete Zeit, weil es dafür fertige Lösungen noch und nöcher gibt.
-
Transtitions haben den Nachteil, das ein gewisser nicht näher genannter Browser sie nicht unterstützt.
Man könnte auch sagen: Ein gewisser nicht näher genannter Browser hat den Nachteil, dass er Transitions nicht unterstützt.
Klingt schöner ;)
Für den Fall gibt's Shims.
-
-
-
-
http://forum.jswelt.de/javascript/49355-suche-horizontalen-div-slider.html#post310112
Nach kruzem Überfliegen vom Code würde ich dringend davon abraten.
Keine Ahnung, das habe ich auf die schnelle gefunden. Wenn es funktioniert(nicht getestet), kann man die Funktionsweise vermutlich schneller erkennen als bei JQuery.
Zum ersten ist der Code hinsichtlich OOP eine Katastrophe.
Also ich habe das jetzt auch mal schnell überflogen und bin (auf den ersten Blick) anderer Meinung! Was ist denn dort eine Katastrophe?
Zum anderen deuten einige Dinge (wie z.B. setTimeout) auf veralteten Code hin.
Ein setTimeout habe ich dort nicht gefunden. Und was ist daran veraltet?
-
Zum ersten ist der Code hinsichtlich OOP eine Katastrophe.
Also ich habe das jetzt auch mal schnell überflogen und bin (auf den ersten Blick) anderer Meinung! Was ist denn dort eine Katastrophe?Zum Beispiel das Leugnen von Prototypen.
-
Zum ersten ist der Code hinsichtlich OOP eine Katastrophe.
Also ich habe das jetzt auch mal schnell überflogen und bin (auf den ersten Blick) anderer Meinung! Was ist denn dort eine Katastrophe?Zum Beispiel das Leugnen von Prototypen.
Das hat 1. nichts mit OOP zu tun und ich sehe 2. nicht, was daran eine Katastrophe sein soll.
-
Zum Beispiel das Leugnen von Prototypen.
Das hat 1. nichts mit OOP zu tun und ich sehe 2. nicht, was daran eine Katastrophe sein soll.Doch das hat es sehr wohl. Genauso könntest du behaupten c++ Klassen hätten nichts mit Objektorientiertheit zu tun.
Die katastrophe ist schnell erklärt. Angenommen ich erstelle 1.000.000 slide-Instanzen, dann erstelle ich auch 1.000.000 mal sämtliche Methoden. Hätte ich sauber gearbeitet (mit Prototypen), dann hätte ich 1.000.000 Instanzen, die sich alle die selben Methoden teilen.
-
Die katastrophe ist schnell erklärt. Angenommen ich erstelle 1.000.000 slide-Instanzen, dann erstelle ich auch 1.000.000 mal sämtliche Methoden. Hätte ich sauber gearbeitet (mit Prototypen), dann hätte ich 1.000.000 Instanzen, die sich alle die selben Methoden teilen.
Hier noch ein jsperf-Test, der die Dramatik verdeutlicht.
-
Die katastrophe ist schnell erklärt. Angenommen ich erstelle 1.000.000 slide-Instanzen, dann erstelle ich auch 1.000.000 mal sämtliche Methoden. Hätte ich sauber gearbeitet (mit Prototypen), dann hätte ich 1.000.000 Instanzen, die sich alle die selben Methoden teilen.
Hier noch ein jsperf-Test, der die Dramatik verdeutlicht.
Die sehe ich hier nicht, was ich sehe ist, daß das Anlegen von Objekten mit und ohne Prototyp in den Unterschieden der Browser untergeht. Einzig Chrome scheint in der Hinsicht stark optimiert zu haben. Das werden sie in die andere Richtung sicher auch noch machen.
Aber selbst wenn es nicht so wäre, nimm mal noch die Aufrufe der Funktionen (welche in der Regel ja häufiger vorkommen als das Anlegen eines Objektes) in den Test mit auf.
-
Aber selbst wenn es nicht so wäre, nimm mal noch die Aufrufe der Funktionen (welche in der Regel ja häufiger vorkommen als das Anlegen eines Objektes) in den Test mit auf.
Ist es doch. die Zeile:
foo.bar();
-
-
-
Hallo,
Die katastrophe ist schnell erklärt. Angenommen ich erstelle 1.000.000 slide-Instanzen, dann erstelle ich auch 1.000.000 mal sämtliche Methoden. Hätte ich sauber gearbeitet (mit Prototypen), dann hätte ich 1.000.000 Instanzen, die sich alle die selben Methoden teilen.
Nur mal so zum Verständnis für mich, weil ich mit dem Thema eh immer a bisserl auf Kriegsfuß steh... Ich kann doch auch über Konstruktoren Instanzen erzeugen, oder etwa nicht?
Viele Grüße
Siri-
Nur mal so zum Verständnis für mich, weil ich mit dem Thema eh immer a bisserl auf Kriegsfuß steh... Ich kann doch auch über Konstruktoren Instanzen erzeugen, oder etwa nicht?
Ja klar. Das machst du auch, wenn du mit Prototypen arbeitest. Der Vorteil, wenn eine Methode über den Prototypen angelegt wird, und nicht innerhalb des Konstruktors, besteht darin, dass sich alle Instanzen die selbe Methode teilen.
Du kannst dazu einfach mal weiter in molilys Einführung lesen.
-
Du kannst dazu einfach mal weiter in molilys Einführung lesen.
Boah, den hab ich schon ein paar mal gelesen und versteh in vielleicht jetzt ein bischen besser. Das mit dem Performancegewinn leuchtet ein. Was sind denn jetzt die Nachteile? Ist jede Instanz völlig unabhängig von den anderen?
-
Was sind denn jetzt die Nachteile? Ist jede Instanz völlig unabhängig von den anderen?
Bei jedem Zugriff auf die Eigenschaften des Prototypen zahlst du drauf. (Ist aber genau wie beim Zuweisen im Konstruktor m.M.n. vernachlässigbar).
Du kannst nicht auf gekapselte Eigenschaften zugreifen (jedenfalls nicht über Funktionsgrenzen hinweg, innerhalb einer Funktion kann man natürlich wieder kapseln).
Ob das Vor- oder Nachteile sind, hängt von der Aufgabe und den Anforderungen ab. Du kannst in JS eine Aufgabe auf mehrere Wege lösen, das ist ja das schöne an JS.
-
Was sind denn jetzt die Nachteile? Ist jede Instanz völlig unabhängig von den anderen?
Bei jedem Zugriff auf die Eigenschaften des Prototypen zahlst du drauf. (Ist aber genau wie beim Zuweisen im Konstruktor m.M.n. vernachlässigbar).
... weil bei jedem Aufruf die Methode erst in der Prototyp-Kette nachgeschlagen werden muss, das kostet Zeit.
Du kannst nicht auf gekapselte Eigenschaften zugreifen (jedenfalls nicht über Funktionsgrenzen hinweg, innerhalb einer Funktion kann man natürlich wieder kapseln).
In dem Zusammenhang sei auf das Module-Pattern hingewiesen.
-
Du kannst nicht auf gekapselte Eigenschaften zugreifen (jedenfalls nicht über Funktionsgrenzen hinweg, innerhalb einer Funktion kann man natürlich wieder kapseln).
In dem Zusammenhang sei auf das Module-Pattern hingewiesen.
Das erzeugt aber ein Singelton, wieder was anderes, damit fällt ja dein Argument (Zeit bei der Instanziierung) ganz weg.
-
Das erzeugt aber ein Singelton, wieder was anderes, damit fällt ja dein Argument (Zeit bei der Instanziierung) ganz weg.
Das ist korrekt. Ich habe darauf hingewiesen, weil ich die Art der Datenkapselung elegant finde.
Für unsere Problemstellung müsste man statt eines simplen Objekts eine Konstruktor-Funktion zurück geben.
-
Das ist korrekt. Ich habe darauf hingewiesen, weil ich die Art der Datenkapselung elegant finde.
Es gibt nur eine Art der Datenkapselung in JS, und das ist über closures.
Für unsere Problemstellung müsste man statt eines simplen Objekts eine Konstruktor-Funktion zurück geben.
Bei welcher dann aber alle gekapselten Daten wieder nur statisch sind. Was aber nicht das Thema war/ist.
Was die Nutzung des Prototypen mit OOP zu tun hat, hast du immer noch nicht erklärt
Oder es ist bei mir nicht angekommen. Ich behaupte immer noch, daß gerade dessen Nutzung eine der fundamentalsten Regeln der OOP verhindert.
Aber das ist alles Ideologie und Ideologie ist Idiotie. Ein JS-Objekt mit leerem Prototypen ist keine Katastrophe. Mit auch nicht. Es gibt mehrere Möglichkeiten.-
Das ist korrekt. Ich habe darauf hingewiesen, weil ich die Art der Datenkapselung elegant finde.
Es gibt nur eine Art der Datenkapselung in JS, und das ist über closures.Oder aber Pseudo-Kapselung mit Konvetion, wie sie zum Beispiel molily vorschlägt.
Oder aber eine selbst geschriebene Accessor-Logik.
Oder aber auf Harmony warten.Bei welcher dann aber alle gekapselten Daten wieder nur statisch sind. Was aber nicht das Thema war/ist.
Nö wars nicht, aber ist ja nichts neues, dass innerhalb eines Threads mehrere Dinge thematisiert werden.
Was die Nutzung des Prototypen mit OOP zu tun hat, hast du immer noch nicht erklärt
Nein, du hast nur eine verquerte Ansicht von OOP. Vererbung wird in Javascript über Prototypen realisiert und ich weiß nicht, wie sich das nach irgendeiner Definition von OOP strikt auseinander halten lässt.
Oder es ist bei mir nicht angekommen. Ich behaupte immer noch, daß gerade dessen Nutzung eine der fundamentalsten Regeln der OOP verhindert.
Und was ist diese fundamentalste Regel?
Aber das ist alles Ideologie und Ideologie ist Idiotie. Ein JS-Objekt mit leerem Prototypen ist keine Katastrophe. Mit auch nicht. Es gibt mehrere Möglichkeiten.
Da stimme ich dir zu, solange der Author sich darüber bewusst ist, warum er sich für das eine oder andere entscheidet. In unserem konkreten Fall unterstelle ich dem Author das Gegenteil.
-
Vererbung wird in Javascript über Prototypen realisiert
Kann realisiert werden! Nicht wird realisiert! Realisieren kann ich das auch über den Konstruktor.
und ich weiß nicht, wie sich das nach irgendeiner Definition von OOP strikt auseinander halten lässt.
Was lässt sich nicht auseinander halten? Den Teil verstehe ich nicht ganz.
Und was ist diese fundamentalste Regel?
Kapselung!
-
Vererbung wird in Javascript über Prototypen realisiert
Kann realisiert werden! Nicht wird realisiert! Realisieren kann ich das auch über den Konstruktor.Dann hat's aber jede Instanz fest eingebaut und bekommts nicht vererbt???
gruß
peter-
Dann hat's aber jede Instanz fest eingebaut und bekommts nicht vererbt???
Ja, bei Vererbung über den Prototypen hat es nur dieser und es wird delegiert (bzw. bei Änderung auch an die "Instanz" kopiert.
Mit beiden Varianten kann ich eine Vererbung modellieren.
-
-
Vererbung wird in Javascript über Prototypen realisiert
Kann realisiert werden! Nicht wird realisiert! Realisieren kann ich das auch über den Konstruktor.Nö, du sprichst von Mixins. Echte Vererbung, nach Maßstäben des instanceof-Operators, funktioniert nur über Prototypen.
und ich weiß nicht, wie sich das nach irgendeiner Definition von OOP strikt auseinander halten lässt.
Was lässt sich nicht auseinander halten? Den Teil verstehe ich nicht ganz.Und was ist diese fundamentalste Regel?
Kapselung!Folgender Abschnitt wird wieder sehr ideologisch.
Kapselung spielt ausschließlich bei der Implementation, nicht aber bei der Spezifikation, eine Rolle. Datenkapselung dient somit nur dazu, die Implementation vor der Schnittstelle zu verstecken. Es ist nur Komfort, aber kein Muss. Infolgedessen betrachte ich es auch nicht als eine der fundamentalsten (Superlativ!) Regeln der OOP.
-
-
-
-
-
-
-
-
-
-
-
Zum Beispiel das Leugnen von Prototypen.
Das hat 1. nichts mit OOP zu tun und ich sehe 2. nicht, was daran eine Katastrophe sein soll.Doch das hat es sehr wohl. Genauso könntest du behaupten c++ Klassen hätten nichts mit Objektorientiertheit zu tun.
Genau das behaupte ich, du kannst in C++ mit Klassen arbeiten und trotzdem gegen jede Regel der OOP verstoßen. Ein Objekt macht noch lange keine OOP aus.
Die katastrophe ist schnell erklärt. Angenommen ich erstelle 1.000.000 slide-Instanzen, dann erstelle ich auch 1.000.000 mal sämtliche Methoden. Hätte ich sauber gearbeitet (mit Prototypen), dann hätte ich 1.000.000 Instanzen, die sich alle die selben Methoden teilen.
Die Methode wird auch hier nur einmal als Code vorhanden sein, die 1.000.000 Eigenschaften, welche auf die Methode verweisen gäbe es nicht (zusätzlich zu den 1.000.000 Eigenschaften die auf den Prototypen verweisen), ja. Und nun? Wo ist da das Problem?
-
zusätzlich zu den 1.000.000 Eigenschaften die auf den Prototypen verweisen
Ok, Prototype ist falsch, nehmen wir constructor
-
Zum Beispiel das Leugnen von Prototypen.
Das hat 1. nichts mit OOP zu tun und ich sehe 2. nicht, was daran eine Katastrophe sein soll.Doch das hat es sehr wohl. Genauso könntest du behaupten c++ Klassen hätten nichts mit Objektorientiertheit zu tun.
Genau das behaupte ich, du kannst in C++ mit Klassen arbeiten und trotzdem gegen jede Regel der OOP verstoßen. Ein Objekt macht noch lange keine OOP aus.Neee, darauf lasse ich mich jetzt nich ein.
Die katastrophe ist schnell erklärt. Angenommen ich erstelle 1.000.000 slide-Instanzen, dann erstelle ich auch 1.000.000 mal sämtliche Methoden. Hätte ich sauber gearbeitet (mit Prototypen), dann hätte ich 1.000.000 Instanzen, die sich alle die selben Methoden teilen.
Die Methode wird auch hier nur einmal als Code vorhanden sein, die 1.000.000 Eigenschaften, welche auf die Methode verweisen gäbe es nicht (zusätzlich zu den 1.000.000 Eigenschaften die auf den Prototypen verweisen), ja. Und nun? Wo ist da das Problem?
-
-
-
-
-
-
-
Danke für den Link!
-
http://forum.jswelt.de/javascript/49355-suche-horizontalen-div-slider.html#post310112
Sei gegrüßt!
Als Anfänger in JavaScript beiße ich mir beim Versuch, dieses Skript (Link oben) zu verstehen, die Zähne aus.
Die einzelnen Funktionen erschließen sich mir bestenfalls rudimentär.Ist es möglich, die einzelnen Funktionen und deren Zusammenhänge kurz zu erklären?
Aber ich fürchte, das sprengt jeden zeitlichen Rahmen, den ich von jemanden erwarten kann.Das in der letzten Zeile des Skripts Argumente/Werte an die Funktion slide() übergeben werden, ist mir soweit klar. Das die Funktion slide() diese Argumente/Werte in eigenen Vaiablen speichert und weiterverarbeitet, verstehe ich auch.
Die einzelnen verschachteln Funktionen innerhalb slide() erschliessen sich mir nur mehr ansatzweise. Für einen Anfänger sind auch die Variablennamen nicht unbedingt informativ.Zu viele Fragen, wie ich fürchte ...
Lieben Gruß
typograph-
Zu viele Fragen, wie ich fürchte ...
Sieh dir das mal an, vielleicht findest du ja dort ein paar Antworten.
-
Das bringt mich ein Stück näher zum Verständnis.
Vielen Dank!
-
-
-
-
@@typograph:
nuqneH
Ich suche Beispiele für einen horizontalen Content Slider mit je einem Link (Pfeil) links und rechts ohne jQuery.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)