Newsgroup: it.comp.www.php
Titolo: eseguire applicazione in modalità verbose

Se si tratta di una cli-app
 
if ($verbose_mode) {// se l'app deve parlare
     // visualizzazione messaggi informativi
     fwrite(STDOUT, 'Caricamento configurazione...');
     fwrite(STDOUT, 'Lettura database...');
     //...
}
 
Se invece si tratta di una web-app, al posto di fwrite() si potrebbe 
usare qualcosa tipo
 
echo '<script>console.log("Caricamento configurazione...")</script>';
 
anche se, secondo me, la *browser-console* andrebbe usata solo per 
visualizzare dati/messaggi di debug, e non dati/messaggi informativi.
 
Cosa ne pensate? Qual'è la soluzione più adatta?

 Cosa ne pensate? Qual'è la soluzione più adatta?
 
Monolog.
 
Bye.

 Monolog.
 
quindi bisogna per forza usare un file tipo *logs/verbose.log*?


No. Monolog è stra-configurabile.
 
Puoi configurarlo per non stampare le date e scrivere in console da CLI, 
e per scrivere su file o su Firebug da web. Il tutto filtrato per livelli 
di log.
 
Bye.

 di log.
 
ok, ma non mi è mai piaciuto dipendere troppo da software esterni 
(firebug, xdebug....)

alex <1j94...@lnx159sneakemail.com.invalid> ha scritto:

firebug serve per fare il debug lato client.
 
xdebug serve per fare il debug lato server.
 
Non c'entra niente il dipendere, c'entra che senza questi software
non puoi fare proprio il debug (se non con le preistoriche stampe
di controllo immerse nel codice).
 
 


 
Quindi
vebose-mode = debug-mode
 
...per me non è proprio la stessa cosa


Puoi sempre riscriverti il protocollo simulando firebug o inventando 
qualcosa di nuovo (come cachare tutto e appendere uno
 
<script>
<?php foreach ($errors as $error): ?>
  console.log('<?php echo $error; ?>');
<?php endforeach ?>
</script>
 
alla fine della pagina). In alcuni casi va bene (per imparare, per 
implementarlo in modo più efficiente o più customizzabile, ecc.).
 
In altri casi è una perdita di tempo.
 
Io ho interpretato la tua domanda come "come mandare output a due cose 
diverse?", mentre forse la tua domanda era in realtà "come mandare output 
solo se attivo il verbose mode?".
 
Monolog risolve entrambe, perché ti permette di configurare il formato di 
output, il dispositivo di output, e anche il loglevel da mandare, quindi 
puoi avere
 
$monolog->pushHandler(
  new StreamHandler(
    '/tmp/log.log',
    $verbose ? 'warning' : 'debug'
  )
);
 
e non devi riempire il tuo codice di if($verbose) printf(...); ma usi 
direttamente $monolog->debug(...) o $monolog->warning(...)
 
Bye.

 direttamente $monolog->debug(...) o $monolog->warning(...)
 
Il fatto è che non capisco perchè non distinguete la modalità debug (in 
cui vengono visualizzati errori e dati relativamente inerenti), dalla 
modalità verbose (di cui si può avvalere non solo lo sviluppatore, ma 
anche l'utente comune).
 
Esempio di utilizzo di rsync in modalità verbose:
 
$ rsync -a --verbose dir1 dir2
 
Secondo voi verranno visualizzate informazioni di debug, o comuni 
messaggi informativi: cosa sta facendo il programma, quali file di 
configurazione sono stati caricati (qualora, cioè *nell'ipotetico* caso 
in cui volessi configurare qualcosa so dove mettere le mani), ecc.

 in cui volessi configurare qualcosa so dove mettere le mani), ecc.
 
In Unix/Linux ci sono normalmente diversi livelli di verbose. Alcuni 
comandi accettano -vvv, per esempio, per il "most verbose" e -v per il 
verbose.
 
Questo si traduce, in Monolog (e in PSR-3) nell'innalzamento del livello 
di log. Questi sono i livelli di PSR3:
 
- emergency
- alert
- critical
- error
- warning
- notice
- info
- debug
 
Secondo me ce ne sono troppo pochi nella parte bassa (avrei introdotto 
almeno trace e profiling), ma puoi per esempio usare notice per i 
messaggi normali, info per il --verbose e debug per il -vv (double verbose)
 
Questo ti permette di non toccare il codice:
 
$logger->notice("Copying file");
$logger->info("Source: " .$source. ", dest: " .$dest);
$logger->debug("Source size: " .filesize($source));
 
Niente if, niente commenti, niente compilazione condizionale (se fosse 
possibile), ma tutto configurabile al bootstrap:
 
$verboseLevel = $argumentParser->count('v'); // metacodice...
 
switch ($verboseLevel) {
  case 0: $logLevel = 'notice'; break;
  case 1: $logLevel = 'info'; break;
  default: $logLevel = 'debug'; break;
}
 
$logger->pushHandler(
   new StreamHandler(
     '/tmp/log.log',
     $logLevel
   )
);
 
Bye.
 

 verbose.
 
Che comunque non forniscono vere proprie info di debug.
Il debug (fatto in modo veramente professionale) è tutt'altra cosa
https://it.wikipedia.org/wiki/Debugging
 
e spesso necessità di dati altamente dettagliati: molto più dettagliati 
di quelli forniti dai *verbali* a cui può accedere anche la GM (gente 
comune) :)
Dati che la maggior parte della GM, peraltro e probabilmente, non 
saprebbe neanche interpretare in modo adeguato.
Magari bastasse una verbose-mode per scovare un bug :)
 
 

 Che comunque non forniscono vere proprie info di debug.
 
Mi spieghi come sei passato dal verbose al debugging?
 
Hai chiesto come implementare il verbose e te l'ho detto. Non hai chiesto 
come fare debug.
 
Se vuoi fare debugging USA XDEBUG!
 
Quante volte dobbiamo dirtelo?
 


 
Non sono mai passato al debugging.
In realtà quello che chiedo è un area dove poter inviare i 
web-verbose-message, che sarebbero l'esatto corrispondente dei 
cli-verbose-message.
La conclusione a cui sono giunto è che gli attuali browser hanno solo 
una console (più precisamente una debug-console), e quindi per un 
momento non esistono browser dotati di una verbose-console, su cui 
scrivere ad esempio messaggi di carattere generico.
 

scrivere ad esempio messaggi di carattere generico.
 
La console del browser è per il codice *client*, mica per il codice *server*.
 
Se proprio, puoi mandare il log verbose in appositi header.
 
Siccome io lo faccio ;-) ti dico subito che per leggerli bene ti conviene usare
un nome come
 
	$headerName	= sprintf('X-Y%05d', $headerCount++);
 
perché altrimenti alcuni browser te li riordinano come vogliono.
 
In effetti, i miei script riconoscono il mio particolare useragent e aggiungono
quegli header solo se lo vedono (non sempre posso usare XDebug :-( ).
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 Se proprio, puoi mandare il log verbose in appositi header.
 
Cosa intendi per header?
 
 

 Quante volte dobbiamo dirtelo?
 
E' quello che gli ho detto io qualche post fa:
 
"firebug serve per fare il debug lato client.
 
xdebug serve per fare il debug lato server.
 
Non c'entra niente il dipendere, c'entra che senza questi software
non puoi fare proprio il debug (se non con le preistoriche stampe
di controllo immerse nel codice)."
 
 
Ma sembra che abbia ancora le idee poco chiare...
 
 

 Ma sembra che abbia ancora le idee poco chiare...
 
Evidentemente non mi so spiegare. Mea culpa, forse...
 
Il tema di questa discussione non è il * D E B U G *, ma la 
realizzazione di un'interfaccia informativa app-user.
 
Ecco un esempio (osservare specialmente la parte in basso)
http://cdn.portableapps.com/GeanyPortable.png
 
 
 


Be'... header. Header HTTP. Tipo
 
	Header('X-Y01345: calling Model\Macchina::fasi()');
 
Che poi puoi leggere nel browser, avendo l'apposito strumento per sviluppatori.



 
Come questo
https://addons.mozilla.org/it/firefox/addon/live-http-headers/
 

 quegli header solo se lo vedono (non sempre posso usare XDebug :-( ).
 
Useragent, cioè?


ogni browser invia un intestazione di chi è (appunto un Useragent) che 
indica chi è (mozilla, webkit, IE, ecc..) e indica anche il SO
 
 
esempio di log Apache dello useragent
127.0.0.1 - - [27/Oct/2016:22:40:33 +0200] "GET / HTTP/1.1" 200 4257 "-" 
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 
Firefox/49.0"
 
 
ora lo Useragent può essere modificato e personalizzato (ci sono plugin 
che agevolano questo)
un client che effettua una richiesta ad un server web, non 
necessariamente è un browser basti pensare a tutto IoT (Internet of Things)
 
prendendo in considerazione quanto sopra puoi far avere un comportamento 
diverso alla tua applicazione in base appunto al riconoscimento dello 
Useragent, come appunto Serni indicava.
 
Ciao
 
 

 Useragent, come appunto Serni indicava.
 
Non ci avevo mai pensato, grazie :)

 Se proprio, puoi mandare il log verbose in appositi header.
 
cmq la soluzione ideale e che in futuro i browser avessero un apposita 
verbose area, come qui (vedere in basso)
http://cdn.portableapps.com/GeanyPortable.png