[Featurewunsch] allgemein Verwendung {id} | Funktionserweiterung Farbe (Hintergrund)

[saegefisch]

Hallo Christian,

A) ganz allgemein wäre es sehr hilfreich, wenn man überall (ähnlich z.B. Meldungsarchiv oder Diagrammen) in jeder Formel - neben dem {#}-KO - auch {id} und {y/y/z} (für GA) verwenden könnte. Dann könnte man mancherlei Umrechnungsfaktoren zentral remanent ablegen und müsste nicht in vielen Visu-Elementen und Farben adjustieren, wenn der Wert doch mal zu ändern ist. Konkret:

statt:
-webkit-linear-gradient(top,transparent 0%, transparent {#*1.41/2.55}%, #4a4b50 {#*1.41/2.55}%, #4a4b50 100%)

würde ich gerne den Werte z.B. aus iKO mit ID 1181 nutzen und schreiben können:
-webkit-linear-gradient(top,transparent 0%, transparent {#*{1181}}%, #4a4b50 {#*{1181}}%, #4a4b50 100%)

Anders gefragt: Lässt sich diese Ersetzung für KO (spannender) und ggf auch GA (weniger spannend) vielleicht gelegentlich und ohne großen Aufwand überall einbauen?


B) Zu den Hintergründen ganz konkret würde ich mir wünschen, auch background-color und background-size angeben zu können. Derzeit wird ja die Farb-Defintion letztlich in das style-Tag des DIV als "...;background: <Farb-Definition>;..." übernommen. Das ermöglicht zwar auch bereits mehrerer gestaffelte -webkit-gradient (was wunderbar ist), aber die Möglichkeiten der Hintergründe würde gemäß CSS3 geradezu explodieren, wenn man auch background-color und background-size angeben könnte. Ein Lösungsoption könnte sein, dass man dafür in der Konfiguration einer Hintergrundfarbe dafür zwei weitere (optionale und viel kleinere) Eingabefelder hat. Die würden meist leer belieben und alles wäre wie bisher. Aber wenn man sie füllt, würden sie im style-Tag als "...;background-color: <neues Feld für color>; background-size: <neues Feld size>;..." umgesetzt.

Noch flexibler, aber vielleicht auch krasser: Mit einem Schalter ("raw") oder einer besonderen Nomenklatur würde man z.B. in Gänsefüßchen "" roh-CSS eingeben dürfen, dass dann 1:1 in das style-Tag übernommen wird (statt wie bisher hinter "background:"). Um die richtige Schreibweise müsste man sich dann selber kümmern (schließende Semikolons,...). Damit wäre die Flexibilität maximal. Die Verantwortung des Anwenders letztlich unverändert, denn wenn's dann doof/verschrubbelt aussieht, muss man halt wieder ran. Und wer's nicht will, für den bleibt alles wie bisher. Aber es geht ja nix kaputt dadurch. Last und Lust einer jeden roh-Schnittstelle...

Kurz: Damit würde die Möglichkeiten von CSS3 erheblich weiter ausgenutzt. Ob die Visus dadurch schöner werden, sei mal dahin gestellt...

Danke für Deine Einschätzung und viele Grüße,
Carsten

[gaert]

ad A:
Nein, das geht leider nicht (so einfach). Das hat mit dem Grundkonzept zu tun - jedes Visuelement hat genau 1 "Steuerungs-KO". Wären hier beliebige weitere KOs möglich, müssten diese ja allesamt per AJAX in die Visu übertragen und überwacht werden. Und das ist erstens nicht ohne Weiteres machbar und zweitens ziemlicher "Overhead"... Abhilfe schafft hier nur "split()" und ein entsprechender LBS, der das KO aufbereitet.

ad B:
Du kannst durchaus eine Hintergrundfarbe UND ein Hintergrundbild im Visuelement angeben. Ausserdem kannst Du bereits jetzt beliebiges CSS im Design angeben...
Für spezielle Anforderungen in Sachen Skalierung gibt's ausserdem das Visuelement "Bildelement".

[saegefisch]

ad A: yupp, das habe ich vermute. Ich hatte gehofft, z.B. für das Muster{<eine zahl>} könnte man relativ einfach überall schauen, ob es dazu eine ID gibt, und den Wert einsetzen, wenn ja, sonst als Null. Das schein mir fast wie ein etwas erweitertes "replace" mit klarem Muster einer Zahl als Ersetzungswert. Aber eine Frage war's wert und vielleicht kommt bist Du da irgendwann noch mal dran und sieht eine Möglichkeit. Aber nix für "die Liste"...

Ad B: Es geht - das steht außer Frage - schon viel! Fakt. Aber es gibt einen ganzen Sack an CSS3-Möglichkeiten, die man nur hat, wenn man im selben style-Tag sitzt. Mit den genannten Umwegen war ich nicht in der Lage, bestimmte Dinge umzusetzen, die durchaus funktionierten, wenn man im Crome mal mit den Entwicklerwerkzeugen on-the-fly das style ändert um background-size und backgrouns-color. Ist nicht wichtig, aber mit dem Vorschlag oben könnte man sich völlig frei im CSS3 und ohne großen Aufwand austoben. Auch mit Bildelement habe ich das versucht. Vielleicht muss ich dem noch mal eine Chance geben --> werden den size und color dort tatsächlich auf background-size und background-color umgesetzt?.
Aber optional "raw" in das Style-Tag rein zu können wäre schon cool. Für mich wär's was für "die Liste", aber sicher nicht weit oben.

Danke und viele Grüße,
Carsten

[Winni]

Ich schreib's mal hier mit dazu, weil's ganz gut passt. Ich würde gerne folgende Hintergrundfarbe benutzen:

-webkit-linear-gradient(left,rgba(255,{255-split(1,"*")},{255-round(split(1,"*")*2.5)},1) 0%,rgba(255,{255-split(1,"*")},{255-round(split(1,"*")*2.5)},1) {split(0,"*")+(5-split(0,"*")/100)}%, rgba(255,{255-split(1,"*")},{255-round(split(1,"*")*2.5)},1) {split(0,"*")}%,rgba(255,255,255,0) {split(0,"*")+5*split(0,"*")/100}%, rgba(255,255,255,0.5) {split(0,"*")+5*split(0,"*")/100}%,rgba(255,255,255,0.5) 100%)

Beim Testen in der Konfiguration -> Farbe funktioniert das noch einwandfrei. In der Visualisierung weder in der Vorschau, noch im Live-Projekt. Sobald das steuernde KO das Trennzeichen enthält ist der Hintergrund durchsichtig. Mit einem einfachen Wert klappt es, aber es fehlt halt die "2. Dimension)

Kann mir jemnd auf die Sprünge helfen?

[Winni]

gaert
Hallo Christian, könntest du mir bitte sagen, ob bei einem dynamischen Hintergrund split() oder str_split() funktionieren müsste? Bei der Simulation in der Anlage der Farbe klappt es, sonst aber nicht? Ist das ein Bug, auf dessen Lösung man warten kann, oder ist das nicht vorgesehen? In dem Fall muss ich es halt anders lösen.

[gaert]

Sollte eigentlich klappen - dafür ist die Vorschau (bei den Farben) ja gedacht

Ob's in der Visu-Vorschau klappen sollte weiß ich gerade selber nicht so genau - aber in der richtigen Visu sollte es natürlich funktionieren. Ich schau's mir mal an, bin aber momentan ziemlich mit anderen Dingen beschäftigt...

EDIT:
Es funktioniert nur mit einfachen Anführungszeichen in einer Farbdefinition, also split(1,'*') statt split(1,"*"). Vermutlich ist dies so, weil die Farbe selbst intern auch wieder als String in "" gepackt wird. Ich werde dies bei Gelegenheit mal genauer untersuchen und entweder beheben oder die Hilfe anpassen

[Winni]

Ich schau's mir mal an, bin aber momentan ziemlich mit anderen Dingen beschäftigt...

Nur kein Stress, danke für die Info

[Winni]

Hab heute die 1.55 installiert und nachdem nichts besser war nochmal reingeschaut.... Danke für den Hinweis mit den Hochkommas, hab's leider erst heute mitbekommen. Klappt nun prima!

[saegefisch]

Nein, das geht leider nicht (so einfach). Das hat mit dem Grundkonzept zu tun - jedes Visuelement hat genau 1 "Steuerungs-KO". Wären hier beliebige weitere KOs möglich, müssten diese ja allesamt per AJAX in die Visu übertragen und überwacht werden. Und das ist erstens nicht ohne Weiteres machbar und zweitens ziemlicher "Overhead"... Abhilfe schafft hier nur "split()" und ein entsprechender LBS, der das KO aufbereitet.

Hallo Christian,
ich arbeite an einer neuen Visu und versuche sie von Grund auf so generisch wie möglich zu halten und wo immer es geht, nur edomi-Standard und HTML/CSS-Standard zu verwenden. Doch stoße ich dabei immer wieder an die Grenze, dass ein Visu-Element nur genau ein KO hat. Ich kann verstehen, was Du mir damals zu beliebig vielen KO geantwortet hast, doch möchte ich meine Frage abwandeln und mit einem Beispiel ergänzen: Sollten Visu-Element (eigentlich ist hier technisch eher der "Design (Visuelement)"-Dialog gemeint) nicht ein oder maximal zwei KO haben können? Das vorhandene KO und ein optionales weiteres KO, was per Split() zentrale Visu-Eigenschaften ermöglicht. In vielen Fällen wird dies bei vielen vielleicht leer bleiben, aber wenn man es nutzen möchte, könnte man Visu gestalten, die durch einen generischen Ansatz außerordentlich wandlungsfähig wären wären und zentral weitreichende Adjustierungen ermöglichen durch Änderungen von ein paar KOs, die als Zweit-KO in sehr vielen Visu-Elementen verwendet werden.

Warum mir ein KO nicht reicht? Oft hat man ein KO, dass für die Werte-Ausgabe oder die dynamischen Designs zuständig ist (im einfachen Fall ein Status, der ein Icon per dynam. Design rot oder grün darstellen soll). Bis dahin alles wie bisher. Aber mit einem 2. KO könnte man z.B. die Position oder Opazität oder noch viele andere Sachen zentral für alle Icons ändern, die einen Status anzeigen. Das 2. KO dient der zentralen Design-Steuerung, das erste (bisherige) KO dem spezifischen Wert _dieses_ Elements. Nehmen wir das 2. KO gewisserweise als Design-KO.

Zugrif könnte sein {#} für das bekannte KO und {{#}} für das zweite, also z.B. {split(0)} auf Basis des 1. KO oder {{split(0)}} auf Basis des zweiten KO. Das wäre m.E. ein riesen Fortschirtt für die Visu und würde bei sinnvollem Einsatz auch weitreichende Änderungen an der Visu von 1000 Klicks auf eine Wert-Änderung eines KO reduzieren.

Sollte es einfacher/performanter sein, kann diese 2. Design-KO funktional eingeschränkt werden auf genau die Nutzung in Design-Parametern, wünschenswert wäre aber zumindest der möglich Durchgriff/Nutzung zur Verwendung auch in Vorder- und Hintergrundfarben.

[saegefisch]

gaert : Hallo Christian,
im selben Geiste wie das colocalc()-Thema letzte Woche mag ich dieses Thema noch mal nach vorne bringen. Denn beides dient m.E. einem großen Schritt zu schlanken/flexiblen Visus - nur auf Basis von edomi-/W3C-Standardmitteln (und ganz ohne Bitmaps), die auch bei hoher Komplexität gut pflegbar/wandlungsfähig und schön/ansprechend zu gleich sein können.

In der letzten Zeit habe ich mich recht intensiv damit beschäftigt und mir so eine recht gute Ausgangsbasis konzipiert. Daraus ist bei mir auch schon eine mehrseitige Doku geworden, die ich demnächst hier als Anleitung/Ideengeber für eine mögliche Art der Visu-Erstellung im Thema "Zeigt her Eure Visus" bzw. ggf auch im edomi-Wiki einbringen mag und in diesem Zuge auch meine Visu vorstellen möchte.

Für eine vollständige Lösung fehlen m.E. aber noch zwei Funktionserweiterungen. Die ein ist genau die hier vorgeschlagene Option eines 2. KO ("Design-KO") für Visuelemente. Denn mit einem geschickten Layerkonzept (Inkludes, Z-Index) und Design-KO kann man nun schon erstaunliches dynamisch mit der Visu machen - manches davon ist sogar sinnvoll...

Allerdings endet diese Flexibität auf der Funktionsebene, weil dort die VE bereits ein funktions-bezogenes KO haben (Status RM-Wert, Stellwert,...). Darunter hatten die VE dies nicht und so konnte das eine KO für Design-KO verwendet werden. Daher mein Ansinnen/meine Anfrage, ob die VE nicht genau _ein_ zusätzliches, optionales KO für Design-Zwecke (per split() in Designs und Farben nutzbar) bekommen können. Diese Design-KO würden zumeist von vielen VE gemeinsam genutzt, um ein homogenes Bild zu erreichen.

Eine wohlwollend-kritische Prüfung ist sehr willkommen...

[gaert]

Natürlich wäre das toll - und ähnliches belagert meine Liste schon gefühlt seit Version 1.0 Ich muss nur stets die Prioritäten im Auge behalten... Aber da kommt schon noch was, alles nur eine Frage der Zeit.

[saegefisch]

...wohlwissend, dass der Zorn des Kollektivs über mich herein brechen wird: Ich find's erheblich spannender, hilfeicher und wichtiger, als dieser Import/Export...

[Marha]

In der letzten Zeit habe ich mich recht intensiv damit beschäftigt und mir so eine recht gute Ausgangsbasis konzipiert. Daraus ist bei mir auch schon eine mehrseitige Doku geworden, die ich demnächst hier als Anleitung/Ideengeber für eine mögliche Art der Visu-Erstellung im Thema "Zeigt her Eure Visus" bzw. ggf auch im edomi-Wiki einbringen mag und in diesem Zuge auch meine Visu vorstellen möchte.

Hast Du bereits einen ersten Entwurf Deiner Anleitung bereitgestellt?
Würde mich sehr interessieren, auch wenn noch nicht alles umsetzbar ist.

[Bernator]

Würd mich auch interessieren, mache gerade meine ersten Schritte, also eine denkbar schlechte Ausgangslage für eine solide Basis

[saegefisch]

Natürlich wäre das toll - und ähnliches belagert meine Liste schon gefühlt seit Version 1.0 Ich muss nur stets die Prioritäten im Auge behalten... Aber da kommt schon noch was, alles nur eine Frage der Zeit.

Hallo Christian,

weil mal danke Janncsi genialen Hinweises (die Lektüre der gesamten Seite ist spannnend) auf material.io wieder etwas Lust auf Visu-Änderung habe (bei mir zu kompliziert) - gibt es ein Update/Ausblick für VisuElementen für ein 2. Design-KO (s.o.), dass nur für diese Design-Zwecke optional möglich ist. Vielleicht als {{#}} oder {##} in split() ansprechbar? Absehbar wäre für mich alles vor Version 2...

Ist für mich überhaupt nicht kriegsentscheidend, nur spannend, in welche Richtung ich bei der Visu gehe. Will halt möglichst selten noch mal dran und mich lieber um Funktionen kümmen und dennoch bei Wünschen meiner Familie ("boah Papa, seit heute ist lila meine Lieblingsfarbe!") mit ein paar Klicks für einzelne Visus reagieren können. Wenn nicht, ist auch gut...

Denn nicht zuletzt geht es mir an vielen (nicht allen) Tagen ähnlich wie vielen hier mit der Visu --> siehe Janncsi interessante Frage