[PHP] Bizar functiegedrag, $foo .= $bar werkt niet

[Verwijderd]

Ik heb een bizar probleem in een functie in PHP.

Ik definieer een aantal variabelen en frommel die in elkaar tot een pakketje html die ik wil echoen. Het gekke is, dat ik die variabelen wél hard kan echoen, binnen de functie, maar niet aan een overkoepelende $sReturn kan vastknopen en die dat terugsturen.

Simpel voorbeeld:

PHP:

function content ($id)
{
# SQL zut enz (werkt)

//nu vars maken
foreach ($aRecords as $key => $value)
{
   $$key = utf8_encode($value);
}

/*en nu de million dollar question:

Als ik doe echo $title; dan print php de titel op het scherm. DIT WERKT
Maar dat wil ik niet, ik wil de titel tussen <h2> tags en de text tussen <p> tags 
en dan de boel in een net pakket teruggeven.
dus ik doe:*/

//echo $title; echo $text; //werkt! -> Ik ben een test. Ik ben een testtekst!

$sReturn = '<div class="content-item">';
$sReturn .= '<h2>'.$title.'</h2>'.<p>'.$text.'</p></div>';
return $sReturn;
}

echo content(2); //geeft -> <div class="content-item"><h2></h2><p></p></div>

Ik heb echt alles geprobeerd: met utfencoding, zonder, met tags, zonder tags, enz enz. Hij wil het gewoon niet doen.
Iemand al iets vergelijkbaars gezien?

[Woef]

PHP:

$sReturn .= '<h2>'.$title.'</h2><p>'.$text.'</p></div>';

punt teveel

[ Voor 6% gewijzigd door Woef op 02-11-2009 12:11 ]

[Janoz]

Als dit je werkelijke code is dan raad ik je aan om eens te stoppen met coden in notepad en een fatsoenlijke IDE met syntax highlighting te gaan gebruiken.

[DEiE]

PHP:

foreach ($aRecords as $key => $value)
{
   $$key = utf8_encode($value);
}

Hier lijkt me wat verkeerd te gaan.
Afgezien de dubbele $ zet je de waarde in de key, die in elke loop wordt aangepast. Als je zoiets ook in je echte code doet zit daar denk ik de fout.

[ValHallASW]

Verwijderd schreef op maandag 02 november 2009 @ 12:08:
met utfencoding, zonder

Als je dat soort dingen probeert dan weet je blijkbaar niet waar je mee bezig bent. Lezen. En inderdaad een editor met syntax highlighting nemen.

[RedRose]

Daarnaast is de $$ niet nodig.. Gebruik liever arrays.

[Woy]

DEiE schreef op maandag 02 november 2009 @ 12:16:

PHP:

foreach ($aRecords as $key => $value)
{
   $$key = utf8_encode($value);
}

Hier lijkt me wat verkeerd te gaan.
Afgezien de dubbele $ zet je de waarde in de key, die in elke loop wordt aangepast. Als je zoiets ook in je echte code doet zit daar denk ik de fout.

Nee daar zit de fout niet, maar het IMHO wel een enorm slechte manier om het te doen. Wat hij hier doet is de waarde van $value in een variabele die de naam van $key heeft zetten.

Het is echter foutgevoelig en voegt niks substantieels toe aan het script.

Hij kan nu alleen $title gebruiken in plaats van dat hij $aRecords[ 'title' ] moet gebruiken. Echter heb je ook de kans dat hij andere variabelen per ongeluk overschrijft. Dus ik zou het gebruik van die constructie zeker afraden.

[DEiE]

Woy schreef op maandag 02 november 2009 @ 12:26:
[...]

Nee daar zit de fout niet, maar het IMHO wel een enorm slechte manier om het te doen. Wat hij hier doet is de waarde van $value in een variabele die de naam van $key heeft zetten.

Het is echter foutgevoelig en voegt niks substantieels toe aan het script.

Hij kan nu alleen $title gebruiken in plaats van dat hij $aRecords[ 'title' ] moet gebruiken. Echter heb je ook de kans dat hij andere variabelen per ongeluk overschrijft. Dus ik zou het gebruik van die constructie zeker afraden.

ahh, die constructie kende ik niet . PHP neemt het ook niet zo nauw met de scope begrijp ik hieruit.

[NMe]

Woy schreef op maandag 02 november 2009 @ 12:26:
[...]

Nee daar zit de fout niet, maar het IMHO wel een enorm slechte manier om het te doen. Wat hij hier doet is de waarde van $value in een variabele die de naam van $key heeft zetten.

Het is echter foutgevoelig en voegt niks substantieels toe aan het script.

Hij kan nu alleen $title gebruiken in plaats van dat hij $aRecords[ 'title' ] moet gebruiken. Echter heb je ook de kans dat hij andere variabelen per ongeluk overschrijft. Dus ik zou het gebruik van die constructie zeker afraden.

Wat ik me dan afvraag is: waarom niet extract($aRecords), als het toch al zo moet?

[Woy]

DEiE schreef op maandag 02 november 2009 @ 12:50:
[...]
PHP neemt het ook niet zo nauw met de scope begrijp ik hieruit.

Het scope gedrag van PHP is perfect gedefinieerd, dus daar zit het probleem niet in. Maar als hij straks bijvoorbeeld een kolom aRecords heeft, wat is dan de output van dit script?

Het maakt onderhoud aan je script gewoon foutgevoeliger. Terwijl er totaal geen probleem is om gewoon aRecords[ 'title' ] te gebruiken in plaats van $title

NMe schreef op maandag 02 november 2009 @ 12:55:
[...]

Wat ik me dan afvraag is: waarom niet extract($aRecords), als het toch al zo moet?

De warning in de docs zou ieder geval al je argwaan moeten wekken

Do not use extract() on untrusted data, like user input (i.e. $_GET, $_FILES, etc.). If you do, for example if you want to run old code that relies on register_globals temporarily, make sure you use one of the non-overwriting extract_type values such as EXTR_SKIP and be aware that you should extract in the same order that's defined in variables_order within the php.ini.

Nou is het resultaat zeker niet altijd untrusted data, maar je kan hele gekke problemen krijgen als je toevallig toch een kolom met de naam van een andere variabele in dezelfde scope hebt . Nou kan je dat natuurlijk gedeeltelijk wel weer ondervangen met EXTR_SKIP, maar dan had je het probleem natuurlijk beter helemaal niet kunnen introduceren.

[ Voor 51% gewijzigd door Woy op 02-11-2009 13:00 ]

[NMe]

Woy schreef op maandag 02 november 2009 @ 12:56:
[...]

De warning in de docs zou ieder geval al je argwaan moeten wekken

Zijn huidige code brengt hetzelfde risico met zich mee. Daarnaast lijkt de naam $aRecords erop dat het data uit de database is, wat betekent dat die invoer bij het erin zetten waarschijnlijk al gecheckt is én je als programmeur precies weet welke variabelenamen je overschrijft.

Ik zeg overigens niet dat ik extract zou gebruiken, maar het is in elk geval op het oog schoner dan wat er nu staat. Toegegeven, intern werkt het hetzelfde.

[Woy]

NMe schreef op maandag 02 november 2009 @ 13:16:
[...]

Zijn huidige code brengt hetzelfde risico met zich mee.

Dat had ik ook al opgemerkt

Woy schreef op maandag 02 november 2009 @ 12:26:
[...]
Hij kan nu alleen $title gebruiken in plaats van dat hij $aRecords[ 'title' ] moet gebruiken. Echter heb je ook de kans dat hij andere variabelen per ongeluk overschrijft. Dus ik zou het gebruik van die constructie zeker afraden.

Daarnaast lijkt de naam $aRecords erop dat het data uit de database is, wat betekent dat die invoer bij het erin zetten waarschijnlijk al gecheckt is én je als programmeur precies weet welke variabelenamen je overschrijft.

Ook dat had ik al opgemerkt

Woy schreef op maandag 02 november 2009 @ 12:56:
Nou is het resultaat zeker niet altijd untrusted data, maar je kan hele gekke problemen krijgen als je toevallig toch een kolom met de naam van een andere variabele in dezelfde scope hebt . Nou kan je dat natuurlijk gedeeltelijk wel weer ondervangen met EXTR_SKIP, maar dan had je het probleem natuurlijk beter helemaal niet kunnen introduceren.

Het is IMHO gewoon een slecht gebruik om extract ( of een eigen variant daarop ) te gebruiken! Het lijkt misschien netter maar dat is het IMHO totaal niet.

[Verwijderd]

Nee, dit is niet mijn werkelijke code, maar een zeer gesimplificeerde versie ervan. Waar het mij in dit topic om te doen is, is dat het op de een of andere manier onmogelijk blijkt om die .= te gebruiken. Uiteraard zat de fout in iets stoms, ik was ergens een . vergeten te zetten, waardoor de boel elkaar overschreef.

Bedankt voor de input!

[NMe]

Woy schreef op maandag 02 november 2009 @ 13:25:
[...]

Het is IMHO gewoon een slecht gebruik om extract ( of een eigen variant daarop ) te gebruiken! Het lijkt misschien netter maar dat is het IMHO totaal niet.

Ik heb het zelf wel eens gebruikt om een query iets korter te kunnen opbouwen. Uiteraard helemaal bewust van de risico's (die non-existent waren in mijn situatie) en van het feit dat het eigenlijk niet zo netjes is. Het is IMO een functie die je verdedigbaar in kan zetten, maar alleen als je de risico's kent.

[Woy]

Verwijderd schreef op maandag 02 november 2009 @ 13:29:
Nee, dit is niet mijn werkelijke code, maar een zeer gesimplificeerde versie ervan. Waar het mij in dit topic om te doen is, is dat het op de een of andere manier onmogelijk blijkt om die .= te gebruiken. Uiteraard zat de fout in iets stoms, ik was ergens een . vergeten te zetten, waardoor de boel elkaar overschreef.

Bedankt voor de input!

Het lijkt me niet dat je de volgende code alleen maar toevoegt voor je voorbeeld

PHP:

foreach ($aRecords as $key => $value) 
{ 
   $$key = utf8_encode($value); 
}

Dus de discussie is IMHO terecht!

NMe schreef op maandag 02 november 2009 @ 13:34:
[...]

Ik heb het zelf wel eens gebruikt om een query iets korter te kunnen opbouwen. Uiteraard helemaal bewust van de risico's (die non-existent waren in mijn situatie) en van het feit dat het eigenlijk niet zo netjes is. Het is IMO een functie die je verdedigbaar in kan zetten, maar alleen als je de risico's kent.

Ik kan niet zo snel een voorbeeld verzinnen waar het te rechtvaardigen is! Als je de risico's kent gaat het natuurlijk ( een stuk ) minder snel mis, maar je introduceert wel een risico op fouten. Een beetje meer typewerk moeten doen is dan IMHO in dit geval geen rechtvaardiging om maar extract te gebruiken.

Nou zullen er vast wel voorbeelden te bedenken zijn waar je het wel wil gebruiken, maar ik zou er het liefst ver vandaan blijven.

[ Voor 4% gewijzigd door Woy op 02-11-2009 14:09 ]

[NMe]

Als ik zelf specificeer welke indexen er in dat array komen en vervolgens het array extract kan er weinig mis lopen, zeker als je het (zoals ik deed) in een lokale function scope doet waar verder alleen een $db en een $context uit de global scope bestaan. Dat ik die niet moet overschrijven onthou ik dan wel, en dat beetje extra codinggemak vind ik daarbij wel fijn. Sowieso zijn $db en $context beiden objecten dus als daar ineens een string in staat krijg je alleen errors als je die probeert aan te spreken, geen securityrisk.

[Verwijderd]

Woy schreef op maandag 02 november 2009 @ 14:08:
Dus de discussie is IMHO terecht!

Ik heb ook nergens beweerd dat je die discussie niet mag voeren. Hij lijkt me alleen niet erg on topic, maar dat terzijde

Overigens ben ik me wel bewust van de risico's die er aan deze methode zitten, maar omdat die non-existent zijn, gebruik ik em toch. Had ik de extract methode gekend, dan had ik die misschien wel gebruikt.

[NMe]

Verwijderd schreef op maandag 02 november 2009 @ 16:25:
[...]

Ik heb ook nergens beweerd dat je die discussie niet mag voeren. Hij lijkt me alleen niet erg on topic, maar dat terzijde

Wij geven het advies dat je nodig hebt niet per se alleen het advies waar je om vraagt.

Overigens ben ik me wel bewust van de risico's die er aan deze methode zitten, maar omdat die non-existent zijn, gebruik ik em toch. Had ik de extract methode gekend, dan had ik die misschien wel gebruikt.

Nou, het gebruik van $$ duidt negen van de tien keer op slecht ontwerp. Het feit dat je dit gebruikt (of extract for that matter) betekent dat je je héél goed moet realiseren wat de risico's zijn én dat het eigenlijk heel erg slecht onderhoudbare code is. Als je je daar terdege van bewust bent kan je het best blijven gebruiken, maar ik zou het niet echt willen aanraden.

[Janoz]

Ik zie niet in waarom die variabelen ge-extract moeten worden. Waarom niet gewoon de array zelf blijven gebruiken? Deze constructie is onveiliger, geheugen intensiever en trager terwijl het enige voordeel is dat de ontwikkelaar nu $var kan tikken ipv $array['var'].

[RedRose]

Verwijderd schreef op maandag 02 november 2009 @ 16:25:
[...]


Ik heb ook nergens beweerd dat je die discussie niet mag voeren. Hij lijkt me alleen niet erg on topic, maar dat terzijde

Overigens ben ik me wel bewust van de risico's die er aan deze methode zitten, maar omdat die non-existent zijn, gebruik ik em toch. Had ik de extract methode gekend, dan had ik die misschien wel gebruikt.

Die discussie is compleet relevant! Je leert jezelf nogal slechte programmeermethoden aan namelijk! En het veranderen van die code is zo ongeveer 3 seconden werk en dan doe je het wel goed.

Maar goed, aangezien je error_reporting ook niet op E_ALL had gezet (anders had je wel een error gekregen op die vergeten punt), vermoed ik ook dat je eigenlijk niet veel op de goede manier wil doen.

Maar haal alsjeblieft die utf8_encode uit je code, want die slaat echt helemaal nergens op. oh nee die was voor de value.