nulib-base/php/src/output/TODO.md

nulib\output

• dans msg::action($m, function() {}), bloquer la marque pour empêcher d'aller plus bas que prévu. comme ça s'il y a plusieurs success ou failure dans la fonction, c'est affiché correctement.

• possibilité de paramétrer le nom du fichier destination pour faire une rotation des logs

  • lors de la rotation, si l'ouverture du nouveau fichier échoue, continuer à écrire dans l'ancien fichier
  • ou alors un moyen pour ré-ouvrir la sortie, afin de pouvoir indiquer à un long running process qu'une rotation a eu lieu

• dans StdMessenger::resetParams(), [output] peut être une instance de StdOutput pour mettre à jour $out ET $err, ou un tableau de deux éléments pour mettre à jour séparément $out et $err

• vérifier que la date affichée pour un TITLE est celle à laquelle l'appel a été fait, même si le premier événement en dessous arrive bien plus tard

• pareil pour action: sauf si c'est une seule ligne, la date de action est la date du premier appel, alors que la date de $result est celui du result si c'est affiché sur une autre ligne

• réorganiser pour que msg:: attaque un proxy dans lequel est configuré un ensemble standard de sorties: say, log, debuglog

  • --aD, --av, --aq, --asilent pour les valeurs d'ajustement qui sont un incrément à la valeur courante (+2, +1, -1, -2)
  • --yD, --yv, --yq, --ysilent, -D, -v, -q, --silent pour say
  • --lD, --lv, --lq, --lsilent pour log, -L:, --L l'active
  • --DD, --Dv, --Dq, --Dsilent pour debuglog, --DL: l'active

question à régler: trouver un moyen pour que l'affichage web soit "un niveau au dessus" afin de ne pas se retrouver avec dans les logs des messages uniquement pour l'UI peut-être rajouter ui (ou web?) en plus de say, log, debuglog? --> ou renommer say en console, et ui en say

• ajouter une option Application::MSG_SIGNALS qui fait que

  • les méthodes msg::eXXX() appellent automatiquement app::_dispatch_signals()

• ajouter une option Application::MSG_ACTIONS qui fait que

  • msg::section() et/ou msg::title() appellent automatiquement app::action()
  • msg::estep() appelle automatiquement app::step()

• support des logs structurés: log:: ajoute des objets json, un par ligne, dans le fichier destination. msg::, say:: mettent en forme l'information structurée.

  • clés standards: timestamp, user, tech, exception
  • string ou list deviennent ["user" => string|list] ne pas faire cette transformation si le tableau est associatif
  • un trait Tlogger permet de spécifier le cas échéant comment mettre en forme une donnée structurée --> il permet de calculer les valeurs de user_message et tech_message

-- coding: utf-8 mode: markdown -- vim:sw=4:sts=4:et:ai:si:sta:fenc=utf-8:noeol:binary