préférences systèmes

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.

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.

stockage

Ce qui est prévue dans la table jlx_prefs

• clé. formaté comme ceci de préférence : nom_module.foo.bar par exemple
• valeur : la valeur (chaine)
• type : type de la valeur stockée (boolean, chaine, nombre)
• locale : clé de locale pour le libellé (pour l'admin)
• id groupe de valeurs
• 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

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

Une autre table jlx_prefs_values_group, contient les valeurs et leurs groupes (clé primaire : id groupe + valeur)

• id groupe
• valeur
• ordre ordre d'affichage
• locale libellé de la valeur (peut être null)

préférences utilisateur

Préférences que les utilisateurs peuvent modifier et donc dont les valeurs sont liées à un login.

À reflechir si on fait cela. La récupération d'une valeur peut être lourde...

table jlx_pref_user ?

• login
• clé
• valeur

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)

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.