Tags dans les logs plus interprètés en 4.4 beta

Salon des Développeurs Core V4 (dev)
22

Bonjour
Après ce n’est que mon avis je décide absolument rien et ce n’est pas moi qui est fait cette fonction.

23

Hello all,

OK, voici donc ma proposition (exhaustive) des remplacements dans les logs :

  • Déjà présents :

    • < → &lt; & > → &gt;
    • WARNING: → <span class="warning">WARNING</span>
    • Erreur → <span class="danger">Erreur</span>
    • OK → <strong>OK</strong>
    • [DEBUG] → <span class="label label-xs label-success">DEBUG</span>
    • [INFO] → <span class="label label-xs label-info">INFO</span>
    • [NOTICE] → <span class="label label-xs label-info">NOTICE</span>
    • [WARNING] → <span class="label label-xs label-warning">WARNING</span>
    • [ERROR] → <span class="label label-xs label-danger">ERROR</span>
    • [CRITICAL] → <span class="label label-xs label-danger">CRITI</span>
    • [ALERT] → <span class="label label-xs label-danger">ALERT</span>
    • [EMERGENCY] → <span class="label label-xs label-danger">EMERG</span>

  • À ajouter :

    • Surligné (highlight) :
      :h-success: → <span class="label label-success">
      :h-info: → <span class="label label-info">
      :h-warning: → <span class="label label-warning">
      :h-danger: → <span class="label label-danger">
      :/h: → </span>
    • Couleurs du texte :
      :t-success: → <span class="success">
      :t-info: → <span class="info">
      :t-warning: → <span class="warning">
      :t-danger: → <span class="danger">
      :/t: → </span>
    • Gras (bold) : :b: → <b> & :/b: → </b>
    • Gros (strong) : :s: → <strong> & :/s: → </strong>
    • Italique : :i: → <i> & :/i: → </i>
    • Retour à la ligne : \r\n & \n & :br: → <br>
    • Commentaires : :hide: → <!-- & :/hide: → -->

Qu’en dites-vous ?

  • Pour
  • Contre
  • Objection votre honneur ! (commenter plus bas)
0 votant

Je pense aussi que serait une bonne idée de mettre ça déjà en place en v4.3.

Bad

1 « J'aime »
24

J’aime bien, le hide peut être sympa si pas affiché mais présent quand on copie colle, ça ouvre des possibilités…

Par contre il me semble que j’avais vu aussi une colorisation simple de la font avec la class danger il me semble. Donc on pourrait avoir le bk-danger et le f-danger non ?

25

En effet, j’ai aussi vu passer des <span class="success">coucou</span>.

On renomme les c-xxx en h-xxx pour highlight et utilise c-xxx pour la couleur du texte ?

  • Couleurs du texte :
    :c-success: → <span class="success">
    :c-info: → <span class="info">
    :c-warning: → <span class="warning">
    :c-danger: → <span class="danger">
    :/c: → </span>
  • Surligné (highlight) :
    :h-success: → <span class="label label-success">
    :h-info: → <span class="label label-info">
    :h-warning: → <span class="label label-warning">
    :h-danger: → <span class="label label-danger">
    :/h: → </span>

J’ai maj au dessus.

1 « J'aime »
26

t- et h- ? :wink: texte et highlight :wink: car c’est tous les deux couleur :wink:

1 « J'aime »
27

I approve! Changed !

28

Et background bg- serait pas plus … parlant !?

1 « J'aime »
29

Toi aussi bg va !

30

J en demandais pas tant :face_with_peeking_eye:

31

Je ne suis pas sur d’avoir compris: du coup on doit écrire genre :i: dans le log pour formater?
Et si on affiche le log brut (ou copié/collé du log sur community) le :i: sera présent dans le texte donc log illisible lorsque l’utilisateur va me filer son log?

1 « J'aime »
32

En log brut oui, là où aujourd’hui tu as deja <i>, donc ça ne change rien.

En log « pas brut » tu auras le formatage attendu.

33

Ok
C’est comme vous voulez alors, je ne m’en servirai pas.

Je ne trouve pas judicieux (au contraire) de vouloir modifier le contenu d’un log pour qu’il s’affiche potentiellement un peu mieux dans un cas d’usage (l’utilisateur sera content d’avoir des couleurs) au détriment d’un autre (le dev va avoir un truc illisible) mais chacun voit midi à sa porte j’imagine.

34

Je rejoins @Mips sur ce coup, je suis très sceptique quant à l’intérêt de s’embêter à aller interpréter du code html dans les logs.

35

Merci @Mips et @Salvialf pour vos avis intéressants concernant l’amélioration de la coloration.

Si cette façon de faire vous gêne, quelle modification apporteriez-vous à la proposition d’amélioration ?

36

Mais si on copie le log non brut on est d’accord que les :tag: n’apparaîtront pas ?

Par contre dans le brut oui je pense… on ne pourrait pas les stripper complet ?

Le log dependency a peu de chance d’être assez long pour passer en brut non ?

Et si je ne me trompe pas avec les nouvelles perf de la 4.4 le log peut encore être plus long avant de passer en brut

(En 4.4 j’ai affiché un log de 300Mb il était en non brut !!!)

37

Non, ils apparaitront On est d’accord !

Actuellement (4.3 et 4.4) du html est juste ajouté autour du texte existant dans les logs non bruts.
La remarque de Mips et Salvialf vient de là : aujourd’hui, dans le fichier de log sur le disque, il n’y a aucun tag, ils sont ajoutés à la volée autour de certaines valeurs prédéfinies (surtout dans les logs des scenarios).

Ce serait peut-être le taff d’un bouton « Copier » (le log dans le presse papier) qui se chargerait en JS de strip les tags à la volée au moment de la copie ?

En v4.3, le replace est fait aussi en JS par le navigateur, sur tout le fichier à chaque changement.
En v4.4, ne sont envoyées que les lignes ajoutées depuis le dernier envoi et le replace est coté PHP.
Le navigateur bouffe quand même N milliers de lignes, mais une fois affichées, il n’y touche plus.
Donc oui, c’est bien plus rapide :slight_smile:

Par contre, je ne pense pas que tu as afficher 300Mo de log : lors du 1er envoi, seules les 4000 dernières lignes (par défaut) sont envoyées et il n’y a plus de basculement automatique en logs brut.
image

Bad

38

D’ailleurs y a un bug très gênant mais c’est un autre sujet: lorsqu’on utilise la recherche pour filtrer les lignes, ca masque les lignes qu’il faut, quand on efface la recherche, les lignes ne reviennent pas… sauf les nouvelles
Je suis toujours obligé de recharger le fichier complet et du coup on perd l’avantage

Tu as résumé après: dans le fichier d’origine je n’ai pas l’intention d’écrire des tag de formatage et cela dans le but de garder le texte d’origine lisible même en mode brut (ou en lorsqu’on ouvre le fichier)

C’est pour ca que je disais faite comme vous voulez: mon avis n’est pas relevant puisque toute la solution repose sur le fait d’ajouter des tags.

39

Ah tu as fait un lazy loading ?

Oui, ou autre idée, une méthode dans la classe de chaque plugin où on peut ajouter un array search et replace qui est concatèné à celui existant dans le core.

Ça fusionnerait les deux avantages

40

Bonjour,
Le log brute devrait être lisible et non modifié en automatique. Au risque de dropper des info sans le faire exprès.

Le log formaté doit aider l’utilisateur à trouver des mot clef.
Est ce utile de proposer des logs ultra compliqué permettant d’avoir un log multi color?
Est ce que le dev d’un plugin s’amusera à mettre en forme pour avoir des logs compliqués ?
Enfin : comment ça se passe quand un utilisateur copie un morceau de log pour le mettre dans Communauty pour avoir de l’aide ?
Plus il y aura de tag, plus ça sera difficile de décoder.
Et une capture d’écran coloré sur smartphone sera pas top non plus.

La proposition simple d’avoir un OK transformé en vert et un ERROR en rouge suffirait à mon avis, la plupart des utilisateurs n’allant pas voir les logs.
Ou simplement les balise pour éviter les blagues de balise HTML contenant le onmouse déjà indiqué au dessus.

De plus, ça donnerait quoi tout cela dans les logs envoyé sur un syslog ?
Ça serait plus lisible avec des tags de mise en forme ?

Il faudrait voir quel est le besoin plutot que comment faire.

1 « J'aime »
41

J’ai cherché un peu et je vois que la mise en forme s’appelle log highlight.
Le rendu tel que ce programme le fait me semble suffisant et clair :

On voit le text qui est mis en valeur, INFO et ERROR aussi.
Le log semble lisible.