System Configuration, User Configuration et Context
13 views
Skip to first unread message
Jean-Loup Kahloun
Jan 6, 2012, 10:12:35 AM1/6/12
to civikey-dev
Suite à des modifs d’Olivier sur le Core 4.0, j’ai dû jeter un coup
d’œil du côté de de la gestion des différents niveaux de configuration
(System, User et Context), et notamment sur leur chargement dynamique.
On part du principe qu’on ne change pas dynamiquement de SystemConf,
cela ne fait pas vraiment sens, puisqu’au-dessus de la notion
d’utilisateur.
Le changement dynamique de Context cette fois-ci, on peut le faire
depuis un plugin, en passant par Context.LoadContext() (prend un
CK.Storage.IStructuredReader en parametres), tout roule de ce côté.
Par contre, on peut (on devrait pouvoir) changer de UserConf
dynamiquement (c’est-à-dire changer de profil utilisateur), ce qui
devrait trigger un changement des plugins lancés, pour que CiviKey
s’adapte à un nouvel utilisateur.
Or, dans l’architecture CiviKey, un utilisateur a un Context qui lui
est lié (le chemin vers un context se trouve dans la UserConf, mais
plusieurs utilisateurs peuvent avoir le même Context). Donc mon idée à
la base était, qui dit changement de user, dit changement de Context.
Et bien ce n’est pas aussi simple que cela. Si un ergothérapeute
modifie le layout d’un clavier, ce serait vachement bien que ce
changement puisse potentiellement se répercuter sur tous les
utilisateurs d’une machine (je dis bien d’une machine). Pour éviter
d’ajouter à la tâche de modifier tous les claviers de l’hôpital, celle
de faire cette modification pour tous les profils présents sur une
même machine (merci pour lui).
D’un autre côté, pour l’utilisation de CK-Core dans le cadre d'une
application autre que CiviKey, cela peut faire sens.
Qu’est-ce qu’on en retire ?
Décider si le changement de User entraine la sélection du Context qui
lui est lié ou si on lui set le Context courant dans sa liste de
contexts est à prendre en fonction des cas, elle se fera donc dans
CiviKey, et non dans CK.Core.
Y’a plus qu’à.
Enfin, puisqu’on ne peut pas changer de SystemConf dynamiquement, je
m’en vais de ce pas retirer LoadSystemConfiguration de l’interface
IContext, pour éviter que l’on puisse l’appeler depuis un plugin.
Jean-Loup Kahloun
d’œil du côté de de la gestion des différents niveaux de configuration
(System, User et Context), et notamment sur leur chargement dynamique.
On part du principe qu’on ne change pas dynamiquement de SystemConf,
cela ne fait pas vraiment sens, puisqu’au-dessus de la notion
d’utilisateur.
Le changement dynamique de Context cette fois-ci, on peut le faire
depuis un plugin, en passant par Context.LoadContext() (prend un
CK.Storage.IStructuredReader en parametres), tout roule de ce côté.
Par contre, on peut (on devrait pouvoir) changer de UserConf
dynamiquement (c’est-à-dire changer de profil utilisateur), ce qui
devrait trigger un changement des plugins lancés, pour que CiviKey
s’adapte à un nouvel utilisateur.
Or, dans l’architecture CiviKey, un utilisateur a un Context qui lui
est lié (le chemin vers un context se trouve dans la UserConf, mais
plusieurs utilisateurs peuvent avoir le même Context). Donc mon idée à
la base était, qui dit changement de user, dit changement de Context.
Et bien ce n’est pas aussi simple que cela. Si un ergothérapeute
modifie le layout d’un clavier, ce serait vachement bien que ce
changement puisse potentiellement se répercuter sur tous les
utilisateurs d’une machine (je dis bien d’une machine). Pour éviter
d’ajouter à la tâche de modifier tous les claviers de l’hôpital, celle
de faire cette modification pour tous les profils présents sur une
même machine (merci pour lui).
D’un autre côté, pour l’utilisation de CK-Core dans le cadre d'une
application autre que CiviKey, cela peut faire sens.
Qu’est-ce qu’on en retire ?
Décider si le changement de User entraine la sélection du Context qui
lui est lié ou si on lui set le Context courant dans sa liste de
contexts est à prendre en fonction des cas, elle se fera donc dans
CiviKey, et non dans CK.Core.
Y’a plus qu’à.
Enfin, puisqu’on ne peut pas changer de SystemConf dynamiquement, je
m’en vais de ce pas retirer LoadSystemConfiguration de l’interface
IContext, pour éviter que l’on puisse l’appeler depuis un plugin.
Jean-Loup Kahloun
Olivier Spinelli
Jan 9, 2012, 3:15:50 AM1/9/12
to civik...@googlegroups.com
Je réagis juste au sujet de:
>> Enfin, puisqu’on ne peut pas changer de SystemConf dynamiquement, je m’en vais de ce pas retirer LoadSystemConfiguration de l’interface IContext, pour éviter que l’on puisse l’appeler depuis un plugin.
Je ne suis pas certain qu'il faille le retirer... (s'il fonctionne).
Il y a-t-il quelque chose qui l'empêche de fonctionner ?
Up to me, un changement de Config System doit déclencher un rechargement de la config User appropriée (the current one of the new System Conf).
Ce n'est effectivement pas le même fonctionnement entre User et Context. J'ai, de fait, considéré que la décision de ce qu'il fallait faire suite à un rechargement de User était laissé à la discrétion de l'application (l' "hôte" qui est, ici, Civikey.exe).
On a donc deux comportements différents:
- System Config (Rechargement et/ou changement de User Config) ==> Load de la User Config
- User Config (Rechargement et/ou changement de Context) ==> Evènement à traiter par le Host (qui entraîne éventuellement un Load du Context).
Si le premier fonctionne... Autant le laisser en place (my 2 cents).
Spi
-----Message d'origine-----
De : civik...@googlegroups.com [mailto:civik...@googlegroups.com] De la part de Jean-Loup Kahloun
Envoyé : vendredi 6 janvier 2012 16:13
À : civikey-dev
Objet : [civikey-dev] System Configuration, User Configuration et Context
Jean-Loup Kahloun
Jan 27, 2012, 11:11:01 AM1/27/12
to civikey-dev
Bonjour,
Petit compte rendu de ce qui a été fait sur le thème de la user
configuration, system configuration et context :
- J'ai laissé la fonction de changement de Systemconf, elle n'est
branchée nulle part pour le moment, et ne le sera pas tant qu'on aura
pas trouvé d’intérêt à le faire.
Mais rien ne l’empêche de fonctionner, je vais faire deux-trois tests,
mais a priori tout devrait fonctionner sans problèmes.
- J'ai mis en place le changement de configuration user sur le host
(CiviKey.exe). Et là, il y a pas mal de choses à dire :
Dans son fonctionnement classique, il trigger bien un changement de
UserConf et de Context, le nouveau clavier current est chargé ( et
affiché si le plugin était lancé).
La nouvelle configuration est prise en compte, si elle spécifie qu'un
plugin doit être lancé, il l'est automatiquement.
Si un plugin avait été lancé par la précédente configuration, il est
éteint.
Par contre, si le précédent utilisateur a lancé un plugin "à la main",
celui-ci reste lancé. ( cela me paraissait plus pertinent, cela ferait
étrange de voir l'Object Explorer se fermer a chaque changement
d'utilisateur ) Ca peut être un point de configuration, mais dans
l'optique de garder CiviKey "relativement simple", j'ai préféré
éviter.
- J'ai également ajouté la possibilité de copier le context du
précédent utilisateur (lorsque l'on change de user), comme on en avait
parlé lors des messages précédents, mais j'ai laissé le code en
commentaire.
Cette popup n'est pas ergonomique. Je n'ai pas trouvé d'endroit
convenable pour la poser.
Je trouve tout de même très "advanced" de proposer de copier un
context et l'ajouter a sa propre liste de contexts. Rien que l'idée de
faire transpirer la notion de context jusqu'à l'utilisateur ne me
parait pas une bonne idée.
En plus, on n'a aucune interface pour changer de context, donc pour le
moment, copier le context de l'utilisateur précédent empêche de
revenir à notre context pre-copie.
En meetant ca en place j'ai eu une idée, si on propose de copier un
context, pourquoi ne pas également proposer de copier la user conf ?
Cela reviendrait en fait à cloner le user dans son ensemble. Plutôt
que de laisser certaines configurations non copiées.
Cela permettrait à l'ergothérapeute de configurer un poste avec les
configurations de base, et de permettre ensuite a chaque utilisateur
cloné de la modifier a sa convenance, mais sans devoir configurer
l'ensemble sur tous les postes (toujours la même idée que
précédemment, mais en prenant TOUTES les configurations d'un user, et
non celles spécifiques à un clavier).
Mais dans ce cas, comment présenter cette possibilité ? Je ne vois pas
ça au moment de changer d'utilisateur.
Le mieux serait d'avoir une fenêtre de configuration (advanced) qui
affiche les contexts et la user conf de chaque utilisateur, et de
pouvoir manager les utilisateurs et leurs différents niveaux de
configuration : copier et supprimer (exporter ?) des configurations,
via des beaux drag & drop 2.0.
Voilà le résultat de mes cogitations sur les configurations de
CiviKey, n'hésitez pas à faire des remarques et à proposer vos idées
(je sais que Spi ne s'en privera pas :-) )
Jean-Loup Kahloun.
On 9 jan, 09:15, Olivier Spinelli <olivier.spine...@invenietis.com>
wrote:
Petit compte rendu de ce qui a été fait sur le thème de la user
configuration, system configuration et context :
- J'ai laissé la fonction de changement de Systemconf, elle n'est
branchée nulle part pour le moment, et ne le sera pas tant qu'on aura
pas trouvé d’intérêt à le faire.
Mais rien ne l’empêche de fonctionner, je vais faire deux-trois tests,
mais a priori tout devrait fonctionner sans problèmes.
- J'ai mis en place le changement de configuration user sur le host
(CiviKey.exe). Et là, il y a pas mal de choses à dire :
Dans son fonctionnement classique, il trigger bien un changement de
UserConf et de Context, le nouveau clavier current est chargé ( et
affiché si le plugin était lancé).
La nouvelle configuration est prise en compte, si elle spécifie qu'un
plugin doit être lancé, il l'est automatiquement.
Si un plugin avait été lancé par la précédente configuration, il est
éteint.
Par contre, si le précédent utilisateur a lancé un plugin "à la main",
celui-ci reste lancé. ( cela me paraissait plus pertinent, cela ferait
étrange de voir l'Object Explorer se fermer a chaque changement
d'utilisateur ) Ca peut être un point de configuration, mais dans
l'optique de garder CiviKey "relativement simple", j'ai préféré
éviter.
- J'ai également ajouté la possibilité de copier le context du
précédent utilisateur (lorsque l'on change de user), comme on en avait
parlé lors des messages précédents, mais j'ai laissé le code en
commentaire.
Cette popup n'est pas ergonomique. Je n'ai pas trouvé d'endroit
convenable pour la poser.
Je trouve tout de même très "advanced" de proposer de copier un
context et l'ajouter a sa propre liste de contexts. Rien que l'idée de
faire transpirer la notion de context jusqu'à l'utilisateur ne me
parait pas une bonne idée.
En plus, on n'a aucune interface pour changer de context, donc pour le
moment, copier le context de l'utilisateur précédent empêche de
revenir à notre context pre-copie.
En meetant ca en place j'ai eu une idée, si on propose de copier un
context, pourquoi ne pas également proposer de copier la user conf ?
Cela reviendrait en fait à cloner le user dans son ensemble. Plutôt
que de laisser certaines configurations non copiées.
Cela permettrait à l'ergothérapeute de configurer un poste avec les
configurations de base, et de permettre ensuite a chaque utilisateur
cloné de la modifier a sa convenance, mais sans devoir configurer
l'ensemble sur tous les postes (toujours la même idée que
précédemment, mais en prenant TOUTES les configurations d'un user, et
non celles spécifiques à un clavier).
Mais dans ce cas, comment présenter cette possibilité ? Je ne vois pas
ça au moment de changer d'utilisateur.
Le mieux serait d'avoir une fenêtre de configuration (advanced) qui
affiche les contexts et la user conf de chaque utilisateur, et de
pouvoir manager les utilisateurs et leurs différents niveaux de
configuration : copier et supprimer (exporter ?) des configurations,
via des beaux drag & drop 2.0.
Voilà le résultat de mes cogitations sur les configurations de
CiviKey, n'hésitez pas à faire des remarques et à proposer vos idées
(je sais que Spi ne s'en privera pas :-) )
Jean-Loup Kahloun.
On 9 jan, 09:15, Olivier Spinelli <olivier.spine...@invenietis.com>
wrote:
Reply all
Reply to author
Forward
0 new messages