Action-based extension of user representation: Unterschied zwischen den Versionen
K (Link Anchor) |
K (Link Target) |
||
Zeile 2: | Zeile 2: | ||
== Prinzip == | == Prinzip == | ||
Jede verfügbare Funktion ist in einer Webanwendung entweder über Javascript auf dem Client oder eine URL erreichbar. In beiden Fällen gelten für den betrachteten Fall die gleichen Bedingungen (authentifizierter Nutzer ist bekannt) und das selbe Vorgehen kann gewählt werden. Die Anwendung kann prüfen, ob ein zu einem Nutzer alle notwendigen Informationen bekannt sind (d.h. im Nutzerobjekt als Attributwerte beschrieben). Ist dies der Fall, wird die Funktion ausgeführt. Ist dies nicht der Fall, kann der Drops Microservice über die Informationen (identifiziert über Attributbezeichnungen) informiert werden, die zu dem aktuellen Nutzer fehlen. Drops kann anschließend ein Formular zur Eingabe der fehlenden Informationen zurückgeben, welches durch die Anwendung ausgegeben wird. Um Drops die volle Kontrolle über das Formular geben zu können, wird hier auf das Konzept der [[ | Jede verfügbare Funktion ist in einer Webanwendung entweder über Javascript auf dem Client oder eine URL erreichbar. In beiden Fällen gelten für den betrachteten Fall die gleichen Bedingungen (authentifizierter Nutzer ist bekannt) und das selbe Vorgehen kann gewählt werden. Die Anwendung kann prüfen, ob ein zu einem Nutzer alle notwendigen Informationen bekannt sind (d.h. im Nutzerobjekt als Attributwerte beschrieben). Ist dies der Fall, wird die Funktion ausgeführt. Ist dies nicht der Fall, kann der Drops Microservice über die Informationen (identifiziert über Attributbezeichnungen) informiert werden, die zu dem aktuellen Nutzer fehlen. Drops kann anschließend ein Formular zur Eingabe der fehlenden Informationen zurückgeben, welches durch die Anwendung ausgegeben wird. Um Drops die volle Kontrolle über das Formular geben zu können, wird hier auf das Konzept der [[Dynamic UI Fragment Composition#Widgets|Widgets]] zurückgegriffen. |
Version vom 31. Mai 2017, 12:14 Uhr
Dem Prinzip der Open Participation bei VcA gerecht werdend, sollen Nutzer im Rahmen der Registrierung so wenig Informationen wie nötig angeben müssen. Einige Aktivitäten im Pool² erfordert jedoch mehr Wissen über den Nutzer. So wird etwa bei der Anmeldung für ein Festival die Handynummer und das Geburtsdatum benötigt. Die angestrebte Microservice Architektur soll es ermöglichen dynamisch neue Funktionen dem Pool² hinzuzufügen. Somit kann der Pool² zur Laufzeit um Funktionen erweitert werden die mehr Informationen über den authentifizierten Nutzer erfordern, als dieser bisher angegeben hat. Diesem Problem begegnet das vorliegende Konzept mit einer dynamischen Erweiterung der Stammdaten des Nutzers immer zu genau dem Zeitpunkt, zu dem der Nutzer eine Funktion nutzen möchte. Dabei wird der Datensatz stets nur um die fehlenden Informationen erweitert.
Prinzip
Jede verfügbare Funktion ist in einer Webanwendung entweder über Javascript auf dem Client oder eine URL erreichbar. In beiden Fällen gelten für den betrachteten Fall die gleichen Bedingungen (authentifizierter Nutzer ist bekannt) und das selbe Vorgehen kann gewählt werden. Die Anwendung kann prüfen, ob ein zu einem Nutzer alle notwendigen Informationen bekannt sind (d.h. im Nutzerobjekt als Attributwerte beschrieben). Ist dies der Fall, wird die Funktion ausgeführt. Ist dies nicht der Fall, kann der Drops Microservice über die Informationen (identifiziert über Attributbezeichnungen) informiert werden, die zu dem aktuellen Nutzer fehlen. Drops kann anschließend ein Formular zur Eingabe der fehlenden Informationen zurückgeben, welches durch die Anwendung ausgegeben wird. Um Drops die volle Kontrolle über das Formular geben zu können, wird hier auf das Konzept der Widgets zurückgegriffen.