[sexy] error_handler
by Denis Jean-Christian
Hello les (non) vacanciers,
J'ai fini les quelques fixes que je savais faire sur la branche
"default" et je suis retourné sur la branche "sexy". Ce mail me permet
de faire une petite mise au propre de mes réflexions sur la gestion des
erreurs et surtout d'avoir un petit coup de main ;-)
Je me penche donc sur la mise en place d'un gestionnaire d'erreur pour
TOUT Dotclear, en effet aujourd'hui il y a un peu tout est n'importe
quoi comme manière de lever des erreurs:
- Erreur de lancement avec __error(),
- Erreur interface avec core->error(),
- Erreur divers avec throw new Exception(),
- Erreur style deprecated (comme dans dcSettings) avec trigger_error(),
- ETC...
Avec également encore des différences avec les modes DC_DEBUG, CLI_MODE, ...
Mon but est que tout passer par un seul et même endroit puis d'y
redistribuer après, cela faciliterait la gestion des erreurs et
l'ouverture aux plugins, ou autres gestionnaires de backoffice et aussi
les log en mail/text/base...
Quelques limites se dessinent:
- Pas forcément compatible avec l'existant (surtout pour les plugins),
- Même si l'handler est définie très tôt certaines erreurs risquent
d'être levées avant,
- Certaines erreurs ne peuvent pas être loguées en base car appelées
trop tôt ou dû à la base,
- Pas forcément possible d'utiliser des plugins pour les même raisons
Pour l'instant je n'ai rien coder, je fouille un peu partout pour voir
ce qu'il se fait, si vous avez des avis/idées je suis preneur !
Cordialement,
JC|au chaud
10 years, 8 months
sexy et formfilters
by Dsls
Re,
Tant qu'on y est, je fusionne formfilters avec la branche sexy ?
--
Bruno
11 years, 4 months
[Pub] Plugin agora
by Greg
Hello,
J'ai remis récemment un coup de fouet au plugin agora.
Derrière cette extension se cache les fonctionnalités suivantes :
- Création d'utilisateur depuis l'accès public du blog via un mécanisme
d'envoi d'emails
- L'authentification des utilisateurs pour ajouter du contenu : billets
et/ou messages (Les messages ne sont pas des commentaires, c'est une
nouvelle table)
- Un paquet d'options qui permet de fabriquer une espèce de wiki, un vague
machin qui serait une espèce de forum.
Vous pouvez l'essayer sans l'installer ici : http://dleds.net/labs
Vous pouvez télécharger une version là : http://dleds.net/labs/media
Vous pouvez en discuter ici ou là-bas :)
--
Greg
11 years, 6 months
[Sexy] Fusion de plugins
by Dsls
Yo,
Maintenant que les catégories vont partir en plugin, que les tags sont
déjà un plugin, je propose de libérer la table dc_meta, et de
fusionner catégories/tags en un seul et unique plugin : taxonomy.
En pratique, les 2 tables dc_meta et dc_category vont laisser la place
à 3 tables, et de nouveaux concepts :
* Les vocabulaires
* les termes.
Un vocabulaire définit un groupe de métadonnées pour les billets. Par
exemple : "catégories", "tags", ... ce vocabulaire définit aussi la
méthode de rattachement des métadonnées au billet : valeur unique ou
multiple, organisation hiérarchique (cat) ou à plat (tag).
Un terme est un élément de vocabulaire (ex : catégorie, tag). Un terme
peut être rattaché à 0 ou plusieurs billets, et un billet peut
posséder 0 ou plusieurs termes.
En klingon, on aura donc 3 tables : dc_taxvoc, dc_taxterm, dc_taxpost.
* dc_taxvoc décrit un vocabulaire donné, avec ses propriétés. Un
vocabulaire est rattaché à un blog_id. On y stocke aussi le début
d'url qu'on veut stocker, pour afficher coté public les listes de
termes (ex : categories, tags), et les billets ayant un terme donné
(ex : category, tag).
* dc_taxterm décrit un terme de vocabulaire. Il est rattaché à un
vocabulaire. On y stocke aussi une url donnée pour lister les billets
ayant ce terme (on pourra ainsi définir une URL différente du nom.
Pratique pour les URLHandlers de tags avec accents par exemple)
* dc_taxpost décrit les liens entre les termes et les billets. J'y
vois pour l'instant seulement 2 colonnes : post_id et term_id
Je me suis inspiré de ce que font les copains de chez drupal. Chez
drupal, il y a une table de plus (tax_hierarchy) qui définit les
relations père-fils, que je remplace par des colonnes left/right comme
c'est le cas actuellement pour les catégories.
Il ne devrait pas être compliqué ensuite, de faire une moulinette
d'import des tags/catégories actuels, et de créer 2 classes "legacy"
singeant dcMeta et dcCategory...
Quant à la table dc_meta, plutôt que de la faire disparaître, le but
serait plutôt de la convertir en quelque chose de plus light, ie.
gérer des propriétés additionnelles des billets (ce que fait mymeta
aujourd'hui).
--
Bruno
11 years, 8 months
[Sexy] Commentaires en plugin - évolution
by Dsls
Re,
Concernant le futur plugin "commentaires" de la branche sexy,
j'envisage d'ajouter une colonne user_id à la table dc_comment.
Objectif : permettre les commentaires "authentifiés", ie. chaque
utilisateur déclaré dans le blog pourra poster des commentaires via
son compte.
Cela aura comme pré-requis au niveau du core une ouverture des
authentifications/inscriptions des utilisateurs coté public (agora
avait ouvert la voie de ce coté-là, autant généraliser l'approche).
Et, tant qu'à faire, permettre aux admins de blog de choisir les mode
de commentaires autorisés (authentifié uniquement, ou pas).
--
Bruno
11 years, 8 months
Re: [Dotclear Dev] [sexy] webperf et url avec ?pf=foo.css ou ?pf=bar.js
by Jean-Christian Denis
De toute façon pour moi le fichier load_plugin_file est a intégrer dans quelque chose de plus standard/générique comme un URL handler ;-) moins y a de bazard et plus c'est réutilisé, plus ça me plais!
Dsls <dsls(a)morefnu.org> a écrit :
>> Ah non, il est hors de question d'ouvrir ce répertoire aux 4 vents, je parle
>> juste de créer un urlhandler dédié qui sert les fichiers de ces
>> répertoires.on afficherait donc exactement la même chose qu'aujourd'hui,
>> avec les mêmes contrôles, mais avec des url plus jolies...
>
>
>Tiens, détail amusant avec l'index.php?pf=plugin/fichier : il sert la
>page même si le plugin est désactivé.
>
>On peut donc même s'amuser à lister les plugins installés sur un blog
>en testant à l'aveugle index.php?pg=<plugin>/icon.png, et listant tous
>les plugins voulus.
>
>Je pense donc au contraire que restreindre les fichiers qu'on peut
>servir coté public à un sous-répertoire public/ d'un plugin sera plus
>sécurité qu'actuellement :)
>
>--
>Bruno
>_______________________________________________
>Dev mailing list
>Dev(a)list.dotclear.org
>http://ml.dotclear.org/listinfo/dev
11 years, 8 months
[sexy] nightly & wizard
by Denis Jean-Christian
Chez moi (sous wamp) l'install de la nightly de la branche sexy par le
wizard fait un joli timeout, et apparemment avant la création des
tables. Et chez vous ?
Cordialement,
JC|trigger_error
11 years, 8 months
[Sexy] Nouveau type "serial" dans dbschema
by Dsls
Hello,
On va commencer doucement le cassage en douceur (et en profondeur) du core.
Comme discuté la semaine dernière, je vais introduire le type "serial"
dans dbschema. Cela signifie la fin à court terme de ces hideux lock
de table dans dotclear, au profit de colonnes autoincrémentées...
--
Bruno
11 years, 8 months
