50 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			50 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| # nulib\output
 | |
| 
 | |
| * log:: permet d'ajouter autant d'instance de LogMessenger que nécessaire
 | |
|   * on pourrait qualifier un logger avec par exemple la classe qui l'appelle
 | |
|     ou le nom d'un sous-système.
 | |
|     * pour un log structuré, un attribut donnerai le qualificatif, ce qui ne
 | |
|       serait pris en compte que par le logger approprié (e.g un logger qui est
 | |
|       responsable de nulib/io logguera les message de nulib/io/ClassA mais pas
 | |
|       les messages de nulib/args/ClassB
 | |
|   * un trait permet d'ajouter un logger à une classe
 | |
| 
 | |
| * [ ] 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
 | |
| * 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 |