Hallo @gaert,
in meinen Augen hat das Tabellen/Liste- Visu-Element hohes Potential.
Leider ist es aktuell zwar schon sehr mächtig, aber zu wenig steuerbar.
Ich fasse hier mal zusammen, was ich noch toll fände.
- Beeinflussbarkeit der Spaltenbreite der einzelnen Spalten
- Spalten unsichtbar schalten (für Sortierung, Schlüsselbegriff)
- Listenbezeichnung (zwischen den Pfeilen), geht aber auch mit zusätzlichem Visu-Element
- Reaktion auf Anklicken einer Zelle (Rückgabe-KOs Zeileninhalt und Spaltennummer), damit könnten Löschfunktionen / Sortieränderungen / Detailsprünge ausgelöst werden
Leider ist mir auch bewusst, dass für dich EDOMI hauptsächlich zur Steuerung von KNX entwickelt wurde und nicht um irgendwelche anderen Infos darzustellen. Das geht hier natürlich in eine etwas andere Richtung. Nachteil am EDOMI-Konzept ist hier leider auch, dass es keine userspezifischen KOs gibt, d.h. dass sich oben beschriebene Aktionen wie Detailanzeige / Sortierung auf alle angemeldeten Geräte auswirken würde. Das bedeutet wenn ich in der einen Visu die Detailansicht in der VISU-Seite aufbaue und ein anderer startet die Detailanzeige von einer anderen Zeile, würde meine Ansicht verändert werden. Damit könnte ich aber leben.
Ideen für solche Tabellen:
Terminübersicht (Müll, Geburtstage....)
Spritpreise (sortierung nach Entfernung / Preis)
Kameraarchiv mit Vorschaubildern und Löschfunktion
Wettervorschau über mehrere Tage
Das Schöne ist halt einfach, ich bin nicht auf eine gewisse fest definierte Anzahl an Zeilen gebunden und man kann Daten schnell aus einem LBS direkt in das Visuelement bringen.
Problem für das ich noch keinen Lösungsansatz habe: Wenn die Daten sehr umfangreich sind, wie man das Nachladen geschickt realisieren könnte ohne alle Daten auf einmal in das Visuelement per KO zu schicken. Grundsätzlich sehe ich aber eher sehr begrenze Datenmengen als Anwendungsfall.
In diesem Zusammenhang gährt auch noch ein Wunsch länger in mir:
Bereitstellung einer Funktion zum Setzen / Lesen interner und externer KOs aus einem LBS heraus. Einfachstes Beispiel wäre eine externe Schaltliste wie vom HS evtl. bekannt. Solange die benötigten KOs bekannt sind, kann man das natürlich mit einigem Aufwand auch mit einer Logik realisieren, sobald aber ein neues KO angesprochen werden soll, muss man die Logik anpassen und das Projekt neu aktivieren.
Bind mal auf dein Feedback gespannt, evtl. brennst du nach der Doku ja wieder auf andere Herausforderungen.
in meinen Augen hat das Tabellen/Liste- Visu-Element hohes Potential.
Leider ist es aktuell zwar schon sehr mächtig, aber zu wenig steuerbar.
Ich fasse hier mal zusammen, was ich noch toll fände.
- Beeinflussbarkeit der Spaltenbreite der einzelnen Spalten
- Spalten unsichtbar schalten (für Sortierung, Schlüsselbegriff)
- Listenbezeichnung (zwischen den Pfeilen), geht aber auch mit zusätzlichem Visu-Element
- Reaktion auf Anklicken einer Zelle (Rückgabe-KOs Zeileninhalt und Spaltennummer), damit könnten Löschfunktionen / Sortieränderungen / Detailsprünge ausgelöst werden
Leider ist mir auch bewusst, dass für dich EDOMI hauptsächlich zur Steuerung von KNX entwickelt wurde und nicht um irgendwelche anderen Infos darzustellen. Das geht hier natürlich in eine etwas andere Richtung. Nachteil am EDOMI-Konzept ist hier leider auch, dass es keine userspezifischen KOs gibt, d.h. dass sich oben beschriebene Aktionen wie Detailanzeige / Sortierung auf alle angemeldeten Geräte auswirken würde. Das bedeutet wenn ich in der einen Visu die Detailansicht in der VISU-Seite aufbaue und ein anderer startet die Detailanzeige von einer anderen Zeile, würde meine Ansicht verändert werden. Damit könnte ich aber leben.
Ideen für solche Tabellen:
Terminübersicht (Müll, Geburtstage....)
Spritpreise (sortierung nach Entfernung / Preis)
Kameraarchiv mit Vorschaubildern und Löschfunktion
Wettervorschau über mehrere Tage
Das Schöne ist halt einfach, ich bin nicht auf eine gewisse fest definierte Anzahl an Zeilen gebunden und man kann Daten schnell aus einem LBS direkt in das Visuelement bringen.
Problem für das ich noch keinen Lösungsansatz habe: Wenn die Daten sehr umfangreich sind, wie man das Nachladen geschickt realisieren könnte ohne alle Daten auf einmal in das Visuelement per KO zu schicken. Grundsätzlich sehe ich aber eher sehr begrenze Datenmengen als Anwendungsfall.
In diesem Zusammenhang gährt auch noch ein Wunsch länger in mir:
Bereitstellung einer Funktion zum Setzen / Lesen interner und externer KOs aus einem LBS heraus. Einfachstes Beispiel wäre eine externe Schaltliste wie vom HS evtl. bekannt. Solange die benötigten KOs bekannt sind, kann man das natürlich mit einigem Aufwand auch mit einer Logik realisieren, sobald aber ein neues KO angesprochen werden soll, muss man die Logik anpassen und das Projekt neu aktivieren.
Bind mal auf dein Feedback gespannt, evtl. brennst du nach der Doku ja wieder auf andere Herausforderungen.
Die Visu wird quasi vollständig in Javascript (also Clientseitig) abgewickelt, daher können nicht beliebige KOs in eine Liste/Tabelle aufgenommen werden. Natürlich würde es auch anders gehen, aber das ufert das Ganze schnell aus...
Denkbar wäre aber ein zusätzliches Visuelement, dass eben auch komplexere Möglichkeiten bietet - dieses würde dann aber in PHP realisiert werden müssen (wie z.B. Diagramme).
Kommentar