Interesantes Design...vielleicht auch bald mit CometVisu?!

[netsrac]

Hast Du Vorschläge für eine Generalisierung?
Oder wo kneift's?

Oh man...schon wieder 'nen Monat rum...wish I had more time :-(

Ich bin ja nun so weit, dass ich mit einer Gruppe arbeiten muss. Hierbei sollte der "Click" auf eine Gruppe etwas auslösen...GA schreiben oder PageJump würde reichen. Zusätzlich brauche ich noch die Möglichkeit, die Hintergrundfarbe der Gruppe zu setzen...

Bin nicht so gerne Einzelkämpfer und hoffe, dass vielleicht noch jemand Lust hat, an so einem Design mitzubauen...

Gruß, Netsrac

[Chris M.]

Hast Du Vorschläge für eine Generalisierung?
Oder wo kneift's?

[netsrac]

Habe nochmal ein bisschen in meinem stillen Kämmerlein rumgespielt, aber so richtig habe ich hier keinen Erfolg.

Man wird nicht um Erweiterungen in den Widgets herumkommen und damit läßt es sich nicht alleine übers Design steuern :-(

[JuMi2006]

EDIT: ich bin wohl im Beitrag verrutscht

[makki]

So ist es, momentan macht es nur Sinn Attribute zu dokumentieren, am Editor ist einiges zu tun und was da rauskommt halte ich aktuell für =?

Makki

[swiss]

Naja.... Wie so etwas zu dokumetieren wäre hängt im wesentlichen auch davon ab was der Editor im Hintergrund selbstständig macht und wo der User selber Handanlegen muss/kann/darf. Je nach dem kommt das in die Widgetbeschreibung oder einen eigenen Artikel für fortgeschrittene Nutzer

Das wird sich aber erst noch zeigen. Erst müsste das Editorkonzept für die neuen Funktionen stehen und wieder funktionieren.

[greentux]

Es obliegt dann der Doku, gut darzustellen, was geht und was eben nicht geht. Ich kann Chris "Feeling" da verstehen. Die Lösung ist nur 99% Aber nun, man kann es ja mal probieren, wie es sich so anfühlt.

[netsrac]

Da hätte ich eine Idee. Jedes Widget kriegt eine eindeutige ID (kann meinetwegen auch REF heissen und im data untergebracht sein, ID ist schöner, wiel einfach zu selektieren), ähnlich der Pages.

Sehr schöner Ansatz....das macht bei weitem mehr Sinn als ein dämliches CSS rumgef*cke :-)

Nicht nur für diese Design Idee könnte man das gut gebrauchen...ich denke sowas erlaubt ganz Andere Möglichkeiten. Zwar bin ich nicht ganz unbeleckt was CSS angeht, bei den Tiefen von jQuery steige ich dann (leider) aus...

[Chris M.]

Wir reden hier über zwei Arten von ID - die eine in der Config-Datei, die andere im DOM.

Vielen Dank für den Hinweis dass die ID nicht mit einer Zahl anfangen darf - das ist ein Bug und muss behoben werden! (-> https://sourceforge.net/tracker/?fun...6&atid=1251141)

[iwan]

Hallo Zusammen

Die Idee mit der ID hatte ich auch, damit ich zB die Uhr auf der Startseite grösser darstellen kann oder ein X-Beliebeiges Element anders formatieren kann.

Ich habe dann das mit der ID wie bei den Pages probiert, leider haben da einige Brower Probleme damit.
(mit dem #id in CSS)

Dann bin ich darauf gestossen: SELFHTML: HTML/XHTML / Referenz /HTML-Attribut-Referenz

Also müsste man zB "id" vorne dran setzen. Die ID der ersten Page wäre dann id="id0" statt id="0" oder id="id0_1" statt id="0_1".

Müsste das nicht allgemein geändert werden um "HTML Konform zu sein"?

Mann könnte die ID auch ins class= integrieren aber auch da kam zB Firefox nicht klar damit wenn der "_" drin war...

Grüsse
Iwan

[Chris M.]

Mir faellt noch ein, dass die Verantwortung für die Eindeutigkeit der Identifier beim User liegt. Ich weiß spontan nicht, was passiert, wenn es eine id zweimal gibt.

Wenn wir's "id" nennen wird die XML automatisch ungültig AFAIK. Bei was anderem (z.B. "ref") dürfen wir wohl selber definieren ob die XML dadurch ungültig werden soll...

Das die XML ungültig wird halte ich für einen Vorteil!

Das mit dem colorchooser finde ich unproblematisch.

Ich auch - aber das war nur ein Beispiel! Du könntest auch das Plugin <clock> - oder gar den <slider> nehmen!

Unterm Strich halte ich das mit dem fehlenden Click-Ort auch für akzeptabel, sehr geht mir hier alle Nachteile zu sammeln und zu bewerten. Denn wenn es keine oder keine schlimmen gibt, können wir das gerne umsetzen

[JNK]

Mir faellt noch ein, dass die Verantwortung für die Eindeutigkeit der Identifier beim User liegt. Ich weiß spontan nicht, was passiert, wenn es eine id zweimal gibt.

Das mit dem colorchooser finde ich unproblematisch.

Gruß,

der Jan

[JNK]

Mir faellt noch ein, dass die Verantwortung für die Eindeutigkeit der Identifier beim User liegt. Ich weiß spontan nicht, was passiert, wenn es eine id zweimal gibt.

Das mit dem colorchooser finde ich unproblematisch.

[Chris M.]

Da hätte ich eine Idee. Jedes Widget kriegt eine eindeutige ID (kann meinetwegen auch REF heissen und im data untergebracht sein, ID ist schöner, wiel einfach zu selektieren), ähnlich der Pages.
[...]
Dann würde der Click entsprechend weitergereicht.

Interessanter Vorschlag! Würde nebenbei auch die IDs für den <pagejump> mit lösen können.

Ein Nachteil fällt mir dabei spontan ein: es würde nur für Widgets gehen, die nicht auf den Ort des Clicks schauen (wie <trigger> oder <switch> - aber z.B. kein ColorChooser) - aber ist das hier relevant?
Was gibt es sonst noch für mögliche Nachteile?

[JNK]

Naja, man müsste für die "groups" ein "onClick" definieren können...nur die Frage, wie man das dann auf ein beliebiges Widget biegt...

Da hätte ich eine Idee. Jedes Widget kriegt eine eindeutige ID (kann meinetwegen auch REF heissen und im data untergebracht sein, ID ist schöner, wiel einfach zu selektieren), ähnlich der Pages.

Wenn der "Programmierer" nichts vorgibt, wird die automatisch vergeben,
d.h. z.b. 0_0_1_2_w1, das zweite dann 0_0_1_2_w2 und so weiter.

Alternativ kann dem Widget ein

id="test_id"

mitgegeben werden. Die Groups (oder meinetwegen alle Widgets) können optional ein

forwardEvent="test_id"

bekommen.

In der action-Routine steht dann am Anfang etwas wie

if ($(this).data('forwardEvent') {
  $('#'+forwardEvent).action();
  return;
}

Dann würde der Click entsprechend weitergereicht.

Gruss,

der Jan