Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
7 Antworten auf „Gedanken zum Thema „Einstellungsspeicher““
ad *Ausprägungen des Einstellungsspeichers*
Wieso ist das Ablegen der Menüstrukturen für jeden Benutzer nicht ganz konsistent und logisch? Die existierende Grundanforderung lautet doch, dass jeder Benutzer sich sein Menü und seine Symbolleiste individuell zusammenstellen können soll. Oder meinen Sie damit, dass die Ablage zwar „allgemein netzweit“ lautet, aber immer je Benutzer gespeichert wird?
ad *Interne Repräsentation des Einstellungsspeichers*
Und welche der drei Varianten würden Sie aufgrund Ihrer Erfahrungen mit dem Einstellungsspeicher bevorzugen?
Die Inkonsistenz besteht für mich in der Festlegung der Oberflächenrechte per Nutzerklasse und im Gegensatz der verfügbaren Menüs per Nutzer. Ich hätte erwartet, dass die Menüs, deren potentielle verfügbarere Inhalt ja auch von den Oberflächenberechtigungen abhängt, dann auch per Benutzerklasse angelegt werden, ansonsten, muss ich für jeden neuen Nutzer ein individuelles Menü zusammenstellen und im Hinterkopf haben, was dieser Benutzer überhupt darf und was nicht. Wenn die Benutzerklasse eines Benutzers geändert wird (was ja theoretisch per Parametrierung möglich ist), enthält sein Menü dann unter Umständen Aktionen, die er letztendlich gar nicht mehr ausführen darf oder Aktionen, die er gemäß seiner neuen Nutzerklassen ausführen könnte sind nicht automatisch verfügbar.
Das verstehe ich soweit, dass ich den Vorschlag richtig finde, den Einstellungsspeicher auf die Benutzerklassen auszuweiten.
Allerdings habe ich die Oberflächenberechtigungen so verstanden, dass es doch gerade deren Aufgabe ist, dafür Sorge zu tragen, dass nur die Aktionen sichtbar sind, die er auch tun darf. Oder wie muss ich mir das vorstellen? Würde er jetzt z. B. einen Menüpunkt angezeigt bekommen, und erst wenn er ihn anklickt, bekommt er die Rückmeldung, dass er diese Aktion nicht ausführen darf? Falls dem so wäre, wäre es möglich, dass solche Aktionen ganz ausgeblendet werden? Denn so habe ich Ihre seitherigen Ausführungen verstanden: es ist Aufgabe des jeweiligen Plug-ins, den konkreten Umgang zu regeln und das könnte ausgrauen oder ganz deaktiveren (= ausblenden) sein oder eben das beschriebene Verhalten, auch wenn das natürlich nicht nutzerfreundlich ist.
Die Menüs funktionieren heute doch so ähnlich wie die Default-Parameter: es wird für einen Benutzer geschaut, ob es ein individuelles Menü gibt. Wenn nicht, wird das netzweite verwendet. So könnte (sollte) es auch doch zukünftig funktionieren, nur eben dass die zusätzliche Ebene der Benutzerklasse dazwischen ist.
Das Ausblenden bzw. Ausgrauen der nicht verfügbaren Aktionen erfolgt natürlich trotzdem entsprechend der Berechtigungen.
Ich muss nur immer das individuelle Nutzermenü bearbeiten, wenn die Benutzerklasse eines Nutzers geändert werden soll, oder wenn beispielsweise ein neuer Bediener hinzukommt.
Wenn die Menüs auch pro Benutzerklasse abgelegt werden sollen, könnte mann natürlich die Menüs anzeigen, soweit eines definiert ist:
nutzerspeziell
nutzerklassenspeziell
allgemein
Das würde sich dann aber auch auf die Einstellungen auswirken, da die Menüs (zumindest bisher) als Einstellungen abgelegt werden. Im Speicherdialog käme dann noch eine weitere Ebene „Benutzerklasse“ hinzu?
Im ersten Schritt würde ich die Verwendung der bestehenden Parameter beibehalten und nur die Benachrichtigungsfunktionalität nachziehen. In erster Linie aus dem Grund, da andere Anwendungen den Einstellungsspeicher individuell (unter Umgehung des Rahmenwerks) auslesen (INOVAT) und anderenfalls ein Kompatibilitätsbruch entstehen würde.
Im Hintergrund der Einstellungsschnittstelle könnte eine irgendwie kompatible Anpassung auch im Nachhinein erfolgen ohne bestehende Client-Software anpassen zu müssen, denn eigentlich sollte es einen Client nicht interessieren, wo letztendlich die Daten des Einstellungsspeichers abgelegt sind.
Ehrlich gesagt würde ich auf solche „special“-Plug-ins, die sich nicht an die Konventionen halten und sich ihre Zugänge „irgendwie hintenrum“ besorgen, nicht viel Rücksicht nehmen. Die Lösung wurde ja im Prinzip nur gewählt, weil die vorhandene zu sperrig und zu kompliziert war. Ich vermute ‚mal, außer dem genanannten Plug-in, gibt es nur sehr wenige (oder gar keine) andere Plug-ins, die nicht die API des vorhandenen Speichers nutzen? Dann müsste ja nur inovat seine Plug-ins an das neue RW 2.0 anpassen.
Ist für die interne Repräsentation denn auch eine Variante 4 denkbar, bei der der seitherige Mega-Parameter granular auf viele kleine aufgeteilt wird, ohne dynamische Objekte daraus zu machen?
Dann müsste es doch auch machbar sein, die skizzierten Methoden transparent realisieren zu können, so dass der Nutzer gar nicht den Unterschied zwischen den neuen vielen kleinen und dem alten einen großen Parameter merkt?
Der Nutzer sollte die interne Aufteilung in keinem Fall bemerken.
Für die granulare Aufteilung ohne dynamische Objekte habe ich noch keine Idee (solange man Datenverteilermittel verwendet und die Schnittstelle nicht komplett ändert). Wenn die Parameter als Datensatz mit Feldern o.ä. gespeichert werden, muss ich diesen im Datenverteiler trotzdem immer komplett übertragen.
Das Problem dieser Datenstrukturen liegt potentiell darin, dass ein Client immer erst den „alten“ Parameter ausliest, diesen lokal ändert und dann an den Datenverteiler zurücksendet. Das braucht immer eine gewisse Zeit und bei mehreren Clients gibt es keine Synchronisation.
Entgültig gelöst werden könnte dieses Problem nur mit einer zentralen Instanz, die die Synchronisation übernimmt, das kann aber das Rahmenwerk nicht bieten, eine solche Funktionalität müsste auf dem Server implementiert werden.
Bei der Verwendung vieler kleinerer dynamischer Objekte besteht das Problem theoretisch zwar auch noch, ist aber praktisch zu vernachlässigen.
ad *Ausprägungen des Einstellungsspeichers*
Wieso ist das Ablegen der Menüstrukturen für jeden Benutzer nicht ganz konsistent und logisch? Die existierende Grundanforderung lautet doch, dass jeder Benutzer sich sein Menü und seine Symbolleiste individuell zusammenstellen können soll. Oder meinen Sie damit, dass die Ablage zwar „allgemein netzweit“ lautet, aber immer je Benutzer gespeichert wird?
ad *Interne Repräsentation des Einstellungsspeichers*
Und welche der drei Varianten würden Sie aufgrund Ihrer Erfahrungen mit dem Einstellungsspeicher bevorzugen?
Zu den Menüstrukturen:
Die Inkonsistenz besteht für mich in der Festlegung der Oberflächenrechte per Nutzerklasse und im Gegensatz der verfügbaren Menüs per Nutzer. Ich hätte erwartet, dass die Menüs, deren potentielle verfügbarere Inhalt ja auch von den Oberflächenberechtigungen abhängt, dann auch per Benutzerklasse angelegt werden, ansonsten, muss ich für jeden neuen Nutzer ein individuelles Menü zusammenstellen und im Hinterkopf haben, was dieser Benutzer überhupt darf und was nicht. Wenn die Benutzerklasse eines Benutzers geändert wird (was ja theoretisch per Parametrierung möglich ist), enthält sein Menü dann unter Umständen Aktionen, die er letztendlich gar nicht mehr ausführen darf oder Aktionen, die er gemäß seiner neuen Nutzerklassen ausführen könnte sind nicht automatisch verfügbar.
Das verstehe ich soweit, dass ich den Vorschlag richtig finde, den Einstellungsspeicher auf die Benutzerklassen auszuweiten.
Allerdings habe ich die Oberflächenberechtigungen so verstanden, dass es doch gerade deren Aufgabe ist, dafür Sorge zu tragen, dass nur die Aktionen sichtbar sind, die er auch tun darf. Oder wie muss ich mir das vorstellen? Würde er jetzt z. B. einen Menüpunkt angezeigt bekommen, und erst wenn er ihn anklickt, bekommt er die Rückmeldung, dass er diese Aktion nicht ausführen darf? Falls dem so wäre, wäre es möglich, dass solche Aktionen ganz ausgeblendet werden? Denn so habe ich Ihre seitherigen Ausführungen verstanden: es ist Aufgabe des jeweiligen Plug-ins, den konkreten Umgang zu regeln und das könnte ausgrauen oder ganz deaktiveren (= ausblenden) sein oder eben das beschriebene Verhalten, auch wenn das natürlich nicht nutzerfreundlich ist.
Die Menüs funktionieren heute doch so ähnlich wie die Default-Parameter: es wird für einen Benutzer geschaut, ob es ein individuelles Menü gibt. Wenn nicht, wird das netzweite verwendet. So könnte (sollte) es auch doch zukünftig funktionieren, nur eben dass die zusätzliche Ebene der Benutzerklasse dazwischen ist.
Das Ausblenden bzw. Ausgrauen der nicht verfügbaren Aktionen erfolgt natürlich trotzdem entsprechend der Berechtigungen.
Ich muss nur immer das individuelle Nutzermenü bearbeiten, wenn die Benutzerklasse eines Nutzers geändert werden soll, oder wenn beispielsweise ein neuer Bediener hinzukommt.
Wenn die Menüs auch pro Benutzerklasse abgelegt werden sollen, könnte mann natürlich die Menüs anzeigen, soweit eines definiert ist:
Das würde sich dann aber auch auf die Einstellungen auswirken, da die Menüs (zumindest bisher) als Einstellungen abgelegt werden. Im Speicherdialog käme dann noch eine weitere Ebene „Benutzerklasse“ hinzu?
Im ersten Schritt würde ich die Verwendung der bestehenden Parameter beibehalten und nur die Benachrichtigungsfunktionalität nachziehen. In erster Linie aus dem Grund, da andere Anwendungen den Einstellungsspeicher individuell (unter Umgehung des Rahmenwerks) auslesen (INOVAT) und anderenfalls ein Kompatibilitätsbruch entstehen würde.
Im Hintergrund der Einstellungsschnittstelle könnte eine irgendwie kompatible Anpassung auch im Nachhinein erfolgen ohne bestehende Client-Software anpassen zu müssen, denn eigentlich sollte es einen Client nicht interessieren, wo letztendlich die Daten des Einstellungsspeichers abgelegt sind.
Ehrlich gesagt würde ich auf solche „special“-Plug-ins, die sich nicht an die Konventionen halten und sich ihre Zugänge „irgendwie hintenrum“ besorgen, nicht viel Rücksicht nehmen. Die Lösung wurde ja im Prinzip nur gewählt, weil die vorhandene zu sperrig und zu kompliziert war. Ich vermute ‚mal, außer dem genanannten Plug-in, gibt es nur sehr wenige (oder gar keine) andere Plug-ins, die nicht die API des vorhandenen Speichers nutzen? Dann müsste ja nur inovat seine Plug-ins an das neue RW 2.0 anpassen.
Ist für die interne Repräsentation denn auch eine Variante 4 denkbar, bei der der seitherige Mega-Parameter granular auf viele kleine aufgeteilt wird, ohne dynamische Objekte daraus zu machen?
Dann müsste es doch auch machbar sein, die skizzierten Methoden transparent realisieren zu können, so dass der Nutzer gar nicht den Unterschied zwischen den neuen vielen kleinen und dem alten einen großen Parameter merkt?
Der Nutzer sollte die interne Aufteilung in keinem Fall bemerken.
Für die granulare Aufteilung ohne dynamische Objekte habe ich noch keine Idee (solange man Datenverteilermittel verwendet und die Schnittstelle nicht komplett ändert). Wenn die Parameter als Datensatz mit Feldern o.ä. gespeichert werden, muss ich diesen im Datenverteiler trotzdem immer komplett übertragen.
Das Problem dieser Datenstrukturen liegt potentiell darin, dass ein Client immer erst den „alten“ Parameter ausliest, diesen lokal ändert und dann an den Datenverteiler zurücksendet. Das braucht immer eine gewisse Zeit und bei mehreren Clients gibt es keine Synchronisation.
Entgültig gelöst werden könnte dieses Problem nur mit einer zentralen Instanz, die die Synchronisation übernimmt, das kann aber das Rahmenwerk nicht bieten, eine solche Funktionalität müsste auf dem Server implementiert werden.
Bei der Verwendung vieler kleinerer dynamischer Objekte besteht das Problem theoretisch zwar auch noch, ist aber praktisch zu vernachlässigen.