[Feature Vorschlag] Eine Config für mehreren Anzeigemöglichkeiten

[daviid]

Mir ist grad ne ziemlich "gute" Idee gekommen.

Und zwar, ich hatte mal 2 verschiedene Configs, eine mit lauter Wetterbildern usw., die hat aber immer ewig zum laden gebraucht (ka. warum, hab eig 32mbit als Downlink), hab dann ne zweite gemacht wo die ganzen Bilder fehlen, und dass ist auch die die läuft.

Was mir jetzt eingefallen ist, man könnte ein neues Attribut oder ähnliches einführen mit dem man eine config sozusagen in mehrere "Unterconfigs" unterteilen kann.

    <page name="Räume">
      <switch on_value="1" off_value="0" mapping="OnOff" styling="RedGreen">
        <label>Esszimmer Tisch</label>
        <address transform="DPT:1.001" readonly="false" variant="">10/1/200</address>
      </switch>
      <break/>
      <show configs="1,2">
      <switch on_value="1" off_value="0" mapping="OnOff" styling="RedGreen">
        <label>Esszimmer Decke</label>
        <address transform="DPT:1.001" readonly="false" variant="">10/1/0</address>
        <address transform="DPT:1.001" readonly="true" variant="">10/1/33</address>
      </switch>
      </show>
    </page>

Dass würde dann bedeuten dass der Switch von Essz Decke nur in der "Unterconfig" 1 und 2 zu sehen ist, die könnte man dann so aufrufen ?config=demo&uc=1

Ich hoffe ihr versteht was ich mein.

Das würde ermöglichen z.B. eine spezielle Unterconfig fürs Handy einzurichten, wo Sachen wie das Wetter oder so ausgeblendet sind, und gleichzeitig muss man trotzdem nur eine Config Pflegen.

Was meint ihr da dazu?

[Chris M.]

Grundsätzlich gut.

Was jetzt (in SVN) schon geht könnte da relativ nahe kommen: includes

Bei einem Include erstellst Du eine Konfig die bei einer anderen per <include> als Sub-Page erscheint.
=> Du müsstest zwei normale Configs erstellen, die halt das mit einbinden oder nicht.

Würde das reichen?
Wenn nicht, was fehlt?

Was ich mir auch noch vorstellen könnte (aber noch keine Ahnung habe, wie man das am besten realisiert...) wären Seiten, die verzögert geladen werden. Bzw. erst dann geladen werden, wenn die aufgerufen werden.

[daviid]

Bei einem Include erstellst Du eine Konfig die bei einer anderen per <include> als Sub-Page erscheint.
=> Du müsstest zwei normale Configs erstellen, die halt das mit einbinden oder nicht.

Würde das reichen?
Wenn nicht, was fehlt?

Reichen würds für mich schon, aber es wäre so in der Art (also vom Prinzip her)
einfach einfacher.
Ich geh da jetzt garnicht von mir selber aus, sondern vor allem vom "Endanwender" der es so einfach wie möglich haben will


Mal noch ne andere Frage, wann solls eigentlich mal wieder nen Release geben, also dass so Funktionen wie das include auch im Release landen?

[Chris M.]

Mal noch ne andere Frage, wann solls eigentlich mal wieder nen Release geben, also dass so Funktionen wie das include auch im Release landen?

Wenn der Editor wieder geht würde ich zeitnah einen Release Candidate o.ä. raus geben an dem dann in der Breite die neuen Features getestet werden können und reifen können. Sobald das stabil ist gibt's das nächste Release.

[makki]

Ein Thema in diesem Kontext, das bei mir ganz weit oben auf der Liste steht:
Eine Art (Ajax-)request-queue, damit erst die Stati und dann die 50 diagrams geladen werden; optimalerweise natürlich erst die auf der Startseite sichtbaren..
Da gibts IMHO noch Optimierungspotential

Makki

[daviid]

Das würds natürlich auch bringen.
Gibts das schon als FeatureRequest?

Aber auf lange sicht sollte man sich glaub wirklich irgendwas überlegen um die Erstellung mehrerer "Configs" oder besser gesagt Anzeigemöglichkeiten zu ermöglichen ohne für jedes einezelne eine Config machen zu müssen, und die auchnoch einzeln "administrieren".

Die Includes sind sicher schonmal praktisch, aber ich glaube nicht dass die das "Eilheilmittel" sein werden dafür.

[Chris M.]

Feature requests stehen unter SourceForge.net: Open Automation: Feature Requests - hier darf jeder was eintragen

[makki]

Doch, gibts schon, die Idee ist nicht neu
https://sourceforge.net/tracker/inde...6&atid=1251144

Makki

[peuter]

Ich benötige auch unterschiedliche Config für verschiedene Endgeräte, jedoch eigentlich nur mit eher minimalen Änderungen, z.B. Navbars ein- oder ausblenden und dementsprechend pagelinks anzeigen oder nicht. Im Wesentlichen also erstmal nur das Ändern einzelner Attribute.
Ich hab mir dafür XSL-Regeln gebastelt, die ich für jede OS/Browser Variante definieren kann und die dann entsprechend die Config anpassen.

Funktioniert als unfertiger Prototyp eigentlich schon ganz gut. Nur ist das weit weg von Endanwederfreundlich, da selbst ich mich als Programmierer schwergetan habe, die entsprechenden Regeln zu definieren. Wäre aber auf jedenfall eine ziemlich mächtige Lösung. Ich bin in dem Bereich zwar blutiger Anfänger, aber ich denke dass man mittels XSL die Config beliebig anpassen kann.

Ein weiteres Problem könnte die Performace auf Low-End Hardware sein. Ich weiß nicht wie rechenintensiv so ein xsl prozessor ist. Allerdings macht das Ding auf einer mit dem Wiregate vergleichbaren Hardware seine Sache ohne spürbare Verzögerung. Und da kann man durch caching der erzeugten config sicher noch einiges optimieren.

[Chris M.]

Ich hab mir dafür XSL-Regeln gebastelt, die ich für jede OS/Browser Variante definieren kann und die dann entsprechend die Config anpassen.

Interessanter Ansatz.

Aber ich glaube für Anwender ist XSL nicht erstellbar.
Jedoch ein Design-Designer könnte durchaus einem Design solche Regeln mitgeben. Doch wenn man die dann schon zum Zeitpunkt der Erstellung der Installations-Pakete kennt, kann man die transformierten XMLs eigentlich im Package-Prozess mit erstellen und gleich fertig mit einpacken. Odrr?

[peuter]

Aber ich glaube für Anwender ist XSL nicht erstellbar.

Ja, wie schon gesagt nicht wirklich Endanwender tauglich. Aber eventuell kann man da eine Abstraktionsebene drüberlegen und z.B. über den Editor die Möglichkeit bieten einen Fork der User-Config für ein bestimmtes Device zu erstellen und dann einfach diverse vordefinierte Änderungen zu ermöglichen, die dann als XSL-Regel hinterlegt werden.
Wer dann etwas fortgeschrittenes braucht muss seine eigenen Regeln definieren.

Jedoch ein Design-Designer könnte durchaus einem Design solche Regeln mitgeben. Doch wenn man die dann schon zum Zeitpunkt der Erstellung der Installations-Pakete kennt, kann man die transformierten XMLs eigentlich im Package-Prozess mit erstellen und gleich fertig mit einpacken. Odrr?

Das ist doch vornehmlich für die User-Config gedacht und die kommt doch erst nach der Installation dazu. Und für ein Design so allgemeine Regeln im Vorfeld zu definieren, die dann eine beliebige Config "optimieren" halte ich für nur sehr eingeschränkt möglich. Oder hast Du an dieser Stelle was anderes gemeint?

[Chris M.]

Das ist doch vornehmlich für die User-Config gedacht und die kommt doch erst nach der Installation dazu.

Ah, sorry, hatte ich anders verstanden.

So etwas per Button im Editor mit anzubieten kann sicher nicht schaden.
Ich frage mich jedoch, wie viel mehr man damit machen kann, dass Sinn macht und nicht auch per Design-Variante zu erledigen ist. Wahrscheinlich denke ich aber nur zu eng.