nicht angemeldet
Bildwechsel - Problem mit Zähler
MudGuard
JürgenBHallo,
folgendes: ich habe einen Bildwechsel onclick mit javascript.
Jetzt möchte ich, dass angezeigt wird, bei welchem Bild sich der User gerade befindet. Also z.b. "2/6" beim nächsten "3/6" ...
in meinem Array sind die Bilder nicht nummeriert und ich weiß nicht, wie ich das aktuelle Bild definieren muss.
<header>
<script type="text/javascript">
var imgs = [
'grafics/1.jpg',
'grafics/2.jpg',
'grafics/3.jpg',
'grafics/4.jpg'
];
imgs.rotate = function (direction) {
if (direction > 0) { this.push(this.shift()); }
else if (direction < 0) { this.unshift(this.pop()); }
}
function nextImg(direction) {
imgs.rotate(direction);
document.getElementById("bg").src = imgs[0];
}
</script>
</header>
<body>
<div class="navibilder" style="width:40%;"><script type="text/javascript">
<!--
document.write ('<p><a href="javascript:nextImg(- 1)"> < prev<\/a> | <a href="javascript:nextImg(1)">next > <\/a><\/p>');
// -->
</script></div>
<div><img id="bg" src="grafics/1.jpg"></div>
</body>
Ich hoffe, ihr könnt mir helfen...
-
Ein Nachtrag:
Die Aufzählung der Bilder "2/6", "3/6" ... soll in einem neuen div liegen!
-
Hallo!
Die Aufzählung der Bilder "2/6", "3/6" ... soll in einem neuen div liegen!
Hallo! Ich habe nur eine ungetestete Idee, die ich leider gerade nicht austesten kann:
Du könntest dir einfach ein Array basteln. Dieses Array wird dann ausgelesen, onclick wird das nächste Bild angezeigt und der Text in einem Div mit der ID X von ID0/length(array) zu ID1/length(array) geändert. Die IDs könntest du dann als array-key notieren.Liebe Grüße aus Norddeutschland.
--
ie:{ fl:( br:> va:} ls:[ fo:| rl:? n4:~ ss:) de:> js:| ch:? sh:( mo:) zu:)
-
-
in meinem Array sind die Bilder nicht nummeriert und ich weiß nicht, wie ich das aktuelle Bild definieren muss.
Doch, sind sie, du nutzt das nur nicht aus.
Statt über push/shift dauernd das Array umzupflügen lass einfach den Index durchlaufen, schon hast du auch direkt Zugriff auf die Bildnr.
-
Hallo,
Statt über push/shift dauernd das Array umzupflügen lass einfach den Index durchlaufen, schon hast du auch direkt Zugriff auf die Bildnr.
Das ist nicht wirklich einfacher: Der Index muss ja verwaltet werden, d.h. jeweils hoch- und runtergezählt und am Anfang/Ende wieder zurückgesetzt.
Die push/shift-Variante finde da ich viel eleganter – nicht zuletzt deshalb, weil ich mich als Erfinder dieser rotate-Funktion sehe ;)
Gruß, Don P
-
Das ist nicht wirklich einfacher: Der Index muss ja verwaltet werden, d.h. jeweils hoch- und runtergezählt und am Anfang/Ende wieder zurückgesetzt.
aber einfacher als parallel zu push/shift eine Indexverwaltung einzubauen!
Die push/shift-Variante finde da ich viel eleganter – nicht zuletzt deshalb, weil ich mich als Erfinder dieser rotate-Funktion sehe ;)
bist du schon soooo alt?
-
Hallo,
Die push/shift-Variante finde da ich viel eleganter – nicht zuletzt deshalb, weil ich mich als Erfinder dieser rotate-Funktion sehe ;)
bist du schon soooo alt?Das nicht, aber ich habe sie halt erfunden. Wahrscheinlich nicht als einziger (das Rad wurde und wird ja auch laufend erfunden), aber ich sehe an der Art der Einrückung im OP, dass es genau meine ist, die ich hier in diesem Forum mal gepostet habe. :)
Gruß, Don P
-
-
Hi,
Das ist nicht wirklich einfacher: Der Index muss ja verwaltet werden, d.h. jeweils hoch- und runtergezählt und am Anfang/Ende wieder zurückgesetzt.
Wieso zurücksetzen? Der modulo-Operator existiert.
Die push/shift-Variante finde da ich viel eleganter
weil Du den JS-internen Aufwand, die Elemente im Array zu verschieben, nicht mit betrachtest.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Hallo,
Das ist nicht wirklich einfacher: Der Index muss ja verwaltet werden, d.h. jeweils hoch- und runtergezählt und am Anfang/Ende wieder zurückgesetzt.
Wieso zurücksetzen? Der modulo-Operator existiert.
Ja, sicher. Mit anschließender Spezialbehandlung bei negativen Werten, ist ja hier im Thread vorgeführt worden. Es ist nicht einfacher, sondern erfordert mehr Hirnschmalz, und der Code sieht neben meinem richtig Sch... aus ;).
Die push/shift-Variante finde da ich viel eleganter
weil Du den JS-internen Aufwand, die Elemente im Array zu verschieben, nicht mit betrachtest.
Der ist hier auch irrelevant. Es geht darum, dass jeweils ein Button geklickt wird, und daraufhin wird ein anderes Bild angezeigt. Zwischen den Klicks ist massig Zeit, intern ein Array zu manipulieren. In einer Schleife mit x Durchläufen würde ich das sicher auch anders machen.
Gruß, Don P
-
Hi!
Die push/shift-Variante finde da ich viel eleganter
weil Du den JS-internen Aufwand, die Elemente im Array zu verschieben, nicht mit betrachtest.
Der ist hier auch irrelevant. Es geht darum, dass jeweils ein Button geklickt wird, und daraufhin wird ein anderes Bild angezeigt. Zwischen den Klicks ist massig Zeit, intern ein Array zu manipulieren. In einer Schleife mit x Durchläufen würde ich das sicher auch anders machen.Als Anwender erwarte ich, dass auf meinen Klick hin etwas passiert und nicht irgendwann später. Die Zeit zwischen zwei Klicks ist ja nicht nur in diesem Fall abhängig davon, wie lange ich mir ein Bild betrachte, sondern es kommt auch noch die hinzu, die zwischen dem Klick und dem Erscheinen des nächsten Bildes vergeht. Und die sollte gegen Null tendieren. Das erwarte ich als Anwender, sonst klicke ich nochmal, weil ich denke, dass es nicht getroffen hat.
Bei vier Bildern fällt das zwar noch unter Microoptimierung, ab wann es spürbar wird, müsste man herausfinden. Wie auch immer, die Argumente sind ausgetauscht, entscheiden muss sich der geneigte Leser und potentielle Verwender letztlich selbst.
Lo!
-
Hallo,
Als Anwender erwarte ich, dass auf meinen Klick hin etwas passiert und nicht irgendwann später. Die Zeit zwischen zwei Klicks ist ja nicht nur in diesem Fall abhängig davon, wie lange ich mir ein Bild betrachte, sondern es kommt auch noch die hinzu, die zwischen dem Klick und dem Erscheinen des nächsten Bildes vergeht. Und die sollte gegen Null tendieren. Das erwarte ich als Anwender, sonst klicke ich nochmal, weil ich denke, dass es nicht getroffen hat.
Nun übertreib' mal nicht! Die Zeit für ein push(shift()) oder unshift(pop()) ist unabhängig von der Arraylänge absolut nicht spürbar, wenn das vom Benutzer durch Klicken einzeln ausgelöst wird. Allenfalls mit vielen Schleifendurchläufen könnte man sie spüren.
Es wird hier auch immer angedeutet, dass intern ein Riesenaufwand für's Umschichten der Array-Elemente stattfinden muss. Woher weiß man das? Ich kann mir vorstellen, das intern sehr optimierter Code läuft. push(shift()) etc. ist jedenfalls recht schnell, habe dazu schon Messungen durchgeführt in FF und Opera. Der IE tut sich vermutlich mit Arrays noch immer schwer...
Gruß, Don P
-
Hi!
Als Anwender erwarte ich, dass auf meinen Klick hin etwas passiert und nicht irgendwann später. Die Zeit zwischen zwei Klicks ist ja nicht nur in diesem Fall abhängig davon, wie lange ich mir ein Bild betrachte, sondern es kommt auch noch die hinzu, die zwischen dem Klick und dem Erscheinen des nächsten Bildes vergeht. Und die sollte gegen Null tendieren. Das erwarte ich als Anwender, sonst klicke ich nochmal, weil ich denke, dass es nicht getroffen hat.
Nun übertreib' mal nicht! Die Zeit für ein push(shift()) oder unshift(pop()) ist unabhängig von der Arraylänge absolut nicht spürbar, wenn das vom Benutzer durch Klicken einzeln ausgelöst wird. Allenfalls mit vielen Schleifendurchläufen könnte man sie spüren.Ok, ich sehe erst ab 1 Million Array-Elementen im FF 3.6.8 eine leichte Verzögerung (und immer noch keine im IE8). Die Performance-Frage ist also für handelsübliche Bildermengen irrelevant.
Es wird hier auch immer angedeutet, dass intern ein Riesenaufwand für's Umschichten der Array-Elemente stattfinden muss. Woher weiß man das?
Ich weiß aufgrund meiner Kenntnisse, dass es mehr Aufwand ist, als lediglich einen Zähler zu inkrementieren.
Ich kann mir vorstellen, das intern sehr optimierter Code läuft. push(shift()) etc. ist jedenfalls recht schnell,
Es gibt einen Unterschied zwischen einfachen Typen wie Zahlen und komplexeren wie Objekten. Die eigentlichen Daten eines Objekts bleiben im Speicher stehen, lediglich Referenzen darauf müssen umsortiert werden. Einfache Typen werden direkt umgeschichtet. Der Aufwand ist in beiden Fällen ziemlich gleich, weil einfache Typen und Referenzen jeweils nur aus wenigen Bytes bestehen. Das Array (mit den einfachen Werten oder den Referenzen) belegt einen bestimmten Speicherbereich. Davor und danach ist nicht genügend Platz. Vermutlich wird ein bisschen mehr Platz reserviert worden sein, damit nicht bei jeden neu anzuhängenden Element das gesamte Array auf einen größeren Platz umkopiert werden muss. Jedenfalls ist nicht so viel Platz vorhanden, dass es in alle Ewigkeit beim Rotieren in die eine oder andere Richtung wandern kann. Interessant sind hierbei nur die Methoden shift() und unshift(). pop() ist unkritisch, push() meistens auch, weil der vermutete Puffer verwendet werden kann, jedenfalls bis er voll ist und ein Umkopieren in einen größeren Bereich oder was adäquates notwendig ist. Was also kann shift() und unshift() machen?
Man kann:- die Elemente im vorhandenen Platz nachrutschen lassen.
- Elemente können in neuer Formation an neu reservierten Platz umkopiert werden.
Je nachdem, wie beide Vorgänge optimiert sind, verbrauchen sie Zeit. Auf Maschinencode-Ebene würde man einen Speicherbereich verschieben und wäre schnell, weil ein Prozessor sowas ständig machen muss und darauf optimiert ist. Je weiter man sich die Abstraktionsebenen nach oben hangelt, desto weniger kann man mit Speicherbereichen an Variablentypgrenzen vorbei direkt hantieren. Hier kommt es dann auf die jeweilige Implementation an, was wirklich passiert. Ich nehme mal an, dass der FF die Elemente einzeln umlagert, denn irgendwoher muss sein Zeitverbrauch ja herkommen.
Eine verkettete Liste wäre das Gebilde mit dem wenigsten Aufwand beim Umsortieren. Die Elemente stehen irgendwo im Speicher und Vorgänger und Nachfolger (oder auch nur in eine Richtung) sind durch Referenzen bekannt. Man muss nur die Referenen von maximal drei Elementen ändern, um ein Element zu entfernen oder irgendwo einzufügen. Allerdings wird ein Array nicht als vL gespeichert werden, weil mit dieser kein Zugriff auf Position X einfach möglich wäre. Man müsste sich dazu nämlich an der Kette entlanghangeln und mitzählen oder einen zusätzlichen Index aufbauen. Doch dann kommt man vom Regen in die Traufe, weil bei einer Änderung dieser Index umsortiert oder neu aufgebaut werden muss. VL scheiden also aus.
Weitere Möglichkeiten?
Lo!
-
Hallo,
Eine verkettete Liste wäre das Gebilde mit dem wenigsten Aufwand beim Umsortieren. [...] VL scheiden also aus.
Weitere Möglichkeiten?
Naja, ich weiß nicht, wie man so eine Array-Struktur am besten abbildet, aber sicher haben sich kluge Köpfe darüber eingehend Gedanken gemacht.
Wenn VL ausfallen und kein Index aufgebaut wird, hat man aber ein Probem beim Implementieren von Array.indexOf(). Es müsste ja dazu im schlimmsten Fall jedes einzelne Element untersucht werden.
Was den zusätzlichen Speicherplatz am Ende betrifft, so könnte ich mir vorstellen, dass man solchen auch am Anfang einräumt. Es gibt ja eigentlich keinen logischen Grund, das eine Ende der Wurst zu bevorzugen. shift, unshift, push und pop sind dann alle gleichwertig, und solange das Array nicht an die Grenzen stößt, sind diese auch ganz einfach zu implementieren. Wenn man dabei doch an die Grenzen stößt, muss das ganze Ding eben zuerst wieder in die Mitte verschoben werden. Das wäre m.E. eine recht effektive Lösung.
Gruß, Don P
-
Hi!
Was den zusätzlichen Speicherplatz am Ende betrifft, so könnte ich mir vorstellen, dass man solchen auch am Anfang einräumt. Es gibt ja eigentlich keinen logischen Grund, das eine Ende der Wurst zu bevorzugen. shift, unshift, push und pop sind dann alle gleichwertig,
Sieht so aus, da würde ich aber nicht kompromisslos mitgehen wollen. Meines Erachtens hat man deutlich öfter den Fall, dass ein (leeres) Array erstellt wird und dann Elemente angehängt werden. Ich gehe mal von PHP aus, da fallen mir auf Anhieb massig Anhäng-Fälle ein. shift und unshift hab ich zwar auch schon verwendet, aber wann und wo das war, hab ich nicht mehr in Erinnerung. Viele Fälle waren das jedenfalls nicht.
Ich denke, wir können diese Diskussion ad acta legen. Wir haben unsere Standpunkte soweit klargemacht und mehr wird dabei nicht rauskommen. Oder?
Lo!
-
Hallo,
Ich denke, wir können diese Diskussion ad acta legen. Wir haben unsere Standpunkte soweit klargemacht und mehr wird dabei nicht rauskommen. Oder?
Stimmt.
Gruß, Don P
-
-
-
-
-
-
-
-
-
Hallo,
Jetzt möchte ich, dass angezeigt wird, bei welchem Bild sich der User gerade befindet. Also z.b. "2/6" beim nächsten "3/6" ...
Dann könntest du einen Zähler verwalten, der bei jedem Wechsel eins hoch bzw. runterzählt.
Oder in deinem Array Objekte speichern statt einfacher Strings:var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ];Und zum Wechseln dann:
function nextImg(direction) { imgs.rotate(direction); document.getElementById("bg").src = imgs[0].pfad; }in meinem Array sind die Bilder nicht nummeriert und ich weiß nicht, wie ich das aktuelle Bild definieren muss.
Array-Elemente sind immer nummeriert, und zwar in deinem Fall von
imgs[0]bisimgs.length.
Aber das nützt dir hier nicht viel, weil du immer nur aufimgs[0]zugreifst. Daher scheint mir die Objekt-Lösung ganz praktisch. Beim Rotieren rotiert dann die Eigenschaft "nummer" gleich mit.Jetzt hast du mit
imgs[0].nummerimmer die aktuelle Bildnummer und mitimgs.lengthdie Gesamtzahl. Musst sie nur noch in deinem DIV jeweils anzeigen (SELF).Gruß, Don P
-
Oder in deinem Array Objekte speichern statt einfacher Strings:
var imgs = [
{pfad: 'grafics/1.jpg', nummer:1},
{pfad: 'grafics/2.jpg', nummer:2},
{pfad: 'grafics/3.jpg', nummer:3},
{pfad: 'grafics/4.jpg', nummer:4},
];Warum - das erste Array-Element hat den Index 0, das zweite 1 - die sind ohnehin eindeutig "nummeriert" - Der Index + 1 entspricht exakt dem zähler, diese Information einzufügen ist absolut unnütz.-
Hallo,
Warum - das erste Array-Element hat den Index 0, das zweite 1 - die sind ohnehin eindeutig "nummeriert" - Der Index + 1 entspricht exakt dem zähler, diese Information einzufügen ist absolut unnütz.
Du hast es nicht kapiert. Schau nochmal genau hin: Die Array-Elemente bleiben nicht an ihrem Ort im Array, sondern rotieren. Es wird immer imgs[0] angezeigt, auch wenn es das dritte Bild ist. Also nützt der Index 0 hier nichts. Und die Bilder werden natürlich ab 1 gezählt. Man kann einem Benutzer schlecht die Auskunft geben "Du betrachtest gerade Bild Nr. 0" wenn es in Wahrheit das erste Bild ist.
Gruß, Don P
-
Du hast es nicht kapiert. Schau nochmal genau hin: Die Array-Elemente bleiben nicht an ihrem Ort im Array, sondern rotieren.
Im aktuellen Script des OP ja - aber das muss nicht sein, wenn man stattdessen auf den Index des Arrays geht und durchzählt.
-
Hallo,
Im aktuellen Script des OP ja -
Eben, und zu diesem habe ich den Vorschlag gebracht mit der nummer-Eigenschaft. Ist also nicht "absolut unnütz".
aber das muss nicht sein, wenn man stattdessen auf den Index des Arrays geht und durchzählt.
Klar könnte man diesen 0815-Weg gehen, aber das muss nicht sein, denn man handelt sich damit mehr Aufwand ein als mit meinem Vorschlag.
Gruß, Don P
-
Hi!
aber das muss nicht sein, wenn man stattdessen auf den Index des Arrays geht und durchzählt.
Klar könnte man diesen 0815-Weg gehen, aber das muss nicht sein, denn man handelt sich damit mehr Aufwand ein als mit meinem Vorschlag.
Mir ist klar, dass du deine Lösung, die du für genial hältst, verteidigen willst und voreingenommen bist. Aber stell doch mal den Aufwand für das Rotieren und den für das Verwalten eines Zählers gegenüber. Du hast eine Rotierfunktion mit einem Fast-Einzeiler. Eine Zählerverwaltung kann man ebenfalls als Einzeiler schreiben und in einer Funktion kapseln. Der Aufwand ist also ungefähr gleich. Aber zu deinem Rotieren muss man zusätzlich noch eine Nummerierung plegen, die bei der Zählervariante schon dabei sind.
Lo!
-
Hallo,
Du hast eine Rotierfunktion mit einem Fast-Einzeiler. Eine Zählerverwaltung kann man ebenfalls als Einzeiler schreiben und in einer Funktion kapseln. Der Aufwand ist also ungefähr gleich.
Das glaube ich nicht. Zeig' doch mal, wie du dir das vorstellst.
Mit Hoch-/Runterzählen ist es ja nicht getan, man muss auch am Anfang/Ende den Zähler zurücksetzen für die gewünschte Endlosrotation und auch jeweils den Zählerstand abfragen beim Anzeigen eines anderen Bildes mit etwas wie
img.src = imgs[zählerstand];.
Dazu muss der Zählerstand irgendwie global sein bzw. man muss ihn von außerhalb der Anzeigefunktion holen. Das entfällt alles bei meiner Rotationsmethode.Aber zu deinem Rotieren muss man zusätzlich noch eine Nummerierung plegen, die bei der Zählervariante schon dabei sind.
Das ist doch nicht wirklich ein Zusatzaufwand, verglichen mit dem für einen Zähler. Die Bildnummer wird einmalig zugeordnet und basta.
Gruß, Don P
-
Hallo,
Du hast eine Rotierfunktion mit einem Fast-Einzeiler. Eine Zählerverwaltung kann man ebenfalls als Einzeiler schreiben und in einer Funktion kapseln. Der Aufwand ist also ungefähr gleich.
Das glaube ich nicht. Zeig' doch mal, wie du dir das vorstellst.
Mit Hoch-/Runterzählen ist es ja nicht getan, man muss auch am Anfang/Ende den Zähler zurücksetzen für die gewünschte Endlosrotation und auch jeweils den Zählerstand abfragen beim Anzeigen eines anderen Bildes mit etwas wie
img.src = imgs[zählerstand];.
Dazu muss der Zählerstand irgendwie global sein bzw. man muss ihn von außerhalb der Anzeigefunktion holen. Das entfällt alles bei meiner Rotationsmethode.Aber zu deinem Rotieren muss man zusätzlich noch eine Nummerierung plegen, die bei der Zählervariante schon dabei sind.
Das ist doch nicht wirklich ein Zusatzaufwand, verglichen mit dem für einen Zähler. Die Bildnummer wird einmalig zugeordnet und basta.
Beim Hinzufügen und Entfernen musst du sie aber neu nummerieren.
Bei vielen Bildern blähst du die Konfiguration unnötig auf.
Holst du die Bilder aus einer anderen Datenquelle - z.B. per XML, JSON oder aus dem DOM des HTML-Dokuments musst du redundate Daten übertragen oder verwalten.
Es sagt niemand, dass deine Lösung nicht funktioniert oder schlecht ist - es geht schlichtweg darum, dass sie gewisse schwächen enthält, die in diesem Form unüblich sind.
Es ist immer besser ein Problem mit vernünftiger Programmierung zu lösen, als ein Problem damit zu lösen, die Datenquelle zu manipulieren oder von der Datenquelle abhängig zu machen - auch wenn dies bedeutet, dass der Programmcode dadurch geringfügig länger wird.
Der Programmcode (bzw. das JavaScript) wird nur 1x geladen, die Bildwechslerinformationen aber ggf. auf jeder unterseite erneut und unterschiedlich - die zusätzlichen paar Zeichen pro Zeile können eben schnell mal massig unnötigen Overhead erzeugen.
-
Hallo,
Beim Hinzufügen und Entfernen musst du sie aber neu nummerieren.
Bei vielen Bildern blähst du die Konfiguration unnötig auf.
Holst du die Bilder aus einer anderen Datenquelle - z.B. per XML, JSON oder aus dem DOM des HTML-Dokuments musst du redundate Daten übertragen oder verwalten.
Ich sehe, es geht euch darum, dass die Rotationslösung nicht generell besser ist. Das habe ich ja auch nie behauptet. Man muss natürlich abwägen, was die Anforderungen sind.
Meine Lösung ist *hier*, in diesem konkreten Fall mit einer fixen Anzahl Bilder und festgelegten Dateinamen besser, meine ich jedenfalls. Das die Hardcodierung der Bilddateinamen und der Nummernzuordnung hier subobtimal ist, weiß ich auch. Das würde man besser mit einer allgemeinen Funktion und Parametern lösen.
Ich wollte aber beim konkreten Problem im OP helfen, keine Grundastzdiskussion über Programmiertechniken im Allgemeinen führen.
Der Programmcode (bzw. das JavaScript) wird nur 1x geladen,
Genau, auch das spricht für mine Lösung. Nach einmaliger Zuordnung muss man keine Berechnungen mit einem Zähler mehr durchführen.
die Bildwechslerinformationen aber ggf. auf jeder unterseite erneut und unterschiedlich - die zusätzlichen paar Zeichen pro Zeile können eben schnell mal massig unnötigen Overhead erzeugen.
Wenn die Anforderungen wachsen (wenn!), kann man wie gesagt auch eine Funktion schreiben, die die Zuordnung durchführt, statt zusätzlicher Zeilen mit hardcodierten Dateinamen und Nummern. Dabei entsteht kein Overhead.
Gruß, Don P
-
Ich sehe, es geht euch darum, dass die Rotationslösung nicht generell besser ist.
Richtig - für einen speziellen Anwendungsfall ist sie sicher perfekt, aber allgemein ist die andere herangehensweise vermutlich schlauer.
Man muss natürlich abwägen, was die Anforderungen sind.
Und die kennen wir nicht - das Ausgangsposting nennt die Rahmenanforderungen nicht wirklich.
Ich wollte aber beim konkreten Problem im OP helfen, keine Grundastzdiskussion über Programmiertechniken im Allgemeinen führen.
Darum wurde deine Lösung auch nicht als falsch abgetan - ich habe lediglich bezweifelt, dass es die vernünftigste Lösung ist.
Auch eine Grungsatzdiskussion zu Programmiertechniken kann dem OP helfen.
Der Programmcode (bzw. das JavaScript) wird nur 1x geladen,
Genau, auch das spricht für mine Lösung. Nach einmaliger Zuordnung muss man keine Berechnungen mit einem Zähler mehr durchführen.
Du hast mich falsch verstanden.
Mit Programmcode meinte ich die Logik - das Konfigurationsarray ist die Datenbasis und gehört nicht zur Programmlogik.
Wenn die Anforderungen wachsen (wenn!), kann man wie gesagt auch eine Funktion schreiben, die die Zuordnung durchführt, statt zusätzlicher Zeilen mit hardcodierten Dateinamen und Nummern. Dabei entsteht kein Overhead.
Sicher entsteht dabei overhead - und zwar in den Daten die Per HTTP übertragen werden
var imgs = [ 'grafics/1.jpg', 'grafics/2.jpg', 'grafics/3.jpg', 'grafics/4.jpg' ];ist nunmal kürzer als
var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ];Und wenn du das mit sagen wir 10 Grafiken auf 10 Unterseiten hast, realtiviert das die 1 bis 2 Zeilen mer Programmierlogik auf jeden Fall :)
-
Hi!
Ich sehe, es geht euch darum, dass die Rotationslösung nicht generell besser ist. Das habe ich ja auch nie behauptet. Man muss natürlich abwägen, was die Anforderungen sind.
In erster Linie war sie ja nicht schlecht. Die Idee hat was. Du solltest dich aber auch von Ideen trennen können, die sich dann doch nicht mehr als so ideal erweisen. Und das ergab sich, als neue Anforderungen hinzukamen, die nur mit mehr Aufwand zu lösen sind und noch weitere Nachteile mit sich bringen. Bei der herkömmlichen Variante ist das jedoch alles schon drin und muss bei Erweiterungen nicht angefasst werden.
Natürlich kann niemand in die Zukunft schauen und wissen, was sonst noch so für Anforderungen kommen. Wenn sich dann die Zählervariante als ungünstig erweist, muss man dann eben umdisponieren. Ob die Rotationsvariante ebenfalls betroffen wäre, ist auch ungewiss. Aber wenn selbst einfach vorhersehbare Fälle, wie Hinzufügen und Umsortieren mit Mehraufwand verbunden sind, ...
Ich wollte aber beim konkreten Problem im OP helfen, keine Grundastzdiskussion über Programmiertechniken im Allgemeinen führen.
Ja, das will fast jeder, aber (suboptimale) Lösungen muss man auch diskutieren dürfen.
Der Programmcode (bzw. das JavaScript) wird nur 1x geladen,
Genau, auch das spricht für mine Lösung. Nach einmaliger Zuordnung muss man keine Berechnungen mit einem Zähler mehr durchführen.
Ein bisschen Zählerberechnung stelle ich mir wesentlich einfacher vor, als Array-Elemente umherzuschieben. Die Elemente selbst werden zwar am selben Speicherplatz bleiben, aber die Referenz darauf muss in der Array-Verwaltung umsortiert werden, inklusive Nachrutschen aller anderen Referenzen.
Lo!
-
-
-
Hi!
Du hast eine Rotierfunktion mit einem Fast-Einzeiler. Eine Zählerverwaltung kann man ebenfalls als Einzeiler schreiben und in einer Funktion kapseln. Der Aufwand ist also ungefähr gleich.
Das glaube ich nicht. Zeig' doch mal, wie du dir das vorstellst.imgs.position = 0; imgs.move = function(delta) { this.position = (this.position + delta) % this.length; // -length < Ergebnis < length if (this.position < 0) // neg. Positionen ins Positive verschieben this.position += this.length; }Sind doch drei Zeilen geworden, als Einzeiler wird es durch Code-Wiederholung zu unübersichtlich. Wenn man dein rotate() ordentlich formatiert, kommt man auf 4 bis 5 Zeilen.
Mit Hoch-/Runterzählen ist es ja nicht getan, man muss auch am Anfang/Ende den Zähler zurücksetzen für die gewünschte Endlosrotation
Ausreißer werden durch die Modulo-Division eingefangen. Negative Werte werden extra korrigiert.
und auch jeweils den Zählerstand abfragen beim Anzeigen eines anderen Bildes mit etwas wie
img.src = imgs[zählerstand];.Das nimmt sich im Prinzip nichts von deiner Variante, da muss man immer das Element 0 ansprechen. Bei dir kommt noch pfad und nummer als zusätzliche Angabe hinzu. Für den Komfort kann man sich ja noch sowas hinzufügen:
imgs.current = function(delta) { return this[this.position]; }Dazu muss der Zählerstand irgendwie global sein bzw. man muss ihn von außerhalb der Anzeigefunktion holen. Das entfällt alles bei meiner Rotationsmethode.
Auf imgs.position zuzugreifen ist nicht aufwendiger.
Aber zu deinem Rotieren muss man zusätzlich noch eine Nummerierung plegen, die bei der Zählervariante schon dabei sind.
Das ist doch nicht wirklich ein Zusatzaufwand, verglichen mit dem für einen Zähler. Die Bildnummer wird einmalig zugeordnet und basta.Ja, bei jedem Bild extra hinzugefügt. Und bei einem eventuellen Umsortieren muss alles umnummeriert werden.
Lo!
-
Hallo,
imgs.position = 0;
imgs.move = function(delta) {
this.position = (this.position + delta) % this.length; // -length < Ergebnis < length
if (this.position < 0) // neg. Positionen ins Positive verschieben
this.position += this.length;
}Ok, so ähnlich habe ich mir das gedacht. Das ist schon eine ganz neue Funktion mit mehreren Berechnungen, die die vorhandene Funktion ersetzen muss. > Für den Komfort kann man sich ja noch sowas hinzufügen: > > ~~~javascript imgs.current = function(delta) { > return this[this.position]; > }Und noch drei Zeilen.
Dagegen ensteht bei meinem Vorschlag keine einzige Mehrzeile; das Ding ist mit einer kleinen Abwandlung von konkret 5 vorhandenen Zeilen erledigt, ohne jeden Umbau der Programmlogik.
Das Argument für den Zähler war doch hier immer, dass es einfacher sei. Unter "einfacher" stelle ich mir aber etwas anderes vor ;)
Ja, bei jedem Bild extra hinzugefügt. Und bei einem eventuellen Umsortieren muss alles umnummeriert werden.
Naja, dazu könnte ich auch noch eine kleine Extrafunktion liefern, die das Array kurz durchläuft und die Nummern neu vergibt nach dem Sortieren. Dateinamen und Nummern würde ich ohnehin nicht so hardcodieren, wie in dem Beispiel. Aber vermutlich sind es nur wenige Bilder, dann ist auch das noch vertretbar.
Gruß, Don P
-
Hi!
Ok, so ähnlich habe ich mir das gedacht. Das ist schon eine ganz neue Funktion mit mehreren Berechnungen, die die vorhandene Funktion ersetzen muss.
Was hast du denn erwartet? Deine Rotation ist auch eine Funktion mit mehreren Berechnungen.
Natürlich muss man immer abwägen, ob man ein bestehendes System komplett umbaut und wieviel Aufwand das ist, wenn sich herausstellt, dass eine neu gewünschte Funktionalität nur mit noch einem Flasch dran funktioniert, den man zukünftig immer wieder beachten muss.
Hier haben weder ich noch du den Zwang mit dem Ergebnis leben zu müssen, deswegen können wir ungeachtet des wirklichen Aufwands (den wir nicht kennen) die aus unserer Sicht bessere Lösung verteidigen. Was Heike daraus macht, muss sie selbst wissen. Ich würde ihr ungern eine Lösung empfehlen, die sie/man nicht einfach durchschaut und die mit ihren offensichtlich noch recht geringen Kenntnissen nicht selbst warten kann.
Für den Komfort kann man sich ja noch sowas hinzufügen:
Und noch drei Zeilen.Das dient dem Komfort! Man kann es auch weglassen. Dein ständiges imgs[0] ist auch nicht gerade schön und schon gar nicht einfach einleuchtend. Im Code steht zwar immer die Konstante 0, aber nach jeder Rotation ist Nummer 0 ein anderes Element. Bei der Variable position weiß man, dass deren Inhalt veränderlich ist. Deswegen nimmt man ja eine Variable.
Dagegen ensteht bei meinem Vorschlag keine einzige Mehrzeile; das Ding ist mit einer kleinen Abwandlung von konkret 5 vorhandenen Zeilen erledigt, ohne jeden Umbau der Programmlogik.
Das wird sich (vermutlich nicht mehr in diesem Thread) zeigen, was langfristig besser gewesen wäre. Der einmalige kleine Umbau oder die zu Fuß mitgeschleppte Nummerierung.
Das Argument für den Zähler war doch hier immer, dass es einfacher sei. Unter "einfacher" stelle ich mir aber etwas anderes vor ;)
Wenn du nur den momentaten Aufwand berücksichtigst, magst du Recht haben. Aber insgesamt und von Null angefangen sehe ich Vorteile beim Zähler.
Ja, bei jedem Bild extra hinzugefügt. Und bei einem eventuellen Umsortieren muss alles umnummeriert werden.
Naja, dazu könnte ich auch noch eine kleine Extrafunktion liefern, die das Array kurz durchläuft und die Nummern neu vergibt nach dem Sortieren.Warum fügst du die Nummern dann nicht gleich mit einer Schleife ein, statt sie von Hand im Code zu notieren? Mit Umsortieren meinte ich nicht eine Sortierfunktion im Code sondern das händische Umstellen des Arrays, weil eine generell andere Reihenfolge gewünscht ist.
Lo!
-
Hallo,
Das ist schon eine ganz neue Funktion mit mehreren Berechnungen, die die vorhandene Funktion ersetzen muss.
Was hast du denn erwartet? Deine Rotation ist auch eine Funktion mit mehreren Berechnungen.
Aber mit wenigen und viel leichter verständlich: Hinten eins abhacken und vorne drankleben oder vorne eins abhacken und hinten drankleben; das ist alles.
Ich würde ihr [Heike] ungern eine Lösung empfehlen, die sie/man nicht einfach durchschaut und die mit ihren offensichtlich noch recht geringen Kenntnissen nicht selbst warten kann.
Finde nicht, dass das Abhacken und Ankleben schwer zu druchschauen ist. Wenn man schon mit Arrays hantiert, sollte man wenigstens diese vier Standardmethoden kennen und verstehen. Einfacher geht's doch gar nicht.
Findest du Modulo-Berechnungen mit if < 0 -Workarounds usw. denn leichter verständlich?
Warum fügst du die Nummern dann nicht gleich mit einer Schleife ein, statt sie von Hand im Code zu notieren?
Weil das im OP schon vorgegeben ist und nicht das Problem von Heike. Ihr Problem ist ja nur die Ausgabe der Bildnummer. Ich bin doch hier nicht der Programmierknecht. Die fünf Zeilen entsprechend abzuändern ist schon Aufwand genug. Wie du schon sagst:
Was Heike daraus macht, muss sie selbst wissen.
Gruß, Don P
-
Hi!
Was hast du denn erwartet? Deine Rotation ist auch eine Funktion mit mehreren Berechnungen.
Aber mit wenigen und viel leichter verständlich: Hinten eins abhacken und vorne drankleben oder vorne eins abhacken und hinten drankleben; das ist alles.
Ich würde ihr [Heike] ungern eine Lösung empfehlen, die sie/man nicht einfach durchschaut und die mit ihren offensichtlich noch recht geringen Kenntnissen nicht selbst warten kann.
Finde nicht, dass das Abhacken und Ankleben schwer zu druchschauen ist. Wenn man schon mit Arrays hantiert, sollte man wenigstens diese vier Standardmethoden kennen und verstehen. Einfacher geht's doch gar nicht.Es geht nicht nur um diese eine Stelle sondern auch darum, wie es insgesamt aussieht. Und da musst du immer im Hinterkopf behalten, dass das Array jedes Mal anders aussieht. Beim Zähler bleibt der Inhalt dagegen stets konstant. imgs[0] ist immer das selbe Bild. Auch die anderen Array-Funktionen kannst du nicht wie gewohnt verwenden, denn du hast jetzt mit der Rotation eine neue Philosophie eingefügt, nach der sich möglichst alle anderen Codeteile richten sollten, wenn du nicht durch verschiedene Arbeitsweisen irgendwann den Überblick verlieren willst.
Findest du Modulo-Berechnungen mit if < 0 -Workarounds usw. denn leichter verständlich?
Nein, nicht im ersten Augenblick. Aber es galt, auch mit der Code-Länge dir gegenüber konkurrenzfähig zu bleiben :-) Meine ursprünglich geplante Einzeiler-Lösung mit Math.min() und .max() erwies sich dann doch nicht als geeignet, weil die nur begrenzt und nicht umbricht.
Man muss letztlich beides verstehen, das Rotationsprinzip und die Modulo-Rechnung. Wobei man Modulo-Rechnungen noch deutlich öfter begegnen wird als dem Rotationsprinzip. Der Nachteil an ihm ist auch, dass es wie die Modulo-Rechnung von außen sehr klein aussieht, aber im Gegensatz zu ihr, die immer gleich lang bleibt, wächst der im Hintergrund nötige Aufwand beim Umschichten mit jedem Element, das das Array größer wird. Bei den drei Werten ist der Unterschied zwar nicht spürbar, ...
Warum fügst du die Nummern dann nicht gleich mit einer Schleife ein, statt sie von Hand im Code zu notieren?
Weil das im OP schon vorgegeben ist und nicht das Problem von Heike. Ihr Problem ist ja nur die Ausgabe der Bildnummer. Ich bin doch hier nicht der Programmierknecht. Die fünf Zeilen entsprechend abzuändern ist schon Aufwand genug. Wie du schon sagst:
Was war denn da vorgegeben? Ein einfaches Array mit Strings als Elementen darin war da. Und dann kamst du und hast aus den Strings Objekte gemacht. Und zwar zu Fuß für jeden Wert einzeln. Das war dein Lösungsvorschlag, und er ist sowohl schnell erdacht als auch umgesetzt - bei den wenigen Werten. Aber je mehr Bilder es werden, desto aufwendiger wird es. Diese Folgewirkung wird dabei nicht berücksichtigt. Da bringt dann eine zweizeilige for-Schleife eine Einsparung in der Wartung (und auch in der Datenmenge, wenn der Array-Inhalt noch irgendwoher/-hin übertragen werden muss). Das jedoch zum Preis, dass das Array im Code betrachtet einfach aussieht, aber später dann doch komlexer anzusprechen ist.
for (var i=0; i < imgs.length; i++)
imgs[i] = {pfad: imgs[i]; nummer: i}Damit wäre das Problem der händischen Pflege der Nummern umgangen, aber merkst du was? Je einfacher man es sich an einer Stelle macht, desto komplexer wird die Sache insgesamt.
Lo!
-
[latex]Mae govannen![/latex]
Was war denn da vorgegeben? Ein einfaches Array mit Strings als Elementen darin war da. Und dann kamst du und hast aus den Strings Objekte gemacht. Und zwar zu Fuß für jeden Wert einzeln. Das war dein Lösungsvorschlag, und er ist sowohl schnell erdacht als auch umgesetzt - bei den wenigen Werten. Aber je mehr Bilder es werden, desto aufwendiger wird es. Diese Folgewirkung wird dabei nicht berücksichtigt.
Ebensowenig wie die Möglichkeit, die Reihenfolge im Array "mal eben" zu verändern. Bei einer expliziten Zuweisung im Objekt fängt man dann nämlich an, sämtliche Werte zu ändern.
Cü,
Kai
--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken in Richtung "Mess up the Web". (suit)
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?-
Hallo,
Ebensowenig wie die Möglichkeit, die Reihenfolge im Array "mal eben" zu verändern. Bei einer expliziten Zuweisung im Objekt fängt man dann nämlich an, sämtliche Werte zu ändern.
Es würde reichen, die Bilddateien mal eben umzubenennen, ohne jede Änderung am JS-Code :P
Und für das Ändern der Werte wurde ja hier ja auch schon eine einfache Funktion gepostet.Wie gesagt, als Universallösung für alle Fälle wurde die Array-Rotation von mir nicht angepriesen, sondern für den konkreten Fall und allgemeiner für relativ kleine Arrays, wenn die Reihenfolge und die Länge gleich bleiben, oder zumindest sich nicht dauerd ändern. Dann ist es wirklich einfacher, das Array zu rotieren, als eine Zählerverwaltung zu implementieren.
Die Rotationsmethode hat auch Nachteile bei langen Arrays, wenn man z.B. mal eben auf einen Schlag von Element 183 auf Element 1461 weiterscrollen will. Dann wäre es natürlich ein Unding, die Elemente einzeln umzuschichten...
Gruß, Don P
-
Hallo,
die Möglichkeit, die Reihenfolge im Array "mal eben" zu verändern. Bei einer expliziten Zuweisung im Objekt fängt man dann nämlich an, sämtliche Werte zu ändern.
Nicht sämtliche, einfach z.B. das:
var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ];umschreiben zu:
var imgs = [ {pfad: 'grafics/3.jpg', nummer:1}, {pfad: 'grafics/1.jpg', nummer:2}, {pfad: 'grafics/4.jpg', nummer:3}, {pfad: 'grafics/2.jpg', nummer:4}, ];Es müssen also nur die Dateinamen geändert werden. Für überschaubare Bild- Arrays und gerade für JS-Anfänger (um nicht zu sagen Unkundige) ist das doch wirklich super einfach.
Gruß, Don P
-
Hi!
Es müssen also nur die Dateinamen geändert werden. Für überschaubare Bild- Arrays und gerade für JS-Anfänger (um nicht zu sagen Unkundige) ist das doch wirklich super einfach.
In dem Fall bei diesen Dateinamen, die nur aus einer Ziffer bestehen, ist das zugegebenermaßen ein sehr geringer Aufwand. Aber was ist, wenn die Dateinamen an vielen Stellen unterschiedlich sind. Es ist dann einfacher, ganze Zeilen umzukopieren, als Namen zu ändern oder zu verschieben.
Bezogen auf den gezeigten Code scheinen deine Vorschläge recht einfache Lösungen zu bieten. Aber schon wenn man das Szenario ein klein wenig ändert, zeigen sich deutlich ein paar Nachteile. Ich will dir ja dein Prinzip nicht generell ausreden, aber hier ist offensichtlich nicht gerade ein Platz, an dem es glänzen kann. Immerhin kann man mit der automatischen Nummerierung das Umsortierproblem bei der Rotier-Lösung umgehen.
Lo!
-
Hallo,
Es müssen also nur die Dateinamen geändert werden. Für überschaubare Bild- Arrays und gerade für JS-Anfänger (um nicht zu sagen Unkundige) ist das doch wirklich super einfach.
In dem Fall bei diesen Dateinamen, die nur aus einer Ziffer bestehen, ist das zugegebenermaßen ein sehr geringer Aufwand.
Eben.
Aber was ist, wenn die Dateinamen an vielen Stellen unterschiedlich sind. Es ist dann einfacher, ganze Zeilen umzukopieren, als Namen zu ändern oder zu verschieben.
Aber sie sind nunmal nicht an vielen Stellen unterschiedlich. Und wenn das zum Problem werden könnte, kann man es ja auch einfach bleiben lassen, die Namen nachträglich so zu verunstalten, dass man sie händisch nicht mehr einfach ändern kann.
Bezogen auf den gezeigten Code scheinen deine Vorschläge recht einfache Lösungen zu bieten.
Sie scheinen nicht nur, sie tun's wirklich.
Aber schon wenn man das Szenario ein klein wenig ändert, zeigen sich deutlich ein paar Nachteile. Ich will dir ja dein Prinzip nicht generell ausreden, aber hier ist offensichtlich nicht gerade ein Platz, an dem es glänzen kann.
Aber wo denn dann? Ich finde gerade hier ist genau der richtige Platz. Bei der konkreten Frage in diesem Thread. Denn wenn man das Szenario ein kein wenig ändert...
Wieso wollen eigentlich alle immer das Szenario ändern? Aber halt - es sind ja nur alle außer der OPeuse ;)Immerhin kann man mit der automatischen Nummerierung das Umsortierproblem bei der Rotier-Lösung umgehen.
Das Umsortierproblem existiert doch gar nicht wirklich. Es ist nur ein Hirngespinst mit geändertem Szenario. Ich könnte selber x Szenarien nennen, bei denen meine Array-Rotation richtig schlecht abschneidet, aber was solls? Gerade hier schneidet es hervorragend ab. Ihr wollt das nur nicht wirklich anrekennen, gelle.
Gruß, Don P
-
Hi!
Aber [die Dateinamen] sind nunmal nicht an vielen Stellen unterschiedlich. Und wenn das zum Problem werden könnte, kann man es ja auch einfach bleiben lassen, die Namen nachträglich so zu verunstalten, dass man sie händisch nicht mehr einfach ändern kann.
Woher weißt du denn, wie die Namen wirklich sind? Vielleicht sind das nur des Beispiels wegen verkürzte Namen? Und woher willst du wissen, dass Archivleser, die diese Lösung für ihr Problem verwenden könnten, ebenfalls nur solche kurzen Namen haben?
Bezogen auf den gezeigten Code scheinen deine Vorschläge recht einfache Lösungen zu bieten.
Sie scheinen nicht nur, sie tun's wirklich.Wieso wollen eigentlich alle immer das Szenario ändern? Aber halt - es sind ja nur alle außer der OPeuse ;)
Sie ist offensichtlich Anfänger und weiß eventuell noch gar nicht, dass sich ihr Szenario im Laufe der Zeit noch ändern wird. Ich weiß das auch nicht mit Gewissheit, aber ich plane das schon mit ein. Meine Erfahrung zeigt, dass sich die Dinge ändern und wenig so bleibt, wie es derzeit ist.
Das Umsortierproblem existiert doch gar nicht wirklich. Es ist nur ein Hirngespinst mit geändertem Szenario. Ich könnte selber x Szenarien nennen, bei denen meine Array-Rotation richtig schlecht abschneidet, aber was solls? Gerade hier schneidet es hervorragend ab. Ihr wollt das nur nicht wirklich anrekennen, gelle.
Du möchtest diese Lösung nur auf dieses Beispiel betrachtet sehen. Als Programmierer bin ich bestrebt, Lösungen auch so zu gestalten, dass sie möglichst wiederverwendbar sind. Und in diesen potentiellen anderen Fällen sind die Rahmenbedingungen garantiert mehr oder weniger anders. Und damit es eben auch auf diese anderen Szenarien passt, darf die Lösung ruhig so gestaltet sein, dass sie da auch möglichst problemlos verwendet werden kann.
Lo!
-
Hallo,
Woher weißt du denn, wie die Namen wirklich sind?
Das rieche ich ;)
Vielleicht sind das nur des Beispiels wegen verkürzte Namen? Und woher willst du wissen, dass Archivleser, die diese Lösung für ihr Problem verwenden könnten, ebenfalls nur solche kurzen Namen haben?
Das weiß ich natürlich nicht. Aber die werden dann schnell merken, das diese Lösung für sie nicht wirklich optimal ist. Dann können sie ja sowas wie deine Funktion benutzen (enthält aber noch Fehler), um die Bildnummern automatisch zu vergeben, gerne auch als Methode des Bildarrays:
imgs.init = function(){ for (var i=0, l=this.length; i<l;) {this[i]={pfad:this[++i], nummer:i};} }Auch diese Lösung – obwohl für Anfänger weniger verständlich – scheint mir noch etwas geringer als die Verwaltung eines Zählers, ist aber schon grenzwertig. Je mehr Features man dranhängen will, umso besser schneidet letzlich die Zähler-Methode ab, da habt ihr sicher recht.
Du möchtest diese Lösung nur auf dieses Beispiel betrachtet sehen.
Richtig. Und für gleiche oder zumindest sehr ähnlich gelagerte Fälle.
Als Programmierer bin ich bestrebt, Lösungen auch so zu gestalten, dass sie möglichst wiederverwendbar sind. Und in diesen potentiellen anderen Fällen sind die Rahmenbedingungen garantiert mehr oder weniger anders. Und damit es eben auch auf diese anderen Szenarien passt, darf die Lösung ruhig so gestaltet sein, dass sie da auch möglichst problemlos verwendet werden kann.
Dazu sag' ich mal YAGNI.
Gruß, Don P
-
Hi!
Als Programmierer bin ich bestrebt, Lösungen auch so zu gestalten, dass sie möglichst wiederverwendbar sind. Und in diesen potentiellen anderen Fällen sind die Rahmenbedingungen garantiert mehr oder weniger anders. Und damit es eben auch auf diese anderen Szenarien passt, darf die Lösung ruhig so gestaltet sein, dass sie da auch möglichst problemlos verwendet werden kann.
Dazu sag' ich mal YAGNI.Ich verstehe unter YAGNI, dass man keine derzeit unnötigen Features einbauen soll. Jedoch "verbietet" mir dieses Prinzip nicht, die derzeit benötigten ohne Mehraufwand so einzubauen, dass Erweiterungen leicht möglich sind. Zudem sieht der Weg, den ich für diesen Fall propagiere, auch nicht vor, eine derzeit nicht notwendige Komplexität aufzubauen, um für die Zukunft gewappnet zu sein. Es ist nur das momentan notwendige vorhanden, aber so, dass es Erweiterungen für recht übliche Wünsche nicht blockiert.
Lo!
-
Hallo,
Dazu sag' ich mal YAGNI.
Ich verstehe unter YAGNI, dass man keine derzeit unnötigen Features einbauen soll. Jedoch "verbietet" mir dieses Prinzip nicht, die derzeit benötigten ohne Mehraufwand so einzubauen, dass Erweiterungen leicht möglich sind.
Doch, so wie ich es verstehe, wird genau das wird eigentlich "verboten", Zitat:
"Entgegen diesem Vorgehen [YAGNI] wird in der Praxis oft versucht Programme durch zusätzlichen oder allgemeineren (generischen) Code auf mögliche künftige Änderungsanforderungen vorzubereiten. [...]"Zudem sieht der Weg, den ich für diesen Fall propagiere, auch nicht vor, eine derzeit nicht notwendige Komplexität aufzubauen, um für die Zukunft gewappnet zu sein. Es ist nur das momentan notwendige vorhanden, aber so, dass es Erweiterungen für recht übliche Wünsche nicht blockiert.
In diesem Fall mag das stimmen, nur mein Weg hier zielt v.a. darauf ab, die gewünschte Funktionalität für Anfänger leichtverständlich und mit so wenig Änderungen wie möglich (am bestehenden Code) herzustellen. Deshalb habe ich z.B. auch den Missbrauch von Links und den Gebrauch von document.write (welches ich hasse) und von globalen Variablen nicht angemeckert und die Bildnummern manuell hardcodiert, statt sie mit einer generischen Funktion zu erzeugen (was ich persönlich auch besser finde). Nebenbei wird damit sogar ein bisschen in OO eingeführt, und zwar auf einfachste Art durch literale Notierung von Objekten.
Wenn die OPeuse allein mit euren Hinweisen ("nimm doch einfach einen Zähler") hätte zum Ziel kommen müssen, dann würde sie nach Wochen oder gar Monaten schließlich mit einem Fader-Framework aufwarten oder mit jQuery oder was immer, nur für das bisschen Zusatzfunktionalität zum bestehenden, soweit doch anscheinend zufriedenstellenden Feature...
Gruß, Don P
-
nur für das bisschen Zusatzfunktionalität zum bestehenden, soweit doch anscheinend zufriedenstellenden Feature...
Dem allgemeinen Verständnis hilft es aber wenig.
Auch ein CSS-Anfänger fängt immer mal gleich mit position:-absolute-Wüsten an. Mit Erfahrung kann man damit auch super Layouts bauen, dennoch wird meistens der Code-Drop und der umstieg zu einem float-basierenden Layout empfohlen - schlichtweg weil man hier weiß, dass man mit bestimmten herangehensweisen igendwann probleme haben wird.
Auch in diesem Fall ist es wichtig zu erwähnen, dass die aktuelle Variante nicht schlau ist, vor allem weil es an Logik mangelt. Zwar ist deine Lösung ausreichend für diese Problemstellung und auch am einfachsten einbaubar, aber langfristig als Lernbasis für weitere projekte dieser Art sicher nicht geeigent - bestenfalls als Blick über den Tellerrand um andere Möglichkeiten kennenzulernen.
From-Scratch würde ich diese Methode aber (auch wenn sie in sehr einfachen Umgebungen äußerst effizent ist) niemals empfehlen wollen.
-
Hallo,
Auch in diesem Fall ist es wichtig zu erwähnen, dass die aktuelle Variante nicht schlau ist, vor allem weil es an Logik mangelt.
Wo am meisten? Kannst du das mit der fehlenden Logik genauer erklären?
bestenfalls als Blick über den Tellerrand um andere Möglichkeiten kennenzulernen.
Nicht zuletzt dafür habe ich die Array-Rotation auch ursprünglich vorgeschlagen (Mai 2009).
Es ist mir schon klar, dass diese Lösung mindetens ungewöhnlich ist.
Aber sie ist einfach, kommt ohne Berechnungen aus (das halte ich für einen Vorteil), und ist inuitiv leicht verständlich:Wenn man vor einem Bilderrahmen (Bildschirm) sitzt, ein Bild betrachtet und dann vorwärts/rückwärts weitere Bilder endlos "durchschieben" will wie einen Filmstreifen, dann ist es doch intuitiv das naheliegendste, eben genau das im Code auch zu tun, und nicht etwa die Bilder erst durchzunummerieren und den Rahmen dann anhand der Nummer von einem Bild zum nächsten zu schleppen *kopfpatsch*. Letztres ist für mich erst mangelnde Logik.
Eine Nummerierung war hier zunächst mal absolut unnötig und verkompliziert die Sache nur. Später (also jetzt in diesem Thread) hat sich dann doch die Anforderung ergeben, die einzelnen Bilder zu benennen bzw. zu nummerieren, und da man schon den "Projektor" für den Filmstreifen fertig vorliegen hat, ist es für mich wiederum das naheliegendste, die zusätzliche Bennung bzw. Nummer einfach an die vorbeilaufenden Bilder zu heften, statt den ganzen Projektor umzubauen und doch noch anzufangen quasi den Bilderrahmen herumzuschieben...
Wäre die zusätzlich einzublendende Eigenschaft nicht eine Bildnummer, sondern z.B. Untertitel, so könnte meine Lösung auch das ohne Codeanpassung leisten, während bei einer zählerbasierten Anzeige z.B. ein weitres, paralleles Array nötig würde.
Gruß, Don P
-
Wo am meisten? Kannst du das mit der fehlenden Logik genauer erklären?
https://forum.selfhtml.org/?t=199371&m=1341504
Wäre die zusätzlich einzublendende Eigenschaft nicht eine Bildnummer, sondern z.B. Untertitel, so könnte meine Lösung auch das ohne Codeanpassung leisten, während bei einer zählerbasierten Anzeige z.B. ein weitres, paralleles Array nötig würde.
Wie schon erwähnt: ich würde mich allgemein Hüten, Informationen in Arrays abzulegen, wenn sie ohnehin in der Dokumentenstruktur abbildbar sind. Ein Untertitel könnte z.B. im title-Attribut eines mehrerere img-Elemente untergebracht sein, ein Konfigurationsarray fiele dann komplett werg.
-
Hallo,
Wo am meisten? Kannst du das mit der fehlenden Logik genauer erklären?
Ich glaube nicht, dass der Beitrag dazu gedacht war, mir Unlogik nachzuweisen. Jedenfalls ist er dazu nicht geeignet.
Ein Untertitel könnte z.B. im title-Attribut eines mehrerere img-Elemente untergebracht sein, ein Konfigurationsarray fiele dann komplett weg.
Nicht komplett. Irgendie muss ja eine Liste der anzuzeigenden Bilder angelegt werden. Dazu müsste man erst alle Bildelemente erzeugen und die title-Attribute vergeben. Die Rotationslösung würde damit ebensogut funktionieren wie jetzt mit dem Array aus Objekten: Die Objekte wären dann halt Bildobjekte und die Eigenschaft "nummer" würde man durch die title-Eigenschaft ersetzen. Es ist dann noch immer kein Zähler, keine Nummernberechnung und kein "Herumschleppen" des Bilderrahmens notwendig.
Gruß, Don P
-
Ich glaube nicht, dass der Beitrag dazu gedacht war, mir Unlogik nachzuweisen. Jedenfalls ist er dazu nicht geeignet.
Ansichtsssache, ich fand es sehr passend :)
Nicht komplett. Irgendie muss ja eine Liste der anzuzeigenden Bilder angelegt werden.
Ja, aber nicht in einer redundanten Datenstruktur "irgendwo anders".
Dazu müsste man erst alle Bildelemente erzeugen und die title-Attribute vergeben. Die Rotationslösung würde damit ebensogut funktionieren wie jetzt mit dem Array aus Objekten: Die Objekte wären dann halt Bildobjekte und die Eigenschaft "nummer" würde man durch die title-Eigenschaft ersetzen.
Nein, die Eigenschaft "Nummer" würde durch die Reihenfolge im DOM ebenfalls redundant sein.
Aber es ist schön zu sehen, wie beharrlich du bei deiner Lösung bleibst, selbst das Haus schon lichterloh in Flammen steht, sagst du "Nein, Feuerwehr brauch ich nicht." :)
-
Hallo,
Nein, die Eigenschaft "Nummer" würde durch die Reihenfolge im DOM ebenfalls redundant sein.
Aha, du würdest also die Bilder direkt als img-Elemente ins HTML schreiben, auf und ab durch den DOM-Baum iterieren und immer schön mitzählen? Die title-Attribute auch gleich direkt reinschreiben?
Was ist nun daran besser oder einfacher, als sie an einer Stelle (Array) zu definieren, wo die Daten quasi schon im JSON-Format vorliegen (könnte ja mal nützlich werden ;) ?
Das verstehe ich nicht wirklich. Und dann würdest du über die Zählerverwaltung in JS jeweils zwei Bildelemente im DOM per Klassenname CSSmäßig ein- und ausblenden?
Wäre das dann das klassische skalierbare Standardverfahren nach Schulbuch für alles und jedes? Sorry, aber ich fürchte, aus dir wird nie ein richtiger Rebell ;) und auch kein Forscher.
Aber es ist schön zu sehen, wie beharrlich du bei deiner Lösung bleibst, selbst das Haus schon lichterloh in Flammen steht, sagst du "Nein, Feuerwehr brauch ich nicht." :)
Du bist lustig :)
Wenn ich wenigstens sehen würde, dass es brennt. Aber ich erkenne weit und breit nicht die geringste Rauchfahne. Ich sehe nur Unbehagen gegen eine kleine, aber feine Lösung, weil hier anscheinend niemand den Mut hat, mal über den bekannten Tellerrand zu schauen oder gelegentlich Ballast abzuwerfen, den man halt gewohnheitsmäßig mit sich herumschleppt...Gruß, Don P
-
-
-
-
-
-
Hi!
Dazu sag' ich mal YAGNI.
Ich verstehe unter YAGNI, dass man keine derzeit unnötigen Features einbauen soll. Jedoch "verbietet" mir dieses Prinzip nicht, die derzeit benötigten ohne Mehraufwand so einzubauen, dass Erweiterungen leicht möglich sind.Doch, so wie ich es verstehe, wird genau das wird eigentlich "verboten", Zitat:
"Entgegen diesem Vorgehen [YAGNI] wird in der Praxis oft versucht Programme durch zusätzlichen oder allgemeineren (generischen) Code auf mögliche künftige Änderungsanforderungen vorzubereiten. [...]"Ich schrieb "ohne Mehraufwand", was mit dem "zusätzlichen" korrespondiert. Und nicht zu verallgemeinern heißt nicht im Gegenzug, überall Speziallösungen einzubauen, wenn mit gleichem Aufwand und Ergebnis eine generische, leicht erweiterbare Methode angewendet werden kann. Am Ende muss man mit dem Ergebnis (nicht nur für den Augenblick) leben können, egal ob es bestimmten Prinzipien ent- oder widerspricht.
[...] nur mein Weg hier zielt v.a. darauf ab, die gewünschte Funktionalität für Anfänger leichtverständlich und mit so wenig Änderungen wie möglich (am bestehenden Code) herzustellen. Deshalb habe ich [...] auch [...] nicht [diverse Vermeidenswertigkeiten] angemeckert [...]
Schon klar. Den Weg des geringsten Widerstandes gehen zu wollen ist verständlich, das versuche ich auch. Jedoch versuche ich dabei die Augen offen zu halten. Manchmal muss man Kraft aufwenden und/oder Althergebrachtes über Bord werfen, wenn neue Wege zwar relativ leicht bleiben, dafür aber immer länger werden. Je früher man eine ordentliche Lösung implementiert, desto weniger Aufwand muss man auf ungünstig gewachsene Strukturen Rücksicht nehmen. Insofern sehe ich es nicht als Problem an, zumindest auf Unzulänglichkeiten, mögliche Probleme oder (potentiell) bessere Lösungen hinzuweisen, auch wenn das Umstellungsaufwand bedeutet. Entweder zahlt er sich gleich oder später aus, oder der Rezipient lässt zwar dieses Projekt wie es ist, weiß es dann aber für das nächste besser. Ganz zu schweigen von Archivlesern, die ihren Lösungsweg erst noch vor sich haben.
Wenn die OPeuse allein mit euren Hinweisen ("nimm doch einfach einen Zähler") hätte zum Ziel kommen müssen, dann würde sie nach Wochen oder gar Monaten schließlich mit einem Fader-Framework aufwarten oder mit jQuery oder was immer, nur für das bisschen Zusatzfunktionalität zum bestehenden, soweit doch anscheinend zufriedenstellenden Feature...
Das wissen wir nicht, wir kennen ihre Pläne nicht. Aber jemandem, der die Grundlagen offensichtlich noch nicht gut genug kennt, ein komplexes Framework zu empfehlen, ist immer etwas riskant. Aber warum auch nicht, wenn Aufwand, Nutzen und Nebenwirkungen ein besseres Verhältnis zu ergeben versprechen als andere Lösungen?
Lo!
-
-
-
Hi!
[...] deine Funktion [...] (enthält aber noch Fehler) [...]
Einen sehe ich, sie nummeriert ab 0 und nicht ab 1, weil sie den Array-Index nimmt, der bei 0 beginnt. Da muss also bei nummer nur noch ein +1 eingefügt werden.
imgs.init = function(){
for (var i=0, l=this.length; i<l;) {this[i]={pfad:this[++i], nummer:i};}
}Das ist auch nicht richtig, weil das i beim Pfad pre-inkrementiert wird. Das führt dazu, dass immer der Pfad i+1 an die Stelle i gestellt wird. Dabei verschwindet Bild 0 und am Ende greift es ins Leere. Post-inkrementieren oder die Pre-Inkrementierung zum i von nummer verlagern, wären zwei Korrekturmöglichkeiten. Lo!-
Hallo,
[...] deine Funktion [...] (enthält aber noch Fehler) [...]
Einen sehe ich, sie nummeriert ab 0 und nicht ab 1, weil sie den Array-Index nimmt, der bei 0 beginnt. Da muss also bei nummer nur noch ein +1 eingefügt werden.
Ja, denke den meinte ich auch.
imgs.init = function(){
for (var i=0, l=this.length; i<l;) {this[i]={pfad:this[++i], nummer:i};}
}> > Das ist auch nicht richtig, weil das i beim Pfad pre-inkrementiert wird. [...] > Post-inkrementieren oder die Pre-Inkrementierung zum i von nummer verlagern, wären zwei Korrekturmöglichkeiten. Ach ja, so hab' ich den Fehler nur verschlimmbessert, also dann endgültig so, nur für's Archiv: ~~~javascript imgs.init = function(){ for (var i=0, l=this.length; i<l;) {this[i]={pfad:this[i], nummer:++i};} }Gruß, Don P
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Hallo,
wenn man stattdessen auf den Index des Arrays geht und durchzählt.
Also nochmal deutlicher:
Es handelt sich immerhin um eine Endlos-Rotation der Bilder. Mit einem Zähler für den Index muss man nicht nur eine mehr oder weniger globale Variable einführen und verwalten für dem aktuellen Zählerstand, sondern auch zusätzlich dafür sorgen, dass sie beim Überschreiten der Arraygrenzen wieder auf 0 zurückgesetzt wird.
Mit der Rotiermethode entfällt das alles. Der Code ist schlank, übersichtlich und zuverlässig. Was will man mehr?
Gruß, Don P
-
Mit der Rotiermethode entfällt das alles. Der Code ist schlank, übersichtlich und zuverlässig. Was will man mehr?
Die Zuordnung oder das gezielte Ansprechen eines Elements wird aber erschwert - darum ist die Rotationsmethode hier imho schlecht.
Was ist, wenn du explizit das 4. Bild haben willst?
-
Hallo,
Die Zuordnung oder das gezielte Ansprechen eines Elements wird aber erschwert - darum ist die Rotationsmethode hier imho schlecht.
Was ist, wenn du explizit das 4. Bild haben willst?
Das will doch niemand. Hier geht es darum, genau eins vor oder zurückzublättern und das endlos.
Wenn Sprünge möglich sein sollen, kann man die Rotierfunktion leicht so umschreiben, dass sie eine Zahl als Parameter entgegennimmt, also z.B. -2 für zwei zurück oder +10 für 10 vorwärts.
Aber wie gesagt, das ist hier gar nicht gefragt. Schreibst du denn den Code immer so, dass alle möglichen denkbaren Eventualitäten abgedeckt sind, nach denen aktuell gar niemand fragt? Das ist IMHO nicht sinnvoll.
Gruß, Don P
-
Hallo,
Die Zuordnung oder das gezielte Ansprechen eines Elements wird aber erschwert - darum ist die Rotationsmethode hier imho schlecht.
Was ist, wenn du explizit das 4. Bild haben willst?
Das will doch niemand. Hier geht es darum, genau eins vor oder zurückzublättern und das endlos.
Tellerrand:
Anstatt 1/6 usw soll ein Pagebrowser im stil von [*1*] [2] [3] [4] [5] [6] drunter stehen.
Wenn Sprünge möglich sein sollen, kann man die Rotierfunktion leicht so umschreiben, dass sie eine Zahl als Parameter entgegennimmt, also z.B. -2 für zwei zurück oder +10 für 10 vorwärts.
Das habe ich nicht bestrittent.
Schreibst du denn den Code immer so, dass alle möglichen denkbaren Eventualitäten abgedeckt sind, nach denen aktuell gar niemand fragt?
Nicht alle denkbaren, aber ich plane künftige erweiterungen die nicht ungewöhnlich sind gleich mit ins design ein.
Das ist IMHO nicht sinnvoll.
Du arbeitest nicht viel mit Kunden zusammen oder? :)
Du musst riechen, was der Kunde in einem halben Jahr haben will - damit sparst du dir und deinem Kunden Zeit und Geld - und den Frust, dass du ggf. den kompletten Code wegschmeissen musst.
-
Hallo,
Nicht alle denkbaren, aber ich plane künftige erweiterungen die nicht ungewöhnlich sind gleich mit ins design ein.
Das ist IMHO nicht sinnvoll.
Du arbeitest nicht viel mit Kunden zusammen oder? :)
Doch, und zwar extrem, Stichwort XP, wie auch gerade hier in diesem Thread, obwohl es hier kein Kunde ist, der etwas nachfragt.
Ich glaube nicht, dass es eine große Hilfe wäre, jetzt den halben Code umzuschreiben, weil er so, wie er jetzt ist, dann evtl. nicht das leisten kann, was möglicherweise sowieso nie gefragt ist ;)
Schnelle und unkomplizierte Hilfe ist hier angesagt, gerade in diesem Forum. Es sei denn, der präsentierte Code enthält wirklich grobe Schnitzer, dann muss man natürlich darauf hinweisen. Aber das ist hier doch gar nicht Fall. Jetzt einen Zähler einzuführen, wäre sicher der größere Umbau mit sehr zweifelhaftem Nutzen.
Du musst riechen, was der Kunde in einem halben Jahr haben will - damit sparst du dir und deinem Kunden Zeit und Geld - und den Frust, dass du ggf. den kompletten Code wegschmeissen musst.
Sowas wird natürlich immer vorab besprochen. Der Kunde erfährt natürlich schon, dass eine bestimmte, schnelle Umsetzung evtl. in Zukunft problematisch werden kann, wenn andere Anfordungen wichtig werden sollten.
Gruß, Don P
-
-
-
-
Hallo Don,
Mit der Rotiermethode entfällt das alles. Der Code ist schlank, übersichtlich und zuverlässig. Was will man mehr?
ich möchte deinen Algorithmus mit folgendem Beispiel kommentieren:
Letzter Schultag, Abschlusszeugnisausgabe, alle Schüler haben sich auf der Bühne in der Aula versammelt. Der Schulleiter geht die Reihe der Schüler ab und überreicht jedem sein Zeugnis ...
Aber halt, das ist ja für den Schulleiter viel zu aufwendig. Er bleibt am rechten Rand der Bühne stehen, gibt dem vor ihm stehenden Schüler das Zeugnis, dieser rennt dann ans Ende der Schlange und alle anderen Rücken eins auf. Da der Schulleiter nicht zählen kann, er aber wissen will, wie viele Schüler noch kommen, bekommt jeder Schüler unter das Namensschild noch eine Startnummer geheftet.
Gruß, Jürgen
PS Wegen der leichteren Lesbarkeit habe ich hier die männliche Form benutzt. Selbstverständlich gibt es auch Schülerinnen und Schulleiterinnen.
-
Da der Schulleiter nicht zählen kann, er aber wissen will, wie viele Schüler noch kommen, bekommt jeder Schüler unter das Namensschild noch eine Startnummer geheftet.
YMMD
-
Hallo Jürgen,
Super! So ähnlich ist es. Der Direktor ist nämlich alt, faul und/oder gehbehindert oder sitzt einfach auf einem Thron. Der Sportlehrer hat vorher das Aufrücken mit den Schülern definiert und der Kunstlehrer hat jeden Schüler seine Startnummer basteln lassen und das korrekte Anheften überwacht.
Außerdem müssen de facto sogar mehrere Dokumente verteilt werden, d.h. es gibt mehr als einen Durchlauf, der zudem auch jederzeit die Richtung ändern kann. Man wird doch nicht vom alten Direktor verlangen, dass er vom Ende der Schlange wieder an den Anfang zurückspurtet und die Verteilung fortsetzt, nein: Die Schüler sollen gefälligst der Reihe nach vor seiner Exzellenz erscheinen... :)
Gruß, Don P
-
Hi!
Super! So ähnlich ist es. Der Direktor ist nämlich alt, faul und/oder gehbehindert oder sitzt einfach auf einem Thron.
Was spricht dagegen, dass er sich einen Assistenen nimmt, der das durchlaufen übernimmt? Den hat er ja aufgrund seiner Gehbehinderung auch schon für den täglichen Bedarf.
Die Schüler sollen gefälligst der Reihe nach vor seiner Exzellenz erscheinen... :)
Jawohl, Eure Exzellenz, solche Fälle gibt es auch.
:-)Lo!
-
Hallo,
Super! So ähnlich ist es. Der Direktor ist nämlich alt, faul und/oder gehbehindert oder sitzt einfach auf einem Thron.
Was spricht dagegen, dass er sich einen Assistenen nimmt, der das durchlaufen übernimmt? Den hat er ja aufgrund seiner Gehbehinderung auch schon für den täglichen Bedarf.
Den hat er nicht, denn er ist ja beamtet und der Staat zahlt solch aufwändigen Luxus nicht. Der Direx hat also nur einen batteriebetriebenen Rollstuhl und eine behindertengerechte Schule/Wohnung zur Verfügung. Die Batterien schont er natürlich.
Jawohl, Eure Exzellenz, solche Fälle gibt es auch.
:-)Bravo. Er darf sich jetzt entfernen. *wegwink*
Don P
-
-
-
-
-
-
-
-
So, ich hab das jetzt mal mit dem Vorschlag von Don P. ausprobiert, da ich jetzt nicht meinen gesamten Code über Bord werfen wollte.
Allerdings wird mir der Zähler leider nicht angezeigt.
Was ist falsch?<header>
<script type="text/javascript"> var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ]; imgs.rotate = function (direction) { if (direction > 0) { this.push(this.shift()); } else if (direction < 0) { this.unshift(this.pop()); } } function nextImg(direction) { imgs.rotate(direction); document.getElementById("bg").src = imgs[0].pfad; } </script></header
----------------
<body>~~~javascript <div class="navibilder" style="width:40%;"><script type="text/javascript">
<!--
document.write ('<p><a href="javascript:nextImg(- 1)"> < prev</a> | <a href="javascript:nextImg(1)">next > </a></p>');
// -->document.write(document.imgs[0].nummer);
document.write("/" + document.imgs.length);</script> </div></body>-
Hi!
So, ich hab das jetzt mal mit dem Vorschlag von Don P. ausprobiert, da ich jetzt nicht meinen gesamten Code über Bord werfen wollte.
Allerdings wird mir der Zähler leider nicht angezeigt.Was wird dann angezeigt? Die Fehlerkonsole des Browser bleibt auch stumm?
Was ist falsch?
Falsch ist, dass du dir anscheinend keine Gedanken machst, wie der übernommene Code arbeitet.
<body> <div class="navibilder" style="width:40%;"><script type="text/javascript">
<!--Den Inhalt von <script> auszukommentieren ist seit dem Aussterben urzeitlicher Browser nicht mehr notwendig. (Und damit meine ich nicht den IE6, sondern noch wesentlich ältere Generationen.)
document.write ('<p><a href="javascript:nextImg(- 1)"> < prev</a> | <a href="javascript:nextImg(1)">next > </a></p>');
Mit -1 erreichst du zwar die vorhergehende Position, indem du das Array um eine Runde rotieren lässt. Was aber, wenn du nun eine Runde in die andere Richtung drehst? Dann stehst du wieder an der selben Stelle. Weiterhin sind mindestens die < als < zu notieren, die keine Tags einleiten.
document.write(document.imgs[0].nummer);
document.write("/" + document.imgs.length);</script> </div>Globale Variablen werden nicht in document eingehängt.
Lo!
-
ok, ein neuer Versuch.
Ich habe versucht die Dinge zu korrigieren, jetzt zeigt er mir zwar Zahlen an, aber immer nur "1/4". Klicke ich ein Bild weiter, bleibt es beim "1/4", obwohl es eigentlich "2/4" heißen müsste.
Was muss ich noch ändern?
Die Fehlerkonsole sagt gar nichts.Die Navigation funktioniert in beide Richtungen tadellos, nur ändert sich die Nummer nicht.
<script type="text/javascript"> var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ]; imgs.rotate = function (direction) { if (direction > 0) { this.push(this.shift()); } else if (direction < 0) { this.unshift(this.pop()); } } function nextImg(direction) { imgs.rotate(direction); document.getElementById("bg").src = imgs[0].pfad; } </script>---
<div><img id="bg" src="grafics/1.jpg"></div> <div><script type="text/javascript"> document.write ('<p><a href="javascript:nextImg(- 1)"> prev<\/a> | <a href="javascript:nextImg(1)">next <\/a><\/p>'); document.write(imgs[0].nummer); document.write("/" + imgs.length);</script> </div>document.write ('<p><a href="javascript:nextImg(- 1)"> < prev<\/a> | <a href="javascript:nextImg(1)">next > <\/a><\/p>');Mit -1 erreichst du zwar die vorhergehende Position, indem du das Array um eine Runde rotieren lässt. Was aber, wenn du nun eine Runde in die andere Richtung drehst? Dann stehst du wieder an der selben Stelle.
Das versteh ich nicht so ganz...
-
Ich habe versucht die Dinge zu korrigieren, jetzt zeigt er mir zwar Zahlen an, aber immer nur "1/4". Klicke ich ein Bild weiter, bleibt es beim "1/4", obwohl es eigentlich "2/4" heißen müsste.
Nein, denn du änderst diesen Wert niemals. Du setzt dieses 1x statisch per document.write am Anfang - warum sollte sich der Wert später ändern?
Was muss ich noch ändern?
Füge eine Routine hinzu, die dafür sorgt dass dein Zähler geändert wird - in der nextImg-Funktion wäre das sinnvoll.
Die Fehlerkonsole sagt gar nichts.
Dein Code scheint auch frei von technischen Fehlern zu sein.
Die Navigation funktioniert in beide Richtungen tadellos, nur ändert sich die Nummer nicht.
Ja, weil du hierfür eben keine Programmlogik existiert - und "einfach so" passiert das natürlich nicht.
-
Füge eine Routine hinzu, die dafür sorgt dass dein Zähler geändert wird - in der nextImg-Funktion wäre das sinnvoll.
Sorry, ich dachte nicht dass es (für mich) so kompliziert sein würde.
Kannst du mir bei der Erstellung der Routine helfen?
Hab schon nach Beispielen im Netz gesucht, um den Code zu verstehen und auf meinen zu übertragen. Leider ist der Code, den ich verwende aber anscheinend doch ziemlich anders als die "herkömmlichen".Wäre echt nett.
Ein Link, oder Beispiel würde mir sicher auch schon weiterhelfen. Danke!Heike
-
Liebe Heike,
Sorry, ich dachte nicht dass es (für mich) so kompliziert sein würde.
es ist noch kein Meister vom Himmel gefallen.
Hab schon nach Beispielen im Netz gesucht, um den Code zu verstehen und auf meinen zu übertragen. Leider ist der Code, den ich verwende aber anscheinend doch ziemlich anders als die "herkömmlichen".
Du willst verstehen? Das kann ich nur unterstützen. Zum Verstehen haben wir hier einen Artikel, der sich mit dem Schreiben eines JavaScripts beschäftigt. Als Lerngegenstand ist da sogar ein Bilderwechsler drinnen: Fader-Framework - kleiner Lehrgang zum vernünftigen Schreiben eines JavaScripts
Habe gerade versucht den Link zu prüfen... aber leider scheint es mit dem Server ein Problem zu geben.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:) -
Hi!
Kannst du mir bei der Erstellung der Routine helfen?
Erst einman müssen wir herausarbeiten, was konkret das Problem ist. Bestandsaufnahme: Wenn die Websiete geladen wird, arbeitet dein document.write() problemlos, denn zu dem Zeitpunkt wird das Dokument ja auch gerade (im Browser) erstellt. Das kann man zwar so ändern, dass man stattdessen eine DOM-Manipulation vornimmt, aber lassen wir das erst einmal. DOM-Manipulation wirst du gleich kennenlernen, du kannst das dann immer noch ändern, wenn du willst.
Nun ist das Dokument fertig im Browser geladen und was passiert? Jemand macht einen Mausklick auf einem Element. Hast du da einen Ereignishandler (onclick) installiert, der dieses Ereignis abfängt? Der müsste nun per DOM-Manipulation alle Elemente ändern, die sich ändern sollen. Das angezeigte Bild muss ein anderes werden und die Nummer im DIV ebenfalls. Wo konkret hakt es da oder welches Wissen fehlt dir noch, um das so zu erstellen?
Lo!
-
Hallo,
Füge eine Routine hinzu, die dafür sorgt dass dein Zähler geändert wird - in der nextImg-Funktion wäre das sinnvoll.
Hab schon nach Beispielen im Netz gesucht, um den Code zu verstehen und auf meinen zu übertragen. Leider ist der Code, den ich verwende aber anscheinend doch ziemlich anders als die "herkömmlichen".
Klar, er ist ja auch von mir :P
Durch die Funktion nextImg() landet bei Klick der nächste oder vorhergehende Bildname an erster Position im Array (jetzt imgs[0].pfad) und das Bild wird durch die Zuweisung ...
.src=... dann angezeigt.Was ein Array (siehe Array) ist, weißt du hoffentlich.
Die zugehörige Bildnummer, die jetzt immer in
imgs[0].nummergespeichert ist, liegt dort aber immer nur faul rum, denn niemand liest sie und schreibt sie ins DIV, was du doch bei jedem Klick haben willst. Also musst du die Funktion nextImg() so erweitern, dass sie das für dich tut.Dazu muss die Funktion das DIV erst mal kennen bzw. finden (siehe getElementById), und dann eben die Bildnummer lang=javascript]imgs[0].nummer[/code] und die Gesamtzahl der Bilder lang=javascript]imgs.length[/code] dort reinschreiben (siehe innerHTML)...
Gruß, Don P
-
Schonmal vielen Dank für die ausführliche Hilfe! Ein Traum!
So langsam kapier ichs glaub ich.Ist es so besser? (Funktioniert noch nicht, aber vielleicht bin ich ja schon näher dran...)
var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ]; imgs.rotate = function (direction) { if (direction > 0) { this.push(this.shift()); } else if (direction < 0) { this.unshift(this.pop()); } } function nextImg(direction) { imgs.rotate(direction); document.getElementById("bg").src = imgs[0].pfad; document.getElementById("aktuell").innerHTML = "<p>imgs[0].nummer</p>"; document.getElementById("alle").innerHTML = "<p>imgs.length</p>"; } ----------- <div class="navibilder"><script type="text/javascript"> document.write ('<p><a href="javascript:nextImg(- 1)"> < prev<\/a> | <a href="javascript:nextImg(1)">next ><\/a><\/p>');</script> </div> <div id="aktuell"></div> <div id="alle"></div> <div><img id="bg" src="grafics/1.jpg"></div>-
So langsam kapier ichs glaub ich.
Sieht danach aus, ja.
Ist es so besser? (Funktioniert noch nicht, aber vielleicht bin ich ja schon näher dran...)
Ja, du bist schon nahe dran - ggf. sollest du dich nochmal damit beschäftigen, wie Stringverkettung in JavaScript funktioniert.
document.getElementById("alle").innerHTML = "<p>imgs.length</p>";
Das scheint übrigens überflüssig zu sein, das war vorher besser gelöst - es ist nicht notwendig, diesen Wert immer wieder neu zu setzen, wenn sich die Gesamtzahl später nicht mehr ändert. Den kannst du bereits am Anfang setzen.
-
So langsam kapier ichs glaub ich.
Sieht danach aus, ja.
danke, das macht mir Mut. ;-)
Ist es so besser? (Funktioniert noch nicht, aber vielleicht bin ich ja schon näher dran...)
Ja, du bist schon nahe dran - ggf. sollest du dich nochmal damit beschäftigen, wie Stringverkettung in JavaScript funktioniert.
ggf.? Heißt dass, mein Code ist unsauber?
document.getElementById("alle").innerHTML = "<p>imgs.length</p>";Das scheint übrigens überflüssig zu sein, das war vorher besser gelöst - es ist nicht notwendig, diesen Wert immer wieder neu zu setzen, wenn sich die Gesamtzahl später nicht mehr ändert. Den kannst du bereits am Anfang setzen.
d.h. ich mach einfach das
document.write(imgs.length);an den punkt im body, wo ich es haben will und kann mir dasdocument.getElementById("alle").innerHTML = "<p>imgs.length</p>";im header sparen?Und woran liegt es, dass es noch nicht klappt? Welche Zeilen sind fehlerhaft codiert?
-
Es funktioniert!
Ich hab einfach die .innerHtml-Zeile korrigiert:
document.getElementById("aktuell").innerHTML = imgs[0].nummer;und schon gings!
Jetz hab ich nur noch ein Problem:
Er zeigt mir beim ersten Bild keine Zahl an, erst ab dem 2. danach aber alle richtig, auch die 1. Also erst, wenn ich einmal geklickt habe Woran liegt das?(Danke danke danke!)
-
Er zeigt mir beim ersten Bild keine Zahl an, erst ab dem 2. danach aber alle richtig, auch die 1. Also erst, wenn ich einmal geklickt habe Woran liegt das?
Das ist das, was ich bereits schrieb: die Gesamtzahl musst du natürlich am Anfang bereits setzen, später ändern brauchst du sie aber nicht mehr.
-
Er zeigt mir beim ersten Bild keine Zahl an, erst ab dem 2. danach aber alle richtig, auch die 1. Also erst, wenn ich einmal geklickt habe Woran liegt das?
Das ist das, was ich bereits schrieb: die Gesamtzahl musst du natürlich am Anfang bereits setzen, später ändern brauchst du sie aber nicht mehr.
Die Gesamtanzahl der Bilder erscheint immer. Aber der variable Zähler, mit dem aktuellen Bild erscheint erst ab dem ersten Klick.
Also steht beim ersten Aufrufen der Seite " /4". Sobald einmal ein Bildwechsel stattgefunden hat, steht korrekt "2/4", "1/4" (also auch die 1 ist dann richtig! Nur beim ersten Aufrufen fehlt die)-
Gelöst!
Ich bedanke mich hiermit ganz herzlich bei Don P. und suit!!!
Ihr wart echt geduldig und habt super erklärt.Was kleiner Erfolgserlebnisse so ausmachen... ;-)
Ich hab jetzt einfach in den Paragraf eine 1 geschrieben und die wird beim durchklicken mit der aktuellen Zahl ersetzt.
Funktioniert also alles bestens!-
Funktioniert also alles bestens!
Das sicher, aber einfacher und logischer ist es mit folgendem Vorschlag - vor allem weil der Code übersichtlicher und kürzer wird:
-
-
Die Gesamtanzahl der Bilder erscheint immer. Aber der variable Zähler, mit dem aktuellen Bild erscheint erst ab dem ersten Klick.
Und der ist beim ersten Bild immer auf 1, also kannst du diese 1 auch gleich mal beim Laden der Seite präventiv setzen.
Also steht beim ersten Aufrufen der Seite " /4". Sobald einmal ein Bildwechsel stattgefunden hat, steht korrekt "2/4", "1/4" (also auch die 1 ist dann richtig! Nur beim ersten Aufrufen fehlt die)
Schon klar ;)
All das sind keine Dinge die sich Programmiertechnisch schwierig lösen - bei dir scheitert es vermutlich einfach nur am logischen Verständnis wann was genau passiert.
Eben z.B. dass deine Funktion erst dann werte Erzeugen kann, wenn sie aufgerufen wird.
Aus diesem Grund ist dieser Mischbetrieb mit document.write und innerHTML etwas uncool - ich würde auf das document.write gänzlich verzichten und die nextImg-Funktion 1x zu beginn mit offset 0 aufrufen. Aus logischen Gründen sollte man sie aber ggf. umbenennen.
-
-
-
-
ggf.? Heißt dass, mein Code ist unsauber?
Nein, damit war "logisch Fehlerhaft" gemeint :)
-
-
-
-
-
-
-
Hallo,
Hab schon nach Beispielen im Netz gesucht, um den Code zu verstehen und auf meinen zu übertragen.
Anscheinend verstehst du auch "deinen" kein bisschen.
Wo hast du z.B. das HTML-Element <header> her? Wirf es dahin zurück, wo du es gefunden hast, es taugt nichts.Die Navigation funktioniert in beide Richtungen tadellos, nur ändert sich die Nummer nicht.
Natürlich nicht, weil auch nirgends im Script angegeben ist, dass sie sich bei Klick ändern soll. Da du anscheinend wirklich überhaupt keinen Plan hast und eigentlich schon fast am Ziel bist, will ich mal eine Ausnahme machen, und dir den Rest auch noch posten:
<script type="text/javascript"> var imgs = [ {pfad: 'grafics/1.jpg', nummer:1}, {pfad: 'grafics/2.jpg', nummer:2}, {pfad: 'grafics/3.jpg', nummer:3}, {pfad: 'grafics/4.jpg', nummer:4}, ]; imgs.rotate = function (direction) { if (direction > 0) { this.push(this.shift()); } else if (direction < 0) { this.unshift(this.pop()); } } function nextImg(direction) { imgs.rotate(direction); document.getElementById("bg").src = imgs[0].pfad; document.getElementById("bildNr").innerHTML = imgs[0].nummer + '/' + imgs.length; // Neue Zeile } </script>---
<div><img id="bg" src="grafics/1.jpg"></div> <div id="bildNr"> <!-- Geänderte Zeile --> <script type="text/javascript"> [code lang=javascript] document.write ('<p><a href="javascript:nextImg(- 1)"> prev<\/a> | <a href="javascript:nextImg(1)">next <\/a><\/p>'); document.write(imgs[0].nummer); document.write("/" + imgs.length); ~~~ </script> </div>[/code] Ist zwar von mir nicht getestet, aber verstehst du, was die Unterschiede zu deinem Code jetzt im einzelnen bewirken (sollen)? Viel Spass, Don P
-
-
-
-