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.

Changes between Version 4 and Version 5 of fr/drafts/preferences


Ignore:
Timestamp:
Jan 24, 2012, 6:13:24 PM (9 years ago)
Author:
laurentj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • fr/drafts/preferences

    v4 v5  
    11= préférences systèmes =
    22
    3 Jelix va comporter des préférences. Concretement, il s'agit d'une table contenant des couples de nom/valeurs. Et une API jPref::get('clé') et jPref::set('clé','valeur') permet de les lire ou les modifier.
     3Les 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.
    44
    5 Ici on parle de préférences systèmes, à l'opposé de préférences utilisateurs. Preferenses systèmes étant des préférences communes à tout user.
     5On 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.
     6
     7
     8
     9== API ==
     10
     11Les préférences sont récupérables et modifiables via l'API d'un nouvel objet jPref :
     12
     13 * jPref::get('clé')
     14 * jPref::set('clé','valeur')
    615
    716== stockage ==
    817
     18jPref 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)
    919
    10 Ce qui est prévue dans la table jlx_prefs
    1120
    12  * clé. formaté comme ceci de préférence : nom_module.foo.bar par exemple
    13  * valeur : la valeur (chaine)
    14  * type : type de la valeur stockée (boolean, chaine, nombre)
    15  * locale : clé de locale pour le libellé (pour l'admin)
    16  * id groupe de valeurs
    17  * r_acl_sujet et r_acl_droit : droit requis pour visualiser la pref dans l'admin
    18  * w_acl_sujet et w_acl_droit : droit requis pour modifier la pref dans l'admin
     21== support de type ? ==
    1922
    20 Sachant que droits peuvent être nulls -> modifiables par tout le monde dans l'admin.
     23FIXME:
    2124
    22 Une autre table jlx_prefs_values_group, contient les valeurs et leurs groupes (clé primaire : id groupe + valeur)
     25supporte-t-on un type de donnée ? jPref ne se contenterait pas de renvoyer une chaine mais convertirai selon le type de la pref.
    2326
    24  * id groupe
    25  * valeur
     27On aurait alors dans la base nosql, deux entrées pour chaque pref:
     28  * nom.de.la.pref.__value pour la valeur
     29  * nom.de.la.pref.__type pour le type : s->string, b->boolean, i->integer.
     30Mais ça fait deux accés à la base...
     31
     32Ou 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"
     33
     34
     35== interface d'admin ==
     36
     37Il serait bon d'avoir une interface d'administration. Mais pour cela, il faut avoir des informations supplémentaires pour chaque pref :
     38
     39  * type: son type (boolean, chaine, nombre)
     40  * locale : son libellé (ou la clé de locale pour le libellé)
     41  * group: identifiant de groupe, pour regrouper des prefs par categories (pour l'affichage)
     42  * r_acl_sujet et r_acl_droit : droit requis pour visualiser la pref dans l'admin
     43  * w_acl_sujet et w_acl_droit : droit requis pour modifier la pref dans l'admin
     44  * defaultvalue : valeur par défaut (ce qui permet de remettre la pref à sa valeur d'origine)
     45
     46
     47Sachant que les droits peuvent être nulls -> modifiables par tout le monde dans l'admin.
     48
     49
     50Et avoir des informations pour chaque groupe :
     51
     52 * id groupe (une chaine plutôt qu'un nombre)
     53 * locale libellé (peut être null)
    2654 * ordre  ordre d'affichage
    27  * locale libellé de la valeur (peut être null)
     55
     56
     57Toutes 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.
     58L'interface d'admin se contenterai alors de lire ce fichier, et générer le formulaire correspondance.
    2859
    2960= préférences utilisateur =
    3061
    31 Préférences que les utilisateurs peuvent modifier et donc dont les valeurs sont liées à un login.
     62Préférences liées aux utilisateurs.
    3263
    33 À reflechir si on fait cela. La récupération d'une valeur peut être lourde...
     64FIXME: implémentation ?
    3465
    35 table jlx_pref_user  ?
     66Dans la base nosql, on pourrait avoir deux clés pour chaque pref:
     67  * nom.de.la.pref.__user:login  pour la valeur de la pref pour le user "login"
     68  * nom.de.la.pref.__value pour la valeur générale
    3669
    37  * login
    38  * clé
    39  * valeur
     70si nom.de.la.pref.__user:login n'existe pas, on prend nom.de.la.pref.__value.
     71Mais ça peut faire deux accès à la base pour chaque pref... perf ?
    4072
    41 sachant que la valeur qu'il y a dans jlx_prefs est la valeur par défaut. Il faudrait alors peut etre ajouter dans jlx_prefs un champs booleen "modifiable" (indiquant si la pref peut etre personnalisée par le user)
     73Il faut aussi dans le preferences.ini, avoir un propriété indiquant si la pref peut être modifiée par utilisateur ou pas.
    4274
    43 Ce qui est aussi possible de faire pour améliorer les performances : avoir un champs pref dans la table des users, qui contient toutes les valeurs de prefs sous forme de tableau php serialisé. Ce champs est invalidé (vidé) à chaque modification dans la table, et regénéré à la connection suivante du user. Ainsi, cela augmente les performances : l'intérrogation des prefs ne se fait plus sur la base, mais sur un tableau php chargé et déserialisé à la connection du user.
     75