GA abhängig Bild anzeigen

[JNK]

Wenn wir schon dabei sind, eine Frage hätte ich noch, damit ichs vielleicht endlich mal wirklich verstehe was ich da pinsle:
- (var) actor: ist eine simple Variable, String, klar
- $(actor) ist jQuery-Magic, nicht ganz klar, aber egal, das kann ich anderswo nachlesen
-> Aber: $actor ist: ? Derselbe jQuery-Magic wie $(actor) aber noch nicht ans DOM gebunden? oder nicht.. oder was? console.dir sagt nur unverständliches Objekt-blubber

Also, ich bin ja auch kein JS Experte, ich hab das das erste mal vor ca. nem halben Jahr gesehen. Aber soweit ich das verstanden habe, liefert $(actor) ein Objekt aus dem String actor, das alle möglichen netten Funktionen bereitstellt.

$actor ist auch nur eine variable, die auch hasemoeff heissen könnte und dieses objekt beinhaltet. also

var hasemoeff=$(actor);

würde es genauso tun. Ich finde das ein unglückliches weil verwirrendes Namenskonzept, aber habe das so übernommen aus dem bestehenden Code. Angebunden wird es dann irgendwann später, ret_val wird irgendwo (da wos passt) eingefügt.

mit $("body").append(hasemoeff) würdest du es direkt einfügen. Solange Du hasemoeff oder $(actor) nicht irgendwo appended hast, schwirrt das einfach nur irgendwo als Objekt rum und ist auch nicht sichtbar. Im Firebug sind die dann so leicht angegraut, während sichtbare Objekte Vollfarben haben.

gruss,

der Jan

[Chris M.]

Wenn wir schon dabei sind, eine Frage hätte ich noch, damit ichs vielleicht endlich mal wirklich verstehe was ich da pinsle:
- (var) actor: ist eine simple Variable, String, klar
- $(actor) ist jQuery-Magic, nicht ganz klar, aber egal, das kann ich anderswo nachlesen
-> Aber: $actor ist: ? Derselbe jQuery-Magic wie $(actor) aber noch nicht ans DOM gebunden? oder nicht.. oder was? console.dir sagt nur unverständliches Objekt-blubber

$(foo) ist jQ Magie. Die kann ich auch nicht ganz erklären - aber wichtig ist halt, dass ist dann ein jQ-Objekt mit dem man jQ-Sachen machen kann.
Da das soooo praktisch ist, lohnt es sich, wenn man es immer wieder braucht, dieses Objekt in einer lokalen Variable zwischen zu speichern (Performance, s.o.). Und bevor man sich im Namen verrennt, kann man gleich einfach $foo schreiben.
(-> Für JS ist das "$"-Zeichen ein stink normales Zeichen das auch für Namen hergenommen werden darf, so wie "_". D.h. wir hätte genau so gut oder schlecht _foo schreiben können...)
$foo hat in sich keinerlei magische Bedeutung.

-> Nachdem ich grad halbwegs drin bin, würde ich writeonly Editor-seitig gleich mit einbauen, weil wenn ich das Problem gefunden habe ist das nur noch zusätzliche fleissarbeit?

Grundsätzlich liebend gerne - aber leider gab's noch kein Feedback im anderen Thread ob statt <nichts>/readonly/writeonly/readonly+writeonly(?!?) nicht besser ein access="readonly"|"writeonly"|"readwrite"(<- default) wäre. Was aber die aktuelle Konfig-Syntax zerstören würde. (Nicht dass wir das nicht schon mit <layout> machen...)

Ausserdem finde ich das ansprechen von Address-parametern (transform, addr, readonly, variant) als array mit [0/1/2] nicht sonders geschickt bzw. ist es uneinheitlich, explizite Namen wären da doch besser(?)

Ja, da wäre wohl ein Hash/Objekt besser als ein Array.

Was auch noch fehlt: die images sollten optimalerweise beim start der Visu vorgeladen werden, was die Sache zügiger macht;

Im Zweifel: Füll mal ein (globales) Array mit den URLs. Wie wir das dann optimal vorladen können später klären.

Sorry, old-school mag durchaus zutreffen

Ich meinte damit, dass Du "use strict"; nicht kennst...
(Ich kenne es auch nur, weil ich die es-discuss Mailing-Liste (die wo am ECMAScript Sprachstandard gearbeitet wird) aboniert habe...

[makki]

$actor ist auch nur eine variable, die auch hasemoeff heissen könnte

..halbwegs kapiert!..

$(foo) ist jQ Magie. Die kann ich auch nicht ganz erklären

.. Das beruhigt mich ungemein
Die Tatsache das man es selbst nicht umfassend versteht, kann auch damit abgemildert werden, das es die Mehrheit nicht versteht

...
$foo hat in sich keinerlei magische Bedeutung.

Da gibts noch viel zu lernen aber ein bedeutender Teil ist mal wieder geschafft! Das mit den doppelten Objekten war mir so ehrlichgesagt vorher (also vor der Erklärung von JNK) nicht so ganz bewusst..

(writeonly)

Grundsätzlich liebend gerne - aber leider gab's noch kein Feedback im anderen Thread

hmm.. egal? wir brauchen das für mindestens zwei bekannte Anwendungsfälle, wo uns nichts besseres einfällt, also ist es so?!

ob statt <nichts>/readonly/writeonly/readonly+writeonly(?!?) nicht besser ein access="readonly"|"writeonly"|"readwrite"(<- default) wäre. Was aber die aktuelle Konfig-Syntax zerstören würde.

Nicht unbedingt, so wie ich mir das denke würde es nur readonly kaputt machen (variant ""=default=RW, RO, WO)
-> Wenn dann jetzt, je eher de besser denke ich..

Ja, da wäre wohl ein Hash/Objekt besser als ein Array.

s.o.: wenn dann gleich, bisher fällt nicht viel auf die Nase, wenn die variants/GA mal Schule machen (was durchaus Sinnig ist!) wirds immer schwerer..

Ich meinte damit, dass Du "use strict"; nicht kennst...

Doch, wo dus geschrieben hast erinnerte ich mich das es das gibt.. Aber mal ehrlich, das pro function als schmutzigen workaround einzufügen ist bestenfalls peinlich und cluttered den source massiv (..$...= function (..) "use strict";
Das ist ja kein Vorwurf an jeden der JS macht/mag und wird mich auch nicht davon abhalten das insgesamt für besser zu halten als "Apps" oder Flash oder..
Aber ich finde das recht peinlich, das sowas essentielles in einer string-Variable nachgerüstet werden muss

Da waren teilw. schon halblustige Kerle am Werk denke ich, im grossen und ganzen gehts also wars so falsch nicht aber im Detail bekommt man manchmal extremes Kopfweh

Makki

[greentux]

Da waren teilw. schon halblustige Kerle am Werk denke ich, im grossen und ganzen gehts also wars so falsch nicht aber im Detail bekommt man manchmal extremes Kopfweh

Na das gilt ja für so einige "Programmiersprachen".

[Chris M.]

Doch, wo dus geschrieben hast erinnerte ich mich das es das gibt.. Aber mal ehrlich, das pro function als schmutzigen workaround einzufügen ist bestenfalls peinlich und cluttered den source massiv (..$...= function (..) "use strict";

Das kommt ganz oben an den Code und gilt dann für alles - aber vorher hab ich noch ein paar wichtigere Probleme kurzfristig zu lösen. (-> Wäre mal gut als Feature Request zu haben, damit's nicht verloren geht)

Aber ich finde das recht peinlich, das sowas essentielles in einer string-Variable nachgerüstet werden muss

Da waren teilw. schon halblustige Kerle am Werk

Diese halblustigen Kerle haben immense Angst davor, bestehenden Code im Netz kaput zu machen. Davon gibt es einfach viel zu viel - und wenn ein Browser eine JS-Engine hat, die nun dank neuem Standard nicht mehr läuft, wird's schwierig.

IIRC wird es Möglichkeiten geben im <script>-Tag die verwendete ECMAScript Version anzugeben - und da drüber auch gewisse Sprach-Features erst frei zu schalten. (Wie ein automatisches "use strict").

Das schön an

"use strict";

ist halt, dass auch Uralt-Browser damit umgehen können. Die machen da nämlich im Zweifel einfach nichts. Aber akzeptieren die Syntax...

[makki]

Na das gilt ja für so einige "Programmiersprachen".

Wohl wahr! Aber zu ECMA-Script passt das, einen essentiellen Laufzeitparameter in einem String zu "verstecken", ehrlichgesagt am wenigsten

(-> Wäre mal gut als Feature Request zu haben, damit's nicht verloren geht)

Das mach ich doch mal glatt, weil ich dringend daran glaube

Das schön an

"use strict";

Warum so: Schon völlig klar..
Wenn ich mir aber zutrauen würde eine solch essentielle Sprache zu machen (was ich nicht tue!) dann verstehe ich nicht wie man sowas banales "vergessen" kann, das lernt man bei den ersten Gehversuchen am Basic aufm Atari als Schüler (anno-schnuff, der heutige Schüler nimmt vermutlich sein Android-Handy), das es einfach total blöd ist, wenn Tippfehler in Variablen zu einer Neu-definition führen..

ist halt, dass auch Uralt-Browser damit umgehen können.

Da gabs noch keine Browser, als ich mir das angewöhnt habe


Zurück zum Thema, WE ist Ziel, ich kämpfe noch mit dem dynamischen hinzufügen&löschen der IMG-divs für mehrere Mülltonnen als Bitmaske (und habe gestern realisiert das ich den privaten Mülltonnen-Kalender 2012 wohl nicht in die "alte" Visu eingetragen habe - mit der Meinung das es bis dahin läuft )
-> writeonly würde ich dann auch mit einbauen. Optional als zusätzliches Feld im Array ohne config/API-break oder als Hash/Objekt??

Makki

[Chris M.]

-> writeonly würde ich dann auch mit einbauen. Optional als zusätzliches Feld im Array ohne config/API-break oder als Hash/Objekt??

Ich würde gleich auf Hash gehen. Der entstehende Break ist sehr überschaubar.

(Wenn nämlich schon alle fleißig eigene Widgets schreiben würden, dürften hier deutlich mehr Fragen dazu auftauchen )

[makki]

Ok, sehe ich genauso..
Erst verplant: config-seitig gibt das ja keinerlei Änderung (das Problem mit readonly hatte mich da auf die falsche Spur geführt, hatte aber damit nicht zu tun..), nur im Code..
-> Aufruf zum commiten!
Ich denke wenn dann in einem Rutsch..

Frage 1): konsequenterweise sollte man dann auch transform (addr[0]) auf object (so heisst das glaube ich in JS) statt array umstellen(?)
Ist ein bisschen Arbeit deswegen frag ich lieber vorher aber ich fänds sauberer und übersichtlicher..
Frage 2): writeonly für address wurde in diesem Zuge mit-implementiert; für alles commiten? Ich halte es für ungefährlich, fehlend wird ignoriert..
Frage 3): Arbeitsname "imagetrigger": solls lieber ein Plugin oder gleich ein Standard-Widget werden?
Benutzt keine Sonderlocken/Specials, ich denke Standard (und evtl. dann ein [wesentlich einfacheres] "imagetoggle/switch" gleich hinterher)

Makki

P.S.: Widget wäre schon, ich überlege nur noch o.g. und es evtl. doch gleich in mehrere splitten, weils schon wieder umfassend konfigurierbar geworden ist..

[Chris M.]

Frage 1): konsequenterweise sollte man dann auch transform (addr[0]) auf object (so heisst das glaube ich in JS) statt array umstellen(?)

Bin gerade nicht im Code drinnen => keine Antwort von mir

Frage 2): writeonly für address wurde in diesem Zuge mit-implementiert; für alles commiten? Ich halte es für ungefährlich, fehlend wird ignoriert..

Wäre ich auch für

Frage 3): Arbeitsname "imagetrigger": solls lieber ein Plugin oder gleich ein Standard-Widget werden?
Benutzt keine Sonderlocken/Specials, ich denke Standard (und evtl. dann ein [wesentlich einfacheres] "imagetoggle/switch" gleich hinterher)

Wenn der Umfang ähnlich der bestehenden Widgets ist, darf's gerne in structure_pure.js

Als Plugin sollten die Dinge gekapselt werden, die viele (einige...) nicht brauchen UND die einen erhöhten Ressourcen-Bedarf haben (egal ob Load-, Compile oder Run-Time)

[makki]

Bin gerade nicht im Code drinnen => keine Antwort von mir

Hmm, von Dir wollte ich die AW aber
Es geht eigentlich nur um Kosmetik, das ist mir dabei halt nur aufgefallen, es ist für mich nicht sonderlich transpararent sich (in diesem Fall) den transform "blind" aus dem ersten Array-Element (xy...[0]) zu holen. xy.transform fände ich deskriptiver als xy[0]
Ebenso wie wie address.readonly, .variant, .. - statt address[1], [2]
Aber der gebohrene Chef-SW-Designer bin ich nun wahrlich auch nicht, daher die Frage zu Bedenken, Risiken und Nebenwirkungen..
-> In der config ändert sich nichts, das ist die gute Nachricht. Es wird halt nur etwas umdenken und Effort erfordern, bis alles umgestellt und getestet ist.
Aber je tiefer ich reinkomme, fallen mir halt auch Sachen auf und die langjährige Erfahrung sagt mir: lieber frühzeitig rangehen! Noch sind wir da nicht in 1000 Abhängigkeiten verstrickt..

Wenn der Umfang ähnlich der bestehenden Widgets ist, darf's gerne in structure_pure.js

Ist es, diesmal nicht nur kopiert sondern eher optimiert (oder anders ausgedrückt mal komplett selber geschrieben, dem Lernprozess zuliebe.. das kann aber auch ein Nachteil sein )

Als Plugin sollten die Dinge gekapselt werden, die viele (einige...) nicht brauchen UND die einen erhöhten Ressourcen-Bedarf haben

Ok, ist hier bewusst nicht der Fall (weil ich das ggü. Wetter-XY wirklich als als Standardfunktion sehe), keine externals, nach bestem Wissen und gewissen macht das garnichts wenn man es nicht verwendet und wenn doch eben nur die Image-URL ändern..
Wollte nur den Segen dazu

Makki

[Chris M.]

Hmm, von Dir wollte ich die AW aber

Keine Antwort heißt auch, dass ich nichts dagegen habe

Im ernst: wenn ich Änderungsvorschläge sehe, die mir suspekt vorkommen, dann sage ich das, auch gerne frühzeitig und aus dem Bauch. Dabei lasse ich mich durchaus auch umstimmen.
Um aber zu sagen, dass eine Lösung super ist, bedarf es halt vorher einer Analyse. (Zumindest um die Wahrscheinlichkeit eines fatalen Fehlers zu senken)

=> Darfst Du von mir aus gerne einbauen, da mir spontan nichts negatives daran einfällt.

[WICHTIG]Eine Bitte allerdings bei so grundlegenden Refactoring Aktionen:
Bitte als einzelnen Commit! Nicht mit anderen Featuren vermischen!
[/WICHTIG]

Nur so lässt sich später sauber nachvollziehen, was wo war und evtl. warum's wo klemmt (und ggf. was überall wo zu fixen ist, damit's nicht mehr klemmt)

[makki]

Klar, ich denke jetzt erstmal das sauber zuende bringen und dann wirds eh getrennt commited.
Also imagetrigger, writeonly, array->object

Die strukturellen Änderungen brennen ja nicht ansatzweise, da hätte ich jetzt eh erstmal auf JNK's neues Design gewartet um da doppelaufwände zu vermeiden..

Und beim imagetrigger-Widget bin ich glaube ich jetzt in die 2D-Visu abgerutscht mit dem Ansporn das (zusätzlich/auch) "lokal" im SVG zu machen
-> Muss dann wohl mal kurz den Reset-button drücken, damit wenigstens das seit 2W fertige mal ans Tageslicht kommt..

Makki

[Chris M.]

Und beim imagetrigger-Widget bin ich glaube ich jetzt in die 2D-Visu abgerutscht mit dem Ansporn das (zusätzlich/auch) "lokal" im SVG zu machen

Das lokal im SVG ist eher eine Fingerübung gewesen.

Optimal ist es nicht, da die dort verwendeten GAs nun doppelt abgefragt werden.
=> Besser ist es, das SVG über den normalen Mechanismus mit zu ändern.
Dank (SVG-)DOM geht das auch wunderbar

Nachtrag: ich überlege gerade mal ein Uhr-Widget zu bauen, bei dem man an einer Zeiger-Uhr (+ Digial-Teil ) per Touch Zeiten einstellen kann. Das wäre dann natürlich auch "Live"-SVG im normalen HTML-DOM.

[JNK]

Nachtrag: ich überlege gerade mal ein Uhr-Widget zu bauen, bei dem man an einer Zeiger-Uhr (+ Digial-Teil ) per Touch Zeiten einstellen kann. Das wäre dann natürlich auch "Live"-SVG im normalen HTML-DOM.

Das wäre sehr schön, aber eine Bitte: skalierbar, wenn es geht. Der colorchooser ist ein schönes Beispiel, wie es NICHT sein sollte. der ist nämlich immer 195x195 px gross, egal wie hoch die Auflösung ist. Das führt dazu, dass die gleiche Seite auf unterschiedlichen Geräten völlig anders aussehen kann, weil das unterschiedlich gesetzt wird.

Gruss,

der Jan

[Chris M.]

Klar, das ist die Stärke von SVG

Wobei die normale Uhrzeit-Anzeige langweilig ist (ok, man könnte zusätzlich eine col-/rowspan abhängige Analog-Uhr einbauen). Für's Input hätte ich dann ein Popup genommen.

(Bevor hier noch jemand fragt, wann's so weit ist: momentan gibt es nur die Idee, keinen Code, und den 3D Code, der fertig werden will...)

Zum Colorchooser: Optimal ist anders, aber hier ging's um Schnelligkeit in der Implementierung. Und hübsch und praktisch ist der außerdem. (Wenn die starre Größe passt...)