Reacties op het script debug dump functie
|
|
 Gepost op: 25 juni 2006 - 15:03 |
|
|
|
Erelid
|
|
|
|
|
| Gepost op: 25 juni 2006 - 15:05 |
|
|
|
Crew algemeen
|
Nee, maar in de mijne, (en blijkbaar ook die van de lui van Zend, die de basis bedachten), heeft het WEL meerwaarde.
sowieso zie je hiermee ook de types, dat lukt je echt niet met print_r...
geef eens een ECHT argument, in plaats van jouw mening te geven. |
|
|
|
|
| Gepost op: 25 juni 2006 - 15:56 |
|
|
|
Crew algemeen
|
Verras me met een argument waarom dit wel meerwaarde heeft.
Je merkt vanzelf wel of een variabele van het juiste type is, anders krijg je wel iets te zien als:
Citaat: Warning: in_array() [function.in-array]: Wrong datatype for second argument in C:webserverApacheApache2htdocstest.php on line 8
En dan heb je jouw functie niet nodig om te zien dat het 2e argument niet goed is (geen array dus). |
|
|
|
|
| Gepost op: 25 juni 2006 - 16:03 |
|
|
|
Crew algemeen
|
Dat is niet het HELE punt, het maakt alles sowieso makkelijker, het gaat niet om functies alleen...
Maar stel je eens voor, je hebt een zelfgemaakte functie, waarbij je geen type-checking hebt, waarbij je niet snapt wat er fout is, en het enige wat je hoeft te doen is vantevoren even t argument te dumpen.
(en ja ik hoor m al komen, 'dan echo je gettype(argument)', maar dat slaat op net zoveel als mijn argument).
Daarnaast is t natuurlijk makkelijker dan steeds '<pre>' . htmlspecialchars (print_r ($var, true)) . '</pre>'; te typen... |
|
|
|
|
| Gepost op: 25 juni 2006 - 16:10 |
|
|
|
Crew algemeen
|
Als ik al print_r gebruik om te debuggen, zet ik er nooit dat gedoe van jou omheen.
1 keer print_r($blaat); is genoeg, geen <pre> en htmlspecialchars nodig...
Dus blijf ik je functie niet erg handig vinden...
'print_r($blaat);' is hetzelfde als 'echo dump($blaat);'... |
|
|
|
|
| Gepost op: 25 juni 2006 - 17:09 |
|
|
|
Crew algemeen
|
Jij ja, maar er zijn genoeg andere mensen die het net als mij doen, meer dan jij blijkbaar denkt.
En deze functie returnt void, niet de output... |
|
|
|
|
| Gepost op: 25 juni 2006 - 17:26 |
|
|
|
PHP ver gevorderde
|
een eenvoudige functie maken als
debug( $var )
{
echo "<pre>";
var_dump( $var );
echo "<\pre>";
}
kan iedereen nadat hij de basis van php kent.
Plus waarom gebruik je ob_start en ob_clean enz. Dit freet geheugen, plus als je cookies of sessies gebruikt, zijn ze dan gewoon kapot.
Dit heeft totaal geen waarde, want zoiets maakt iedere php'er als het nodig is op zijn eigen niveau. Een beginner heeft niets aan je script omdat hij dan problemen krijgt met tekst die al eerder geëchoed zijn, enz. Een gemiddelde gebruiker heeft niet al de foefjes nodig die op je functie zit. En een gevorderde gebruiker schrijft het zelf, zodat het handeld zoals hij wilt.
mijn besluit, deze script is nodeloos op deze site. |
|
|
|
|
| Gepost op: 25 juni 2006 - 18:20 |
|
|
|
PHP expert
|
Wordt die cast nu geen twee keer uitgevoerd?
settype ($data, 'array');
en
? array_map ('replace_nl', (array) $a) |
|
|
|
|
| Gepost op: 25 juni 2006 - 18:48 |
|
|
|
Crew algemeen
|
@nemesis: net toen ik dit las dacht ik er aan, ik fix het meteen;-)
@dolfje: misschien heb jij blijkbaar nog flink wat les nodig in php... var_dump slaat zelf de output niet op, dus moet je dit zelf doen, en dit kan alleen met output buffering. je argument over sessies en cookies is sowieso al onzin, omdat dit een debug functie is, dit gebruik je dus niet op een live site.
Citaat: Dit heeft totaal geen waarde, want zoiets maakt iedere php'er als het nodig is op zijn eigen niveau. Een beginner heeft niets aan je script omdat hij dan problemen krijgt met tekst die al eerder geëchoed zijn, enz. Een gemiddelde gebruiker heeft niet al de foefjes nodig die op je functie zit. En een gevorderde gebruiker schrijft het zelf, zodat het handeld zoals hij wilt.
jaja, vast wel, waarom krijg ik op msn steeds vragen over dit soort scripts dan? iedere gebruiker kan hier wat aan hebben, maar jij hebt blijkbaar niet door dat dit niet voor een live site is, maar alleen voor ontwikkeling. |
|
|
|
|
| Gepost op: 26 juni 2006 - 12:27 |
|
|
|
PHP expert
|
@JeXuS: toch denk ik niet dat je daarom per definitie de output moet opvangen. Je zou evengoed de functie eerst '<pre>' laten echoën, dan de loop beginnen en dan dumpen (eerst cleanen, kan je een aparte functie voor maken die dit doet) en dan afsluiten met '<pre>'. Dan krijg je zoiets:
function clean($what) {
if(is_array($what) || $was_object = is_object($what)) {
$what = array_map('clean', (array) $what);
if(isset($was_object)) settype($what, 'object');
} else {
return htmlentities (
preg_replace (
'~]=>\s+~',
'] => ',
$what
),
ENT_QUOTES
);
}
return $what;
}
function dump ()
{
echo '<pre>';
$args = func_get_args();
foreach ($args as $data)
{
if(is_string($date) || is_array($data) || $was_object = is_object($data)) {
$data = replace_nl($data); // moet die array_map eigenlijk wel... kan je niet gewoon de functie aanroepen?
if (isset($was_object)) {
settype ($data, 'object');
unset($was_object);
}
$data = clean($data);
}
var_dump($data);
}
echo '</pre>';
return;
}
function clean($what) { } else { '~]=>\s+~', '] => ', $what ), ENT_QUOTES ); } return $what; } function dump () { foreach ($args as $data) { $data = replace_nl($data); // moet die array_map eigenlijk wel... kan je niet gewoon de functie aanroepen? if (isset($was_object)) { } $data = clean($data); } } return; }
Schiet me niet dood als dit hierboven niet werkt:) |
|
|
|
|
| Gepost op: 26 juni 2006 - 13:10 |
|
|
|
Crew algemeen
|
Je hebt daar inderdaad gelijk in, daar had ik eigelijk niet eens aan gedacht 
Maar sowieso zelfs dan, ik denk niet dat het erg nuttig is om daar een vervanging voor neer te zetten. Het is ook alleen maar voor debugging bedoelt, en vaak maakt het hierbij niet veel uit of je enkele kb's meer gebruikt hiervoor... (bij het compileren van language files voor mn highlighter is er geen significant verschil in memory, terwijl er zo'n mb hierdoorheen gaat).
Evengoed, ik zal het script op deze manier veranderen, zal om ongeveer 3 uur wel klaar zijn... |
|
|
|
|
| Gepost op: 26 juni 2006 - 13:22 |
|
|
|
PHP ver gevorderde
|
@JeXuS: Dus als een debug-functie mag alles verkloten?
En wat je output-buffering betreft, waarom heb je output-buffering nodig als je het 3 lijntjes erachter echoed?
dan kan je evengoed de functie echo nog eens opnieuw uitvinden (mss een tip voor je volgende script, er zijn ook veel mensen die dit nodig hebben  ):
<?
function echo_advanced()
{
ob_start ();
$args = func_get_args ();
foreach ($args as $data)
{
echo $data;
}
$string = ob_get_clean();
echo $string;
}
?>
<? function echo_advanced() { foreach ($args as $data) { } } ?>
Mss kan je ook nog eens een les php nodig hebben JeXuS: Je moet niet iets bufferen als het zonder gemakkelijker is (kijk maar naar mijn script in mijn vorige post en naar nemesiskoen zijn reactie), dit zorgt alleen maar voor overbodige code, waar je later niets mee bent.
En dat php'ers aan jouw zo'n script vragen die eigenlijk samengevat kan worden door 5 regels, verteld iets over hun niveau.
<?
functie debug()
{
echo "<pre>";
$args = func_get_args ();
foreach ($args as $data)
echo $data;
echo "</pre>";
}
?>
<? functie debug() { foreach ($args as $data) } ?>
En nog makkelijker is om gewoon, waar je wilt weten wat er loos is, gewoon je variabel die je wilt checken echo'en. (waarom moeilijk doen als het makkelijk gaat, remember) |
|
|
|
|
| Gepost op: 26 juni 2006 - 13:35 |
|
|
|
Crew algemeen
|
Je weet blijkbaar niet eens goed wat mijn script doet.
Ten eerste: output buffering was nodig, omdat er over de output htmlentities moest worden gedaan, en var_dump NIET kan worden opgeslagen in een variabele. Ik pas de output van var_dump ook nog eens aan met regex, zodat het iets makkelijker te lezen is.
Ten tweede: waarom stellen jullie deze vraag niet aan de makers van het Zend Framework, die bijna precies dezelfde functie gebruiken (op het veranderen van newlines na)?
In ieder geval pas ik hem zo aan, ik heb er flink wat aan veranderd.
EDIT: overigens nemesiskoen, het zal niet helemaal lukken, omdat de output van var_dump met een regex wordt aangepast, de ob blijft dus. |
|
|
|
|
| Gepost op: 26 juni 2006 - 13:39 |
|
|
|
PHP ver gevorderde
|
Omdat het ons niet aangaat wat er op hun site staat, maar wel op deze site.
(en ik weet wel wat er in je script gebeurt, allemaal overbodige dingen) |
|
|
|
|
| Gepost op: 26 juni 2006 - 13:40 |
|
|
|
Crew algemeen
|
Betere vraag: waarom vraagt niemand hun waarom ze het doen? Jullie zijn niet de enigen die hier iets aan zouden kunnen hebben, als andere mensen het slecht vinden zeggen ze het wel.
EDIT: ik ben nu dus in een bug in PHP gestuit... zal hem toch weer gedeeltelijk moeten veranderen... |
|
|
|
|
| Gepost op: 26 juni 2006 - 14:03 |
|
|
|
PHP expert
|
| @Jexus: zoals je waarschijnlijk wel weet ben ik geen held in regex. Zou je me misschien kunnen vertellen waarom die regex over de output van var_dump moet en niet over de waarde van de variabele? |
|
|
|
|
| Gepost op: 26 juni 2006 - 14:08 |
|
|
|
Crew algemeen
|
de regex past de uitvoer van var_dump aan, die is ongeveer zo:
array(2) {
[0]=>
string(9) "array_var"
[1]=>
string(11) "another_var"
}
[0]=> string(9) "array_var" [1]=> string(11) "another_var" }
de regex past het aan naar dit:
array(2) {
[0] => string(9) "array_var"
[1] => string(11) "another_var"
}
[0] => string(9) "array_var" [1] => string(11) "another_var" }
persoonlijk vind ik dit toch wel iets duidelijker... |
|
|
|
|
| Gepost op: 26 juni 2006 - 15:50 |
|
|
|
Moderator
|
Citaat: Ten tweede: waarom stellen jullie deze vraag niet aan de makers van het Zend Framework, die bijna precies dezelfde functie gebruiken (op het veranderen van newlines na)? |
|
|
|
|
| Gepost op: 26 juni 2006 - 20:25 |
|
|
|
Ouwe rakker
|
Wat ik alleen niet begrijp is waarom dat je replace_nl functie gewoon om kan gaan met array/object/string en je in je dump functie dan alsnog deze 3 gaat scheiden en apart gaat voeren aan je functie.
Omdat het toevallig een array is en geen string hoef jij die niet te gaan array_mappen omdat jouw eigen replace_nl functie om kan gaan met een array.
Dat is het enige wat ik even niet kan volgen.
edit
Update deze dan ook even als dat toch de nieuwste versie van je script is. |
|
|
|
|
| Gepost op: 26 juni 2006 - 20:53 |
|
|
|
Crew algemeen
|
| Dit heb ik inmiddels in de nieuwe versie (niet geupdate) al verholpen. Hierin handelt de replace_nl functie dit gewoon af. |
|
|
|
|
| Gepost op: 28 juni 2006 - 13:07 |
|
|
|
PHP expert
|
| Zo is hij echt een pak beter, mooier en logischer:) |
|
|
| Enkel aanvullende informatie, vragen en antwoorden op vragen zijn welkom. |
|
|
|
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
