testare valore visualizzato da una funzione

[alex]

function abc() {
return 'ciao';
}

assert(abc() == 'ciao');


Tutto ok, ma se la funzione fosse stata cosￜ:

function abc() {
echo 'ciao';
}

come si fa a testare un valore non restituito, ma visualizzato direttamente?

[Alessandro Pellizzari]

Il Sat, 04 Oct 2014 07:23:06 +0200, alex ha scritto:

> function abc() {
> echo 'ciao';
> }
>
> come si fa a testare un valore non restituito, ma visualizzato
> direttamente?

Intanto non dovresti avere funzioni che stampano, ma solo che ritornano
valori, ma per i casi particolari (template engine, per esempio) puoi
usare ob:

ob_start();
abc();
assert(ob_get_clean(), 'ciao');

Bye.

[alex]

si, però funzioni che stampano ce ne sono:

var_dump(...);
print_r(...);
exit(...);

[Alessandro Pellizzari]

Il Sat, 04 Oct 2014 10:41:17 +0200, alex ha scritto:

> si, però funzioni che stampano ce ne sono:
>
> var_dump(...);
> print_r(...);
> exit(...);

Sì, ci mancherebbe altro.
Ma perché dovresti usarle in una funzione o, peggio, in una classe?

Se devi stampare qualcosa a schermo devi essere un template engine (o
pochi altri casi specifici).

Se devi uscire con un errore, lancia un'eccezione.

Se devi fare un dump, fallo su file (o, meglio, su uno stream).

In tutti gli altri casi, una funzione deve tornare un risultato con
return o modificare lo stato dell'oggetto in cui si trova, ma non scrivere
a schermo.

Bye.

[Alessandro Pellizzari]

Il Sat, 04 Oct 2014 09:12:42 +0000, Alessandro Pellizzari ha scritto:

> Se devi stampare qualcosa a schermo devi essere un template engine (o
> pochi altri casi specifici).

O, meglio ancora, nemmeno loro. Implementa semplicemente un __toString(),
poi sarà l'utente a decidere quando usare "echo $template" nel suo main
frontcontroller o quello che è.

Bye.

[alex]

Il 04/10/2014 11:12, Alessandro Pellizzari ha scritto:
> Il Sat, 04 Oct 2014 10:41:17 +0200, alex ha scritto:
>
>> si, però funzioni che stampano ce ne sono:
>>
>> var_dump(...);
>> print_r(...);
>> exit(...);
>
> Sì, ci mancherebbe altro.
> Ma perché dovresti usarle in una funzione o, peggio, in una classe?
>

per scopi di debug.
Ad esempio dai un occhiata qui [ metodo debug() ]
http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine

> Se devi stampare qualcosa a schermo devi essere un template engine (o
> pochi altri casi specifici).
>
> Se devi uscire con un errore, lancia un'eccezione.
>
> Se devi fare un dump, fallo su file (o, meglio, su uno stream).
>

un esempio di dumping su stream? (se non chiedo troppo)

[alex]

Il 04/10/2014 13:06, alex ha scritto:
>> Se devi stampare qualcosa a schermo devi essere un template engine (o
>> pochi altri casi specifici).
>>
>> Se devi uscire con un errore, lancia un'eccezione.
>>
>> Se devi fare un dump, fallo su file (o, meglio, su uno stream).
>>
>
> un esempio di dumping su stream? (se non chiedo troppo)
>

Ah forse php://stdout, giusto?

[alex]

class TemplateEngine {
function __toString(){
return 'Hello!!!';
}
}

$template = new TemplateEngine('Hello');
echo $template;


Così?

[Leonardo Serni]

On Sat, 04 Oct 2014 07:23:06 +0200, alex
<1j94...@lnx159sneakemail.com.invalid> wrote:

>function abc() {
> return 'ciao';
>}
>
>assert(abc() == 'ciao');

>Tutto ok, ma se la funzione fosse stata così:

>function abc() {
> echo 'ciao';
>}

>come si fa a testare un valore non restituito, ma visualizzato direttamente?

In tanti modi, nessuno efficiente.

Suggerimento: NON visualizzare mai nulla nelle funzioni :-)

function assert_output($output, $callback) {
ob_start();
$ret = $callback();
$out = ob_get_contents();
ob_end_clean();
assert(preg_match($output, $out));
// Magari ulteriori asserzioni su $ret, sai mai.
}

Leonardo

--

Questi non hanno speranza di morte; e la lor cieca vita e' tanto bassa,
Che 'nvidiosi son d'ogne altra sorte. Fama di loro il mondo esser non lassa;
Misericordia e Giustizia li sdegna; non ragioniam di lor, ma guarda e passa.

[alex]

Il 05/10/2014 14:00, Leonardo Serni ha scritto:
> In tanti modi, nessuno efficiente.
>
> Suggerimento: NON visualizzare mai nulla nelle funzioni:-)
>
> function assert_output($output, $callback) {
> ob_start();
> $ret = $callback();
> $out = ob_get_contents();
> ob_end_clean();
> assert(preg_match($output, $out));
> // Magari ulteriori asserzioni su $ret, sai mai.
> }

Come già accennato nell'altro postm dai un occhiata qui [ metodo debug() ]
http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine

Quindi i geni che hanno scritto Doctrine non sono poi così geni :-P

[Leonardo Serni]

On Mon, 06 Oct 2014 13:58:56 +0200, alex
<1j94...@lnx159sneakemail.com.invalid> wrote:

>Come già accennato nell'altro postm dai un occhiata qui [ metodo debug() ]
>http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine

Ma quella e' appunto una funzione di debug; e' fatta apposta per iniettare del
contenuto su stdout... Li', l'errore (architetturale) sarebbe pensare di AVERE
l'accesso al suo output, non di non averlo.

Header(), la funzione (quale che sia) che manda l'output finale al browser, e,
ovviamente, cose come crash(), var_dump(), ecc., l'output possono averlo... o,
addirittura, devono.

[alex]

Il 06/10/2014 17:48, Leonardo Serni ha scritto:
> On Mon, 06 Oct 2014 13:58:56 +0200, alex
> <1j94...@lnx159sneakemail.com.invalid> wrote:
>
>> Come già accennato nell'altro postm dai un occhiata qui [ metodo debug() ]
>> http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine
>
> Ma quella e' appunto una funzione di debug; e' fatta apposta per iniettare del
> contenuto su stdout...

però nel caso seguente mi sembra che l'output sia stampato direttamente
a video

public function debug($realOutput = false)
{
print $this->tester->error('Response debug');

if (!$realOutput && null !== sfException::getLastException())
{
// print the exception and the stack trace instead of the
"normal" output
$this->tester->comment('WARNING');
$this->tester->comment('An error occurred when processing this
request.');
$this->tester->comment('The real response content has been
replaced with the exception message to ease debugging.');
}

printf("HTTP/1.X %s\n", $this->response->getStatusCode());

foreach ($this->response->getHttpHeaders() as $name => $value)
{
printf("%s: %s\n", $name, $value);
}

foreach ($this->response->getCookies() as $cookie)
{
vprintf("Set-Cookie: %s=%s; %spath=%s%s%s%s\n", array(
$cookie['name'],
$cookie['value'],
null === $cookie['expire'] ? '' : sprintf('expires=%s; ',
date('D d-M-Y H:i:s T', $cookie['expire'])),
$cookie['path'],
$cookie['domain'] ? sprintf('; domain=%s', $cookie['domain']) : '',
$cookie['secure'] ? '; secure' : '',
$cookie['httpOnly'] ? '; HttpOnly' : '',
));
}

echo "\n";
if (!$realOutput && null !== $exception =
sfException::getLastException())
{
echo $exception;
}
else
{
echo $this->response->getContent();
}
echo "\n";

exit(1);

}


> Li', l'errore (architetturale) sarebbe pensare di AVERE
> l'accesso al suo output, non di non averlo.
>

non ho capito il gioco di parole :)

> Header(), la funzione (quale che sia) che manda l'output finale al browser, e,
> ovviamente, cose come crash(), var_dump(), ecc., l'output possono averlo... o,
> addirittura, devono.

certo ci sono sempre le eccezioni

[Leonardo Serni]

On Mon, 06 Oct 2014 19:26:18 +0200, alex
<1j94...@lnx159sneakemail.com.invalid> wrote:

>> Ma quella e' appunto una funzione di debug; e' fatta apposta per iniettare del
>> contenuto su stdout...

>però nel caso seguente mi sembra che l'output sia stampato direttamente
>a video

Appunto, e io che ho detto? :-)

>> Li', l'errore (architetturale) sarebbe pensare di AVERE
>> l'accesso al suo output, non di non averlo.

>non ho capito il gioco di parole :)

Non e' un gioco di parole... ero io che mi ero fumato la corda e stavo
probabilmente pensando in Klingon. Scusami.

Intendevo mettere a confronto l'avere accesso all'output:

function eeeeh() {
return "puppa";
}

rispetto ad avere l'output:

function eeeeh() {
echo "puppa";

[alex]

Il 06/10/2014 21:28, Leonardo Serni ha scritto:
> On Mon, 06 Oct 2014 19:26:18 +0200, alex
> <1j94...@lnx159sneakemail.com.invalid> wrote:
>
>>> Ma quella e' appunto una funzione di debug; e' fatta apposta per iniettare del
>>> contenuto su stdout...
>
>> però nel caso seguente mi sembra che l'output sia stampato direttamente
>> a video
>
> Appunto, e io che ho detto? :-)
>

che dovrebbe indirizzare l'output su sdtout

>>> Li', l'errore (architetturale) sarebbe pensare di AVERE
>>> l'accesso al suo output, non di non averlo.
>
>> non ho capito il gioco di parole :)
>
> Non e' un gioco di parole... ero io che mi ero fumato la corda e stavo
> probabilmente pensando in Klingon. Scusami.
>
> Intendevo mettere a confronto l'avere accesso all'output:
>
> function eeeeh() {
> return "puppa";
> }
>
> rispetto ad avere l'output:
>
> function eeeeh() {
> echo "puppa";
> }

ma quindi a rigor di logica la funzione debug, l'output lo deve
restituire o lo deve visualizzare?
Faccio un po' di fatica a comprenderti ;)

Ad esempio debug_backtrace() lo restituisce

[Alessandro Pellizzari]

Il Mon, 06 Oct 2014 13:58:56 +0200, alex ha scritto:

> Come già accennato nell'altro postm dai un occhiata qui [ metodo debug()
> ]
> http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine
>
> Quindi i geni che hanno scritto Doctrine non sono poi così geni :-P

~~~
Caution: You are browsing the legacy 1.x part of this website.

This version of symfony is not maintained anymore. If some of your
projects still use this version, consider upgrading.
~~~


http://it.wikipedia.org/wiki/Symfony:

1.4 Novembre 2009


Stai studiando codice di 5 anni fa...

Oltretutto, è codice per fare testing di un sistema headless. Scrivere su
stdout in questo caso è il modo migliore, perché se hai un monitor per i
test, intercetta stdout, e se non ce l'hai, l'output viene, nel 99.9% dei
casi, rediretto (per esempio cron e at te lo mandano per email)

Bye.

[alex]

Alessandro Pellizzari <shur...@amiran.it> ha scritto:

a questo punto però mi chiedo quando sia il caso di usare lo
stream, e quando invece stampare i dati su appositi file di
log?
--


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[alex]

Alessandro Pellizzari <shur...@amiran.it> ha scritto:

> Il Mon, 06 Oct 2014 13:58:56 +0200, alex ha scritto:
>

>> Come gi� accennato nell'altro postm dai un occhiata qui [ metodo debug()
>> ]
>> http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine
>>
>> Quindi i geni che hanno scritto Doctrine non sono poi cos� geni :-P

>
> ~~~
> Caution: You are browsing the legacy 1.x part of this website.
>
> This version of symfony is not maintained anymore. If some of your
> projects still use this version, consider upgrading.
> ~~~
>
>
> http://it.wikipedia.org/wiki/Symfony:
>
> 1.4 Novembre 2009
>
>
> Stai studiando codice di 5 anni fa...
>

> Oltretutto, � codice per fare testing di un sistema headless. Scrivere su
> stdout in questo caso � il modo migliore, perch� se hai un monitor per i

> test, intercetta stdout, e se non ce l'hai, l'output viene, nel 99.9% dei
> casi, rediretto (per esempio cron e at te lo mandano per email)
>
> Bye.
>

Cosa intendi per monitor di test?
--

[Leonardo Serni]

On Mon, 06 Oct 2014 22:26:01 +0200, alex
<1j94...@lnx159sneakemail.com.invalid> wrote:

>>> però nel caso seguente mi sembra che l'output sia stampato direttamente
>>> a video

>> Appunto, e io che ho detto? :-)

>che dovrebbe indirizzare l'output su sdtout

Ah, e' un problema di terminologia. Io chiamo 'stdout' il video :-)

Effettivamente, con un server web non e' detto che sia sempre cosi'.

>ma quindi a rigor di logica la funzione debug, l'output lo deve
>restituire o lo deve visualizzare?

"A rigor di logica" potrebbe fare entrambe le cose. Secondo me, il fatto
che faccia l'una o l'altra non deve stupire o far pensare che gli autori
siano pazzi scriteriati.

>Faccio un po' di fatica a comprenderti ;)

Eh, probabilmente dovrei dormire di piu' ;-)

[Alessandro Pellizzari]

Il Tue, 07 Oct 2014 01:14:11 +0200, alex ha scritto:

> Cosa intendi per monitor di test?

Roba tipo Jenkins o Travis. :)

Bye.

[Alessandro Pellizzari]

Il Tue, 07 Oct 2014 01:09:35 +0200, alex ha scritto:

> a questo punto però mi chiedo quando sia il caso di usare lo
> stream, e quando invece stampare i dati su appositi file di log?

Un framework non dovrebbe mai scrivere di sua iniziativa su un file o su
stdout/stderr.

Un'applicazione (che usi un framework o meno) può fare quello che vuole,
dipende dalle esigenze del progetto.

Ma generalmente si tende a costruire una libreria o un framework "sotto"
l'applicazione, usando pezzi riutilizzabili.

A quel punto il tuo logger dovrà accettare o un nome di file dove scrivere
i log (ma risulterà limitato) o uno stream (così può scrivere anche in
rete o a schermo). Oppure implementare un componente per ogni output e
l'applicazione deciderà quale usare.

Bye.

[alex]

Il 07/10/2014 21:54, Alessandro Pellizzari ha scritto:
> A quel punto il tuo logger dovrà accettare o un nome di file dove scrivere
> i log (ma risulterà limitato) o uno stream (così può scrivere anche in
> rete o a schermo). Oppure implementare un componente per ogni output e
> l'applicazione deciderà quale usare.

limitato in che senso?

[Alessandro Pellizzari]

Il Wed, 08 Oct 2014 11:37:31 +0200, alex ha scritto:

> Il 07/10/2014 21:54, Alessandro Pellizzari ha scritto:

>> A quel punto il tuo logger dovrà accettare o un nome di file dove
>> scrivere i log (ma risulterà limitato)

> limitato in che senso?

Nel senso che se gli passi solo un nome di file può scrivere solo su un
file. Se hai un logserver, un'applicazione distribuita su più server, la
necessità di loggare su db, ecc. ecc. non lo puoi fare.

Bye.

[alex]

Il 08/10/2014 21:33, Alessandro Pellizzari ha scritto:
> Il Wed, 08 Oct 2014 11:37:31 +0200, alex ha scritto:
>
>> Il 07/10/2014 21:54, Alessandro Pellizzari ha scritto:
>
>>> A quel punto il tuo logger dovrà accettare o un nome di file dove
>>> scrivere i log (ma risulterà limitato)
>
>> limitato in che senso?
>
> Nel senso che se gli passi solo un nome di file può scrivere solo su un
> file.

certo

> Se hai un logserver, un'applicazione distribuita su più server, la
> necessità di loggare su db, ecc. ecc. non lo puoi fare.
>

logserver?
Si tratta di una struttura hardware o soft?

[Alessandro Pellizzari]

Il Wed, 08 Oct 2014 22:05:22 +0200, alex ha scritto:

> logserver?
> Si tratta di una struttura hardware o soft?

software