[DISKUSSION] Optional benötigte Eingänge im LE ausblenden

[Dragonos2000]

Bei der Entwicklung größerer/komplexerer Logikbausteine komme ich immer wieder an den Punkt, Eingänge für eher optionale Funktionen/Parameter ausblenden zu können, wie das schon bei den Ausgängen möglich ist, um die Übersichtlichkeit zu erhöhen und die Komplexität für den Standardfall klein zu halten.
Es gibt zwar diese in beliebieger Anzahl erzeugbaren Eingänge, diese funktionieren allerdings nicht mit allen Logikbausteinen und decken auch den Usecase nicht ab.
Im Prinzip stelle ich es mir so vor, dass ich einen Eingang anlegen kann, der durch den Level mit einem Standardwert vorbelegt ist, der aber zunächst nicht auf der linken Seite eines Logikblocks sichtbar ist (er wird zwar in der Logik erzeugt, aber ausgeblendet). Somit kann ich diesen Eingang/Level dann auch mit beliebigen Logikbausteinen verwenden. Durch das "plus" unten kann ich dann den Eingang sichtbar machen/ auf der linken Seite des Logikblocks hinzufügen und dann normal nutzen, Standardwert überschreiben...

Wie geht es denn anderen? Meinungen?

[Robert_Mini]

Sehe das genauso. Scheint zwar vielleicht nicht als dringendstes Thema, aber wenn mann größere Logiken baut bzw. diese auch teilt, dann wäre diese Option sehr wünschenswert => Übersichtlichkeit, Flexibilität.
Ich habe auch das Gefühl, dass der LE das schon großteils kann, aber irgendwo eine kleine Schraube noch fehlt.

lg
Robert

[Dragonos2000]

Ja, das stimmt. Du kannst bspw. auch bei den Eingängen bereits ein "?" anhängen, dann werden die im Frontend entsprechend berücksichtigt und ausgeblendet. Nur beim Speichern gibt es dann einen Fehler...
Ich habe allerdings den Eindruck, dass das nicht nur kosmetisches Problem ist (einblenden/ausblenden), sondern auch beim Parsing ein derartiger Eingang gar nicht erzeugt wird und es deswegen mit einigen Logikbausteinen bzw. beim speichern dann kracht.

[StefanW]

Hi Jochen und Robert,

es geht hier vor allem eine Funktion für Custom Logiken?

lg

Stefan

[Dragonos2000]

@StefanW Ja, richtig. Es geht um Custom-Logiken. Wobei das durchaus auch ein Mehrwert für OOTB Bausteine bringen kann. Bei den Ausgängen nutzt Ihr sowas bzw. funktioniert sowas bereits...

[Robert_Mini]

Anlässlich des Bewässerungsbausteins muss ich für diese Erweiterung pushen! Hier mal der Vergleich für den Baustein mit/ohne optionalen Ein/Ausgängen. Die Ausgänge sind schon dynamisch hinzufügbar, bei den Eingängen fehlt diese Option, obwohl es bei den Arrays schon geht!

Wobei eine Spezialität zu beachten ist: bei ausgeblendeten Eingängen, sollte der Variablenwert des Levels nicht vom Eingang überschrieben werden, da man die Defaultwerte für den ausgeblendeten Fall auch <> 0 braucht. Sonst müsste man für ausgeblendete Werte mit Latch was basteln.

Das würde dann so im Vergleich aussehen (die Ausgangsseite ist original, die Eingangsseite habe ich im Code auskommentiert):

Bewässerung_Ventil_minimiert.png

Aktuell:

Bewässerung_Ventil.png

[Dragonos2000]

Ist ein gutes Beispiel. Dem Neueinsteiger wird es dann erstmal schwindelig und er verliert leicht die Lust (zumindest geht mir das so), obwohl der Baustein ganz einfach ist, wenn man die optionalen Funktionen einfach weg lässt.
Im Idealfall lässt sich das sogar gruppiert ein-/ausblenden. Im Beispiel oben könnte das bei den Ausgängen sein:
"Runtime" als Auswahl und das blendet dann "Runtime[sec]" und "Runtime [min]" ein bzw. aus
"Time left" als Auswahl und das blendet dann "Time left [sec]" und "Time left [min]" ein bzw. aus

[StefanW]

Hi Jochen,

Dem Neueinsteiger wird es dann erstmal schwindelig und er verliert leicht die Lust

Wirklich, weil manchmal habe ich den Eindruck, dass unsere Logik als "nicht ausreichend mächtig" erachtet wird, weil es dort keine Screenshots gibt wie solche hier (für Edomi):




Die Frage ist schon, ob die vielen Vereinfachungen die wir implementiert haben (Auto-Convert, Aufbereitung im Subsystem, Verknüpfungen im Objektsystem) so dass man beim Timberwolf Server gar nicht mehr soviel Logik braucht, uns wirklich am Ende gut tun, weil neue Nutzer dann meinen, dass der TWS keine starke Logik hat. Weil von den anderen Dingen, weiß man "draußen" nichts...

lg

Stefan

[starwarsfan]

Hallo miteinander,

naja, werden hier nicht wieder mal Äpfel mit Birnen verglichen?

Die Komplexität einzelner Bausteine hat doch erstmal nichts damit zu tun, auf welche Art und Weise diese miteinander verknüpft werden!? Hier hat der LE des TW eben einen gänzlich anderen Ansatz, als ihn bspw. Edomi verfolgt. Von der "Mächtigkeit" der Logik-Engine ganz zu schweigen, wie auch immer man diese erfassen oder messen möchte.

Just my two cents, aus den TW-Edomi-Vergleichen bin ich raus...

[gbglace]

Das eine große Menge zur Verängstigung von Nutzern führt würde ich nicht sagen, es zeigt nur das eben eine Menge Logik in kompakte Form mit dem TWS machbar ist.

Eingänge zu Optionalisieren in der Ansicht ist sicher ein schickes Feature, aber muss wahrlich nicht in der Prio oben liegen. Da finde ich es auch erstmal besser eher zu zeigen was alles geht. Wenn der TWS und dessen Logik gut angenommen ist kann man sowas auch noch für etwas mehr Übersichtlichkeit einbauen.

Da kommen bestimmt mehr fragen wo muss ich klicken um Den Eingang zu finden als Hilfe da sind zu viel Brauch ich nicht hab Angst da was falsch zu machen. Eine ordentliche Doku eines Bausteine sollte den Eingang ausreichend gut beschrieben das dann auch jeder schnell entscheiden kann ob er den nutzen will ja /nein.