gruss Felix,
Ich muss gestehen, beim ersten Überfliegen Deines Codes bin ich
etwas überfordert.
schau mal auf die anzahl meiner nachtraeglich hinterhergeworfenen
korrekturen - ich war es offensichtlich auch ... ueberfordert.
Offensichtlich ist Dein Ansatz wesentlich umfassender, als der
meine.
das denke ich nicht, der abstraktionsgrad fuer die gesamtanwendung
mag zwar hoch erscheinen, ist es aber keineswegs und zahlt sich in
dem moment aus, wo es darum geht, alle anderen features wie "autorun",
"random play" usw. parametrisiert zu implementieren. bei mir ist
das ueberblenden z.b. *nur* ein abfallprodukt, welches mit maximal
4 zeilen mehr code zu buche schlaegt (ja natuerlich nur, wenn ich
[YAHOO.util.Anim] oder mein eigenes [DHTMLOpacityObject] verwende).
generell halte ich Deinen ansatz zum ueberblenden fuer zu kompliziert,
denn ein einziges zusaetzliches bild, welches als fadeout-blende vor
dem jeweils anzuzeigenden bild liegt, ist alles, was diesen effekt
ausmacht.
fazit: pro slideshow wird genau ein [HTMLImageElement] benoetigt;
mit ueberblendung braucht man genau zwei von dieser sorte.
Außerdem richtet sich Dein Ansatz an Profis, während ich eher an
den unerfahrenen JavaScript Neuling dachte, der vielleicht schon
eine kleine Funktion selbst geschrieben hat, und mit den wesentlichsten
Grundstrukturen (wie z.B. if - Verzweigungen und for - Schleifen)
vertraut ist.
ob es dem anfaenger am ende nun von Deiner fetten objektorientierten
programmierung oder von meinem zugegebenermassen sehr konsequent
durchgezogenen funktionalen konzept schummrig vor augen wird, ist
eigentlich egal ;-)
fuer absolute neulinge wird beides schwer verdaulich bleiben - der
interessierten laien hingegen sollte in der lage sein, sich durch
beide ansaetze zu arbeiten.
Daher mein Vorschlag: Lass uns doch zweigleisig fahren ! Ich schreibe
meinen Ansatz zu Ende, damit eine sagen wir mal "einfache" Version
zum Nachverfolgen und selbst wieder einsetzen entsteht. Und Deine
Version baut dann (offensichtlich) darauf auf, diesen Ansatz noch
wesentlich weiter zu treiben ...
mein ansatz wird die sichtbare komplexitaet der eigentlichen applikation
hoffentlich eher reduzieren, indem er offensichtliche aufgaben/tasks durch
geeignete abstraktionen abbildet.
.., indem sie
a) mehr Features und
b) raffiniertere Programmiertechniken
mal sehen.
bietet. Das wäre dann gerade für mich genau die Vorlage, auf der
ich meinen Wissensstand wieder deutlich weiter voranbringen könnte ...
...Wäre das ein Vorschlag?
jo.
Nochmals vielen herzlichen Dank für Deinen Input. Genau deshalb habe
ich diesen Thread hier gestartet, damit genau das passiert.
nur aus diesem grund, bin ich ueberhaupt darauf eingestiegen. denn
ungeachtet aller bastelfreude halst man sich 'ne menge zusaetzliche
arbeit auf.
so long - peterS. - pseliger@gmx.net
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford
ie:( fl:) br:> va:( ls:& fo:) rl:) n3;} n4:} ss:} de:µ js:} mo:? zu:]