wiki:fr/drafts/preferences
developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

préférences systèmes

Les préférences sont des options de configurations qui sont modifiés au cours de la vie de l'appli. C'est donc différent des options de configurations se trouvant dans les fichiers de configurations ini des points d'entrées (et de defaultconfig.ini.php), qui, elles, sont à priori immutable dans la vie de l'application.

On distingue deux types de préférences : les préférences générales, et les préférences utilisateurs. Dans un premier temps, il n'y aura que les préférences générales.

API

Les préférences sont récupérables et modifiables via l'API d'un nouvel objet jPref :

  • jPref::get('clé')
  • jPref::set('clé','valeur')

stockage

jPref utilise jKvDb pour le stockage. Il utilisera un profil "jpref" (FIXME: il faudrait un profil jpref par défaut.. Pour la migration de version, créer ce profil automatiquement)

support de type ?

FIXME:

supporte-t-on un type de donnée ? jPref ne se contenterait pas de renvoyer une chaine mais convertirai selon le type de la pref.

On aurait alors dans la base nosql, deux entrées pour chaque pref:

  • nom.de.la.pref._value pour la valeur
  • nom.de.la.pref._type pour le type : s->string, b->boolean, i->integer.

Mais ça fait deux accés à la base...

Ou alors on serialize/deserialize ? Ou alors on a un flag en début de chaine. La première lettre indique le type. Ex de valeur "s|la chaine", "b|true","i|123"

interface d'admin

Il serait bon d'avoir une interface d'administration. Mais pour cela, il faut avoir des informations supplémentaires pour chaque pref :

  • type: son type (boolean, chaine, nombre)
  • locale : son libellé (ou la clé de locale pour le libellé)
  • group: identifiant de groupe, pour regrouper des prefs par categories (pour l'affichage)
  • r_acl_sujet et r_acl_droit : droit requis pour visualiser la pref dans l'admin
  • w_acl_sujet et w_acl_droit : droit requis pour modifier la pref dans l'admin
  • defaultvalue : valeur par défaut (ce qui permet de remettre la pref à sa valeur d'origine)

Sachant que les droits peuvent être nulls -> modifiables par tout le monde dans l'admin.

Et avoir des informations pour chaque groupe :

  • id groupe (une chaine plutôt qu'un nombre)
  • locale libellé (peut être null)
  • ordre ordre d'affichage

Toutes ces informations pourrait être dans un fichier preferences.ini dans var/config. il serait rempli par les scripts d'install des modules, via un objet jPrefAdmin. L'interface d'admin se contenterai alors de lire ce fichier, et générer le formulaire correspondance.

préférences utilisateur

Préférences liées aux utilisateurs.

FIXME: implémentation ?

Dans la base nosql, on pourrait avoir deux clés pour chaque pref:

  • nom.de.la.pref._user:login pour la valeur de la pref pour le user "login"
  • nom.de.la.pref._value pour la valeur générale

si nom.de.la.pref.__user:login n'existe pas, on prend nom.de.la.pref.value. Mais ça peut faire deux accès à la base pour chaque pref... perf ?

Il faut aussi dans le preferences.ini, avoir un propriété indiquant si la pref peut être modifiée par utilisateur ou pas.

Last modified 9 years ago Last modified on Jan 24, 2012, 6:14:25 PM