Visuelemente (VSE) - Entwicklerwunschliste

[SvenA]

Hallo!

Hier mal eine kleine Wunschliste an gaert. Die folgenden Punkte würde ich mir für die Entwicklung von Visuelemente noch wünschen:

1. Ich hätte nicht gedacht, dass ich die 20 Variablen so schnell verbrauche, aber da ich auch viele einzelne Farben einstellbar gemacht habe und jede Farbe eine Referenz zu einem Farbobjekt darstellt, waren ganz schnell 9 Variablen alleine dafür weg.
   Ich werde jetzt bei meinem VSE versuchen noch irgendwie zu tricksen, da ich noch Felder brauche, aber sauber wird die Lösung dann nicht.
   
   Ich würde mir wünschen, wenn 25 Variablen zur Verfügung stünden.
   Das sollte erstmal reichen. Noch besser wäre es natürlich die Anzahl dynamisch wählen zu können, aber das wird vermutlich schwieriger zu implementieren.
2. Eine VSE Funktion für eine Überprüfung zur Verfügung stellen, die immer nach Ändern einer Eingabe aufgerufen wird.
   
   Dort könnte dann die EIngabe überprüft werden und ggf. eine Meldung ausgegeben werden.
   
   Zum Beispiel:
   

   VSE_VSEID_VALIDATE=function(fieldId,obj,value) {
   	if ((fieldId == 1) && (value == obj.dataset.var2))
   	VSE_VSEID_ERROR_MSG(fieldId, "Werte dürfen nicht gleich sein!")
   	}

3. Das Deaktivieren von Feldern hinzufügen.
   Manchmal hängen Felder von Eingaben in anderen Feldern ab. Wenn ich in einem Feld eine bestimmte Auswahl getroffen habe, dann könnte es sinnvoll sein Eingabefelder zu deaktivieren.
   
   Ich könnte mir auch vorstellen, dies als Erweiterung zu 2) zu sehen, um die Implementation einfach zu halten. Dann könnte in der VALIDATE() Funktion zum Beispiel über eine Funktion wie "VSE_VSEID_VALIDATE_ACTIVE()" das Feld aktiviert bzw. deaktiviert werden.
4. Das Laden von Standardwerten für ein VSE aus der Datenbank. (Hatte ich schon mal geschrieben, aber der Vollständigkeit halber).
   
   Anstatt nur die Standardwerte für ein VSE im Quelltext selbst anzugeben, sollte es möglich sein die Standardwerte auch in der DB zu speichern. Dazu bräuchte es nur zwei Knöpfe zum Setzen und Löschen der aktuelle eingegebenen Werte.
5. Vielleicht einen neuen Abschnitt [CHANGELOG] hinzufügen, in dem die Änderungen gelistet werden können.
6. Zusätzliche Dateien beim Hochladen eines VSE ermöglichen.
   
   Ich könnte mir vorstellen, dass es bei komplizierteren VSE nötig sein wird zusätzliche Dateien (z.B. Bilder, Schriften, etc.) zusammen mit dem VSE zu installieren.
   Vielleicht könnte man das lösen, indem man ein ZIP hochlädt und EDOMI das dann erkennt und entsprechend handelt.

So, das war's erstmal. Die Entwicklung von VSEs ist schon gut gemacht und auf jeden Fall Danke dafür. Diese Punkte würden meiner Meinung nach das ganze noch perfektionieren.

Gruß
Sven

[gaert]

Alles richtig und auch größtenteils uff Liste...

Vielleicht ein Tipp zu den Farben: Diese sollten eigentlich bevorzugt im "Design" ausgewählt werden, damit die Design-Vorlagen auch hier ihren Zweck erfüllen können. Dort stehen immerhin 3 Vorder- und 3 Hintergrundfarben zu Verfügung - das sollte i.d.R. genügen...

Das Changelog kann doch einfach in der Hilfe untergebracht werden (wie bei LBSen ja auch).

[sipiyou]

[gelöscht, falsches thema]

[SvenA]

Alles richtig und auch größtenteils uff Liste...
Vielleicht ein Tipp zu den Farben: Diese sollten eigentlich bevorzugt im "Design" ausgewählt werden, damit die Design-Vorlagen auch hier ihren Zweck erfüllen können. Dort stehen immerhin 3 Vorder- und 3 Hintergrundfarben zu Verfügung - das sollte i.d.R. genügen...

Hmm? Und wie ordne ich dann diese Designvorlagen den einzelnen Elementen des Visuelements zu?
Im Falle meines Schiebeschalters bräuchte ich das "Design" zweifach. Einmal für den Hintergrund und einmal für den Knopf.
Wenn ich mehrere Designs angeben könnte, dann würde es das Problem natürlich lösen...

Alternativ wäre auch eine Möglichkeit das Design nur auf einen spezifischen Teil des Elements anzuwenden und den Rest dann über die speziellen Eingenschaften zu steuern, aber das geht glaube ich nicht, oder?

Das Changelog kann doch einfach in der Hilfe untergebracht werden (wie bei LBSen ja auch).

Meine Idee war hier, dass man das dann beim Hochladen direkt parsen kann und für den Download separat speichern kann.
Außerdem könnte man das in der Hilfe vielleicht nur nach dem Klick auf einen Expander anzeigen, da mit der Zeit so ein Changelog schon lang werden kann.

[gaert]

Ich kenne Dein VE nicht bzw. habe ich noch nicht ausprobiert. Aber eigentlich gibt es ja unendlich viele Designs (dynamische welche), die verschiedene Zustände "füttern" sollen/können.

Farben und Bilder gibt's pro Design 3-fach (Zusatzfarben/Bilder). Das sollte doch eigentlich genügen?

[SvenA]

Ja, aber der Schiebeschalter setzt sich aus zwei Elementen zusammen. Und für jedes habe ich eigene CSS Angaben. Das kann ich also (soweit ich das verstanden habe) nicht über das Design abbilden, da die Designangaben das ganz Element betreffen, aber ich will die beiden Teile ja unabhängig voneinander "designen"...
Oder vestehen wir uns da falsch?

[gaert]

Naja, Du kannst über die entsprechenden Funktionen quasi auf alle CSS-Eigenschaften aus dem Design zugreifen und so z.B. dem Knopf ein Bild aus dem Design zuweisen. Grundsätzlich wird das "Design" immer auf den VE-Container angewendet (automatisch), sofern Dein VSE dies nicht überschreibt. Was mit den Child-Elementen passiert hängt ganz davon ab...

Bei der ZSU z.B. wird die Hintergrundfarbe der Buttons (ein/aus) aus dem Design entnommen - da kannst Du mal reinschauen.

[SvenA]

Hallo gaert,

ich habe mir jetzt das ZSU einmal angesehen.
Eventuell könnte ich einen Teil wirklich über die "Zusatzeigenschaften" abdecken. Werde ich einmal ausprobieren...

Wenn ich den "Design" Dialog wieder zulassen, dann habe ich natürlich das Problem, daß der Benutzer alle Werte angezeigt bekommt und ändern kann. Bei meinem VSE würde ich dann natürlich einige Werte fest setzen / überschreiben. Um Missverständnisse zu vermeiden wäre es hier toll, wenn man bestimmte Felder ausschalten könnte, so dass sie gar nicht erst zur Verfügung stünden.

Wenn man das allerdings weiterdenkt und zum Beispiel ein kompliziertes VSE mit vielen Bedienelementen annimmt, welche man dann all individuell designbar machen möchte, dann würden diese Zusatzeigenschaften nicht mehr reichen. Da wäre es toll, wenn man jedem dieser Bedienelemente ein eigenes Design zuweisen könnte. Eventuell sogar ein eigenes dynamisches Design. Das Design bekäme dann einfach einen eigenen Prefix oder so...


Außerdem wäre es nett ein Feld im VSE zu haben, wo die aktuelle Versionnummer gespeichert wird. Dieses wird dann bei Erzeugen mit abgespeichert und sollte man dann später abfragen können.
Ich habe das Problem, daß sich teilweise viele Felder in der Bedeutung ändern. Damit ist das gleiche Visuelement von einer Version zur nächsten eigentlich nicht mehr kompatibel. Jetzt könnte ich bei größeren Änderungen vermutlich immer ein komplett neues VSE erzeugen, aber dann erzeugen wir meiner Meinung nach nur VSE-Leichen...
Das wird sich mit dem Reifegrad des VSE wahrscheinlich legen, aber mit einer Versionnummer könnte man das Kompatibiltätsproblem kompensieren.

Danke und Gruß
Sven

[gaert]

Ich sag's mal so: Wenn ich EDOMI hier und heute from scratch entwickeln würde, würde ich auch einiges anders machen. Aber EDOMI ist nunmal gereift und schleppt einige Konzepte mit sich, die heute vielleicht besser design-bar gewesen wären.

Daher werde ich am Grundkonzept (Design/dyn. Designs) nichts mehr ändern, auch wenn's manchmal kompliziert erscheinen mag. Ich habe inzwischen ja 35 (oder so) VSE entwickelt, die allesamt recht gut funktionieren (wenn auch manchmal etwas komplex zu konfigurieren). Will sagen: Alles eine Sache der Routine...

[SvenA]

Ja, das kenne ich... Wenn mal es fertig hat, dann weiß man, wie man es richtig gemacht hätte.

Geht mir beim Programmierung des VSEs ja jetzt auch irgendwie so.

Gruß
Sven