Struktur der CV config (Allgemein)

[vlamers]

Guten morgen,

Ich hatte gestern angefangen meine visu zu überarbeiten, da diese relativ verschachtelt ist und einige objekte öfter vorkommen hatte ich mir die Frage gestellt warum jedes Objekt an Ort und Stelle definiert sein muss.
Warum nimmt man nicht alle benötigten Objekte und schiebt sie ganz an den Anfang? Also im Editor und in der xml.
So könnte man alles grundsätzliche dort definieren.

Als Beispiel ein Diagramm:
<objects>
<object name="test" grid-color="white">
<axis line-color="yellow" ....><rrd=wohnz_temp"/><label...> usw
<axis....>
...
</object>
</objects>
....
....

<page blabla>
<object="test" series="week"/>

So wäre alles allgemeine global definiert und nur die Feinheiten vor Ort.
Wäre das nicht übersichtlicher im großen und ganzen?
Jetzt habe ich ein paar Diagramme doppelt definiert popup inline und info. Bei switches und Multitriggern das selbe.
Für mich persönlich wäre das übersichtlicher (auch im Editor) muss aber natürlich nicht für die Entwickler und die Allgemeinheit so sein.

Gruß

Gesendet von meinem GT-N7100 mit Tapatalk 2

[Chris M.]

Da muss man trennen zwischen Einmal-Aufwand (Erstellen der Config), Lade-Aufwand (also jedes mal, wenn die Visu geladen wird) und Laufzeit-Aufwand (als was kontinuierlich Rechenzeit und somit Strom kostet) unterscheiden.

Die gute Nachricht vorne weg: Der Laufzeit-Aufwand ist davon unabhängig.

Dein Vorschlag soll den Einmal-Aufwand reduzieren, insb. bei der Verwendung eines klassischen Text- oder XML-Editors.
(Bei einem Text-Editor der mit Code-Schnipseln arbeitet oder gar einem optimierten integrierten Editor kann man dieses Verhalten trotzt klassischer Config wohl ganz oder zumindest teilweise nachbilden).

Der Lade-Aufwand wird durch diesen Vorschlag jedoch erhöht, denn nun muss zuerst die Object-Section verarbeitet werden und dann beim Erstellen des DOM immer wieder bei den Objects nachgeschlagen werden.
(Man muss aber ehrlich bleiben und sagen, dass der Overhead zwar da, aber dennoch ziemlich gering ist)

Nun muss man das Optimum finden und zwischen den Vor- und Nachteilen abwägen.

Meine Tendenz geht zum lassen, wie's ist. Aber es ist wirklich nur eine Tendenz, d.h. wenn's jemand eincheckt würde ich es nicht schreiend wieder rauswerfen... Aber implementieren werde ich es wohl auch nicht.

[netzkind]

AW: Struktur der CV config (Allgemein)

Abgesehen davon, dass ich mir nicht so recht vorstellen kann wie das Format aussehen soll (id und ref? Der Vorschlag mit <object="test"> dürfte nicht klappen, da der Tag-Name keine Eigenschaften haben kann), werden wir damit bei den meisten nicht-Programmierer-Anwendern keine Freude verursachen.

Ich denke das macht eine Einsteiger-config unnötig kompliziert ("Wieso muss ich das Diagramm erst einmal definieren, und dann noch sagen wo es hin soll?").

Die Option haben? Vielleicht ja, aber auf keinen Fall würde ich sowas als "the way to go" einsetzen wollen.

Grüße,
Julian

[vlamers]

AW: Struktur der CV config (Allgemein)

Ok bin schon überstimmt

Wäre nur für mich logischer(muss nicht auf die Allgemeinheit zutreffen). Bin auch weit entfernt davon ein programmierer zu sein .
Mit dem Editor ist es ja so auch kein Problem. Man kann mit copy & paste ja alles recht einfach vervielfältigen.
Es ist dann nur relativ unübersichtlich, und ich hatte Sorge das die config unnötig fett wird.

Die performance auf allen meinen Android Browsern ist recht träge, bin noch auf der Suche wo das her kommt.
Am Endgerät sollte es nicht scheitern (Verbindung wlan 56MBit, dual core (sony)) im heimischen Lan, kein Internet.

Gruß

Gesendet von meinem GT-N7100 mit Tapatalk 2

[henfri]

Hallo,

ich hatte soetwas auch einmal vorgeschlagen:
https://knx-user-forum.de/cometvisu/...templates.html

Gruß,
Hendrik