[PHP] variabelen als PHP-code uitschrijven

[Verwijderd]

Beste mensen,

Ik heb een probleempje. Als ik stukje code uit een database ophaal wil ik dit echo-en. Echter zou ik graag willen dat deze als PHP code word uitgeschreven.

code:

    $connection = mysql_connect($host, $user, $pass) or die ("Unable to connect!");
    mysql_select_db($db) or die ("Unable to select database!"); 
    $query = "SELECT * FROM tabel "; 
    $result = mysql_query($query) or die ("Error in query: $query. ".mysql_error()); 
    

    if (mysql_num_rows($result) > 0) { 

        // met een while loop, zolang er rijen zijn haal de gegevens eruit
        while($row = mysql_fetch_assoc($result)) { 
            echo "<p>".$row["Inhoud"]."</p>\n"; 
        } 

    } 
    mysql_free_result($result); 
    mysql_close($connection);

Dit zal vervolgens uitschrijven:
$variabele = "inhoud_variabele";

Maar wat graag zou willen is dat $variabele gedeclareerd gaat worden als inhoud_variabele voor verder gebruik. Heeft iemand enig idee hoe ik dit kan doen?

[RobIII]

Verwijderd schreef op zaterdag 07 februari 2009 @ 21:08:
Dit zal vervolgens uitschrijven:
$variabele = "inhoud_variabele";

Euh; waar in bovenstaande code wordt dat uitgeschreven dan? Op regel 11 zie ik wel een echo, maar die echo't de inhoud van een MySQL veld?

Verwijderd schreef op zaterdag 07 februari 2009 @ 21:08:
Maar wat graag zou willen is dat $variabele gedeclareerd gaat worden als inhoud_variabele voor verder gebruik. Heeft iemand enig idee hoe ik dit kan doen?

Ik begrijp niet helemaal wat je nou bedoelt of wil bereiken? Bedoel je zoiets

[ Voor 52% gewijzigd door RobIII op 07-02-2009 21:13 ]

[Verwijderd]

hmm fout voorbeel idd. Waar het mij om gaat is dat een als er een string in een variabele zit de string kan worden uitgeschreven als PHP code.

[Verwijderd]

Je spreekt echt in raadsels. Waarom werk je niet gewoon met de array $row?

[RobIII]

PHP:

$foo = 'bar';
$bar = 123 ;
echo $$foo;
//Output: 123

Zie ook eens: Variable variables

Verwijderd schreef op zaterdag 07 februari 2009 @ 21:14:
Je spreekt echt in raadsels.

Probeer even een beetje leesbaarheid in je zinnen aan te brengen voor je op "Verstuur bericht" ramt

[ Voor 85% gewijzigd door RobIII op 07-02-2009 21:17 ]

[Verwijderd]

Wat je bedoelt is waarschijnlijk eval.

Maar dit is totaal niet de netste manier om dit op te lossen. En al helemaal niet de veiligste.

[storeman]

Hmm, je probleem is niet echt duidelijk. Wil je debuggen, dan zul je de output toch vooral handmatig moeten formatteren icm met de print functie.

[Verwijderd]

TeMo snapt mijn probleem. Excuses ik heb geprobeerd het zo duidelijk mogelijk op te schrijven, is niet gelukt. Met eval zou ik waarschijnlijk inderdaad mijn probleem kunnen oplossen.

[Verwijderd]

Verwijderd schreef op zaterdag 07 februari 2009 @ 21:20:
TeMo snapt mijn probleem. Excuses ik heb geprobeerd het zo duidelijk mogelijk op te schrijven, is niet gelukt. Met eval zou ik waarschijnlijk inderdaad mijn probleem kunnen oplossen.

Met eval kun je jouw eigenlijke probleem niet oplossen. Jouw probleem is waarschijnlijk dat je geen betere oplossing hebt dan je nu hebt bedacht. Eval is zelden een oplossing doch vrijwel altijd een indicatie van onervarenheid

[Verwijderd]

Verwijderd schreef op zaterdag 07 februari 2009 @ 21:20:
TeMo snapt mijn probleem. Excuses ik heb geprobeerd het zo duidelijk mogelijk op te schrijven, is niet gelukt. Met eval zou ik waarschijnlijk inderdaad mijn probleem kunnen oplossen.

Maar als ik jou was zal ik het niet gaan gebruiken. Als mensen op een of andere manier toegang kunnen krijgen tot de database (sql-injection) dan euhm, denk ik dat je een nog groter probleem hebt.

[Janoz]

Je probleem is niet opgelost. Je hebt gewoon het ene probleem voor het andere vervangen. Eval is evil en je zou het zo veel mogelijk moeten vermijden. Het zorgt alleen maar voor slecht onderhoudbare en onveilige code.

De grote vraag blijft nog steeds waarom je denkt dat je uit de database gehaalde code uit zou moeten voeren. Daar zit namelijk je echte achterliggende probleem.

[BCC]

Verplicht leesvoor: http://www.google.com/search?q=eval+is+evil

[MueR]

Om maar eens een oude uit de kast te trekken: If eval is the answer, you're asking the wrong question.

Je moet

1. Geen code uit je database willen halen,
2. Geen code uit je database hoeven halen,
3. Geen code uit je database halen.

Code moet je uitschrijven in een relatief feilloos mechanisme. Dat is een DB niet, een bestand op je hdd wel.

[ Voor 54% gewijzigd door MueR op 07-02-2009 22:12 ]

[Verwijderd]

hmm ok.Ik denk dat ik weet wat mijn beslissing gaat worden....

GEEN EVAL .

Bedankt mensen!

[Creepy]

Maar wat wordt de oplossing dan wel en wat is het echte probleem nu eigenlijk?

[storeman]

Om nog maar even op eval door te gaan. Ik gebruik het nooit, maar laatst liep ik tegen iets aan waar ik echt geen betere oplossing voor hand dan /ev[ai]l/, ik wilde een x aantal kolommen van een multidim array sorteren. Het aantal kolommen was onbekend. Een dergelijke situatie vroeg écht om eval.

PHP:

/**
     * Sort an multidim array (that has the form of a table).
     * 
     * @param array $data The table data: array( 'row1'=>array('cell1', 'cell2'))
     * @param array $sortOptions array( 'firstSortColumn'=>array('key'=>'theColumnKey', 'direction'=>'ASC|DESC', 'type'=>'NUMERIC|STRING|REGULAR'), 'scndSortco.... 
     */
    static public function tableSort( array $data, array $sortOptions, $blnCaseInsensitive = true ){
        
        // When there is nothing to sort, the 
        if( count( $data ) == 0 ) return $data;
        
        // Invert the tabular data (sorting by column
        $columns = self::invertTable( $data );
        if( count( $columns ) == 0 ) return $data;
        
        
    /* Snip... */
        
        foreach( $allKeys as $key ){
            $lSort .= '$sColumns[' . $key . '], ';
            if( $blnCaseInsensitive ) $nSort .= '$columns[' . $key . '], ';
        }
        
        if( substr($lSort . $nSort, -2 ) == ', ' ) $sort = substr($lSort . $nSort, 0, -2);
        else $sort = $lSort . $nSort;
        
        eval( 'array_multisort(' . $sort . ');' );
        
        // Rebuild to table and return
        return self::invertTable( $blnCaseInsensitive ? $columns : $sColumns );
    }

[ Voor 24% gewijzigd door storeman op 08-02-2009 11:43 . Reden: Code verkleint ]

[Voutloos]

Wat een draak van een code.
Ken je sorteer algoritmes, weet wanneer je bijvoorbeeld recursiviteit of callbacks kan gebruiken etc. etc. en je hebt voor het sorteren van zaken geen eval() nodig. Bij het schrijven van deze code heb je van begin af aan eval() in je hoofd gehad...

Overigens zijn variabele variabelen (post RobIII) ook enorm evil en ook zeker geen oplossing in dit topic, alsmede in 999 vd 1000 topics.

[RobIII]

Voutloos schreef op zondag 08 februari 2009 @ 11:52:
Overigens zijn variabele variabelen (post RobIII) ook enorm evil en ook zeker geen oplossing in dit topic, alsmede in 999 vd 1000 topics.

Dat is waar; maar gegeven de érg karige info van de TS en het ontbreken van enige context is het wel het antwoord op z'n vraag (voor zover ik er hout van kan snijden that is)

[.oisyn]

storeman schreef op zondag 08 februari 2009 @ 11:42:
Een dergelijke situatie vroeg écht om eval.

Nee, een dergelijke situatie vroeg om degelijke programma-structuur en het goed lezen van de documentatie. Dit stuk code gaat werkelijk helemaal nergens over.

Zonder je code alteveel aan te hoeven passen zou je bijvoorbeeld al eens kunnen kijken naar call_user_func

[ Voor 22% gewijzigd door .oisyn op 08-02-2009 15:11 ]

[storeman]

@Voutloos: Ik zie niet in waarom en hoe ik dit probleem op zou kunnen lossen met recursieve functies (ongetwijfeld een tekortkoming van mij, maar ik ben zeer benieuwd!)

@.oisyn: Inderdaad, de call_user_func is inderdaad een vele malen nettere oplossing voor dit probleem. Ik ga direct deze functie vervangen door iets wat een stukje beter te overzien en te doorgronden is.

Ik had de eval uit de php.net-comments getrokken en aangepast.

[Noork]

Gaat het er niet gewoon om dat de topicstarter stukjes code uit de db in een website/blog o.i.d. wil publiceren. Niet dat het wordt uitgevoerd, maar dat er staat iets als:

PHP:

<?
echo "Hoi ik ben een php-script";
?>

[Cartman!]

Hij wil het dus juist wel uitvoeren

[Noork]

Cartman! schreef op dinsdag 10 februari 2009 @ 13:12:
Hij wil het dus juist wel uitvoeren

Aha okay, dat was me niet duidelijk. Maar goed, dan zou ik het verder ook niet weten. Misschien zou de TS een php code ophalen uit de db om vervolgens weg te schrijven in een bestand en deze te includen.

[.oisyn]

storeman schreef op dinsdag 10 februari 2009 @ 12:54:
@Voutloos: Ik zie niet in waarom en hoe ik dit probleem op zou kunnen lossen met recursieve functies of callbacks (ongetwijfeld een tekortkoming van mij, maar ik ben zeer benieuwd!)

call_user_func() lijkt me praktischer, maar als je zonder array_multisort meerdere arrays wilt sorten dan kun je dat doen met usort() op een array van indices en een user callback die adhv die indices de elementen vergelijkt. Daarna kun je de gesorteerde array van indices gebruiken om je meerdere arrays te remappen.

PHP:

class MultiArrayComparer
{
    var $arrays;

    function __construct($arrays)
    {
        $this->arrays = $arrays;
    }

    function compare($a, $b)
    {
        foreach ($arrays as $array)
        {
            if ($array[$a] < $array[$b])
                return -1;
            if ($array[$a] > $array[$b])
                return 1;
        }
        return 0;
    }
}

// pre:
//      count($arrays) > 0
//      alle arrays in $array zijn even lang en hebben dezelfde keys
//      waarden in $arrays[x] zijn significanter dan die in $arrays[x+1]
// post:
//      returnt gesorteerde arrays, keys zijn indices
function my_array_multisort($arrays)
{
    $c = new MultiArrayComparer($arrays);
    $a = array_keys($arrays[0]);

    // sort
    usort($a, array($c, "compare"));

    // remap
    $ret = array();
    foreach($arrays as $array)
    {
        $r = array();
        foreach($a as $k => $v)
            $r[$k] = $array[$v];
        $ret[] = $r;
    }
    return $ret;
}

Zoiets. Ongetest.

[ Voor 7% gewijzigd door .oisyn op 10-02-2009 13:26 ]

[steffex]

bedoel je dit: hightlight_string()??

[Cartman!]

stef-o schreef op dinsdag 10 februari 2009 @ 13:52:
bedoel je dit: hightlight_string()??

Doe even moeite om het topic te lezen anders...

Noork: dat verandert niets aan het probleem dat ie dan een verkeerde aanpak heeft bedacht, je maakt dan meer andere vieze workaround om maar geen eval te gebruiken.

[Sebazzz]

Noork schreef op dinsdag 10 februari 2009 @ 13:16:
[...]

Aha okay, dat was me niet duidelijk. Maar goed, dan zou ik het verder ook niet weten. Misschien zou de TS een php code ophalen uit de db om vervolgens weg te schrijven in een bestand en deze te includen.

Wat veranderd dat eraan? Het is gewoon hetzelfde, en gevaarlijke code kan gewoon worden uitgevoerd. Je moet je probleem altijd aanpakken met het idee dat zelf code maken en uitvoeren niet de optie is. Ik denk altijd maar: Het is net alsof je C# schrijft of C++. Je hebt niet de mogelijkheid om ge-outputte code te compileren en uit te voeren.

[Verwijderd]

Even los van het huidige probleem is het jammer dat vele posters meteen weer de standaard eval is evil achte opmerkingen van stal halen. Eval is niet evil en heeft wel degelijk zijn nut. Je moet alleen verdomd zeker weten dat jij en alleen jij bepaalt wat de invoer is die Eval ontvangen mag. Ditzelfde geld voor bijvoorbeeld SQL queries en die vind ook niemand evil dacht ik zo.

Omdat "internet" iets vindt is het nog niet waar...

[.oisyn]

Volgens mij moet jij de definitie van evil nog eens opzoeken. Dat iets evil is betekent niet dat je het nooit en te nimmer mag gebruiken.

De C++ FAQ lite legt het bijvoorbeeld mooi uit

Eval is evil. Niet omdat het op internet staat, maar omdat daar weldegelijk valide argumenten achter zitten. En goh, precies om die argumenten staat het toevallig ook op internet.

[ Voor 56% gewijzigd door .oisyn op 10-02-2009 15:28 ]

[Verwijderd]

Waar zeg ik dan dat evil dat betekent? Je legt me nu woorden in de mond. Het voorbeeld wat jij geeft is inderdaad een uiterst genuanceerde uitleg van de context van het gebruik van de term evil. Ik kan me er zelfs in vinden, alleen vind ik dat als je iets niet bedoelt dat je het dan ook niet moet zeggen, de letterlijke definitie van evil.

Het voorbeeld is en blijft namelijk een verkeerde uitleg van het woord evil. Als we het dan toch over definities willen hebben:

evil

• adjective 1 deeply immoral and malevolent. 2 embodying or associated with the devil. 3 extremely unpleasant: an evil smell.

• noun 1 extreme wickedness and depravity, especially when regarded as a supernatural force. 2 something harmful or undesirable.

Ik zou de term "ill-advised" dan wel weer kunnen waarderen

Helaas lezen heel veel mensen die uitleg van jou niet. Om die redenen denken heel veel programmeurs dat GOTO statements in de negende kring van de Hel zouden moeten branden, vlak naast.... inderdaad de eval functie. Eval is niet evil, Eval kan echter wel heel evil toegepast worden. Maar dat geld voor ongeveer alles op de wereld...

[.oisyn]

Verwijderd schreef op dinsdag 10 februari 2009 @ 15:41:
Helaas lezen heel veel mensen die uitleg van jou niet. Om die redenen denken heel veel programmeurs dat GOTO statements in de negende kring van de Hel zouden moeten branden

Precies de bedoeling. De programmeurs die dat denken moeten dat juist denken. De programmeurs die wat verder zijn kunnen voor zichzelf argumentatie verzinnen waarvoor en wanneer ze een bepaalde feature wel of niet gebruiken. Die programmeurs zijn het stadium al voorbij dat ze waarde hechten aan opmerkingen die voornamelijk aan beginners gericht zijn. Die zullen niet iets doen "omdat het op internet staat".

Jouw nuancering bereikt helemaal niets. Je kunt wel zeggen dat een "evil" feature in sommige situaties wel kan helpen, maar de meeste beginnende programmeurs weten alsnog niet in welke situaties. Sterker nog, ze zouden er weleens van overtuigd kunnen zijn dat de situatie waar ze op dat moment in zitten weldegelijk om die feature vraagt (de post van storeman is hier een uitstekend voorbeeld van - niet dat ik hem verder wil betichten van het zijn van een beginnende of novice programmeur overigens).

Daarom kiest men de overdreven term "evil". Op het moment dat je voor jezelf kan bepalen dat het niet waar is dan heb je dat advies ook niet meer nodig.

Overigens:

Verwijderd schreef op dinsdag 10 februari 2009 @ 15:41:
Waar zeg ik dan dat evil dat betekent? Je legt me nu woorden in de mond.

Nee, dat doe je zelf. Je zei namelijk:

Eval is niet evil en heeft wel degelijk zijn nut.

Daarmee impliceer je dat "evil" in de hier gebruikte context zou betekenen dat het nooit nut heeft. En ik leg uit dat dat niet de kern is van het woord "evil"

Overigens past de definitie waar je zelf mee kwam, namelijk "something harmful or undesirable", er weldegelijk perfect bij. Eval() *is* harmful en undesirable.

[ Voor 22% gewijzigd door .oisyn op 10-02-2009 16:03 ]

[Janoz]

Het punt is juist dat er eigenlijk geen toepassing van eval is die niet op een nette manier zonder eval geimplementeerd kan worden. In 99.9% van de gevallen is het gebruik van eval toe te kennen aan een incompetente programmeur of een smerige hack. Je kunt dus met een aan zekerheid grenzende waarschijnlijkheid zeggen dat bijna elk gebruik van eval evil is.

Je punt over SQL is valide. Dat blijkt alleen al uit de hoeveelheid bugs en security fouten er worden veroorzaakt door problemen met queries (Dan heb ik het niet eens over sql-injecties, maar ook over het moeten controleren van je query syntax @ runtime ipv compile-time waardoor het van belang is dat je test alle excutiebranches afdekt). Gelukkig wordt dat probleem opgepakt door O/R mappers en Linq.

[ Voor 14% gewijzigd door Janoz op 10-02-2009 16:14 ]

[Fishbeast]

Janoz schreef op dinsdag 10 februari 2009 @ 16:06:
Je punt over SQL is valide.

ben ik het niet helemaal mee eens, omdat je dan stiekum wel een beetje appels met peren aan het vergelijken bent.
SQL had/heeft imho een heel ander(e) doel/toepassing dan zoiets als een taal zoals PHP, Java C# enz.

[Noork]

Sebazzz schreef op dinsdag 10 februari 2009 @ 14:53:
[...]
Wat veranderd dat eraan? Het is gewoon hetzelfde, en gevaarlijke code kan gewoon worden uitgevoerd. Je moet je probleem altijd aanpakken met het idee dat zelf code maken en uitvoeren niet de optie is.

Dat verandert niks. Maar het was ook meer mijn bedoeling om een praktische oplossing te geven. Wanneer de TS de code zelf in z'n database knalt, voor b.v. een persoonlijke site, dan heb ik er niks op tegen. Is wat anders natuurlijk als Jan en alleman dit zomaar kan doen.

[Janoz]

Fishbeast schreef op dinsdag 10 februari 2009 @ 16:11:
[...]


ben ik het niet helemaal mee eens, omdat je dan stiekum wel een beetje appels met peren aan het vergelijken bent.
SQL had/heeft imho een heel ander(e) doel/toepassing dan zoiets als een taal zoals PHP, Java C# enz.

Terwijl ik mijn post edit (wat context gegeven aan de sql opmerking) zie ik dat er reacties op gekomen zijn. Het punt is dat je in je code een variabele hebt waarin uitvoerbare code staat welke tijdens runtime opgebouwd wordt en dus ook pas tijdens runtime syntactisch en semantisch gevalideerd kan worden.

Goed, ze evil als eval is het niet, maar de redenatie die gebruikt wordt om eval af te wijzen gaat in zekere mate ook op voor strings met sql code die naar de DB gestuurd worden.

Noork schreef op dinsdag 10 februari 2009 @ 16:14:
Dat verandert niks. Maar het was ook meer mijn bedoeling om een praktische oplossing te geven. Wanneer de TS de code zelf in z'n database knalt, voor b.v. een persoonlijke site, dan heb ik er niks op tegen. Is wat anders natuurlijk als Jan en alleman dit zomaar kan doen.

Het enige dat je bereikt is dat je je evil oplossing obfuscate. IMHO ben je daarmee alleen maar verder van huis. Goed, je hebt nu niet meer het commando evil in de code staan, maar je hebt vervolgens wel een world writable map waarin executable code geschreven wordt. Als ik al uit deze twee kwaden zou moeten kiezen dan zou ik absoluut voor de eval kiezen.

[ Voor 30% gewijzigd door Janoz op 10-02-2009 16:25 ]

[Fishbeast]

en wat ik dan vreemd vind, is dat het punt dat flijten aanhaalde over dat niemand SQL evil vind.
want je zou eens moeten kijken hoevel mensen er nog gewoon SQL typen in hun code i.p.v. een O/R mapper te gebruiken. (bijvoorbeeld tegen dingen als sql-injection)

[Janoz]

Dat klopt, maar dat komt omdat O/R mappers redelijk nieuw zijn en dergelijke abstractie lagen zijn nog lang niet overal beschikbaar, laat staan standaard geïntegreerd in het platform.

[Verwijderd]

Ho eens ik ga ook even vlees halen en marineren zeg

.oisyn schreef op dinsdag 10 februari 2009 @ 15:55:

Precies de bedoeling. De programmeurs die dat denken moeten dat juist denken. De programmeurs die wat verder zijn kunnen voor zichzelf argumentatie verzinnen waarvoor en wanneer ze een bepaalde feature wel of niet gebruiken. Die programmeurs zijn het stadium al voorbij dat ze waarde hechten aan opmerkingen die voornamelijk aan beginners gericht zijn. Die zullen niet iets doen "omdat het op internet staat".

Jouw nuancering bereikt helemaal niets. Je kunt wel zeggen dat een "evil" feature in sommige situaties wel kan helpen, maar de meeste beginnende programmeurs weten alsnog niet in welke situaties. Sterker nog, ze zouden er weleens van overtuigd kunnen zijn dat de situatie waar ze op dat moment in zitten weldegelijk om die feature vraagt (de post van storeman is hier een uitstekend voorbeeld van - niet dat ik hem verder wil betichten van het zijn van een beginnende of novice programmeur overigens).

Daarom kiest men de overdreven term "evil". Op het moment dat je voor jezelf kan bepalen dat het niet waar is dan heb je dat advies ook niet meer nodig.

Tja ik heb misschien iets meer vertrouwen in het gezond verstand van mensen (of in dat van de schrijvers van api's/tutorials) dan de gemiddelde mens. Volgens die redenatie moet je prozac ook verkopen met de melding dat het evil is erbij. Maar goed, volgens mij denken we beide hetzelfde over Eval en verschillen we slechts van mening over de manier om de functie aan te duiden.

Daarmee impliceer je dat "evil" in de hier gebruikte context zou betekenen dat het nooit nut heeft. En ik leg uit dat dat niet de kern is van het woord "evil"

Als ik nou had gezegd "Eval is niet evil, want heeft wel degelijk zijn nut" ipv "Eval is niet evil, en heeft wel degelijk zijn nut" was ik het met je eens geweest. Nu leg je me toch echt gewoon woorden in de mond.

Overigens past de definitie waar je zelf mee kwam, namelijk "something harmful or undesirable", er weldegelijk perfect bij. Eval() *is* harmful en undesirable.

Das waar

Ach in het kort zijn we volgens mij aan het bakkeleien over grammatica Ik moest net denken aan een briljante XKCD die overigens even goed op mij betrekking heeft als op anderen:

Fishbeast schreef op dinsdag 10 februari 2009 @ 16:11:
[...]
ben ik het niet helemaal mee eens, omdat je dan stiekum wel een beetje appels met peren aan het vergelijken bent.
SQL had/heeft imho een heel ander(e) doel/toepassing dan zoiets als een taal zoals PHP, Java C# enz.

Het is helemaal geen appels met peren vergelijken. Ze hebben uiteraard een ander doel, maar in beide gevallen is het iets wat niet per definitie slecht is, maar wel als zodanig misbruikt kan worden. Ik had in plaats van SQL ook politiek kunnen noemen, maar ik wou het dichter bij huis houden

[Verwijderd]

Verwijderd schreef op dinsdag 10 februari 2009 @ 17:54:

Tja ik heb misschien iets meer vertrouwen in het gezond verstand van mensen (of in dat van de schrijvers van api's/tutorials) dan de gemiddelde mens.

De meeste tutorials zijn door prutsers geschreven, die iets voor zichzelf duidelijker wilden krijgen.

[Noork]

Verwijderd schreef op dinsdag 10 februari 2009 @ 19:24:
[...]

De meeste tutorials zijn door prutsers geschreven, die iets voor zichzelf duidelijker wilden krijgen.

En daarmee is het eindresultaat van een tutorial ook altijd prut. Kun je niks zinnigers toevoegen?

[skabouter]

Ok ik denk even out-of-the-box, maar waarom schrijf je het gene wat je uit de DB hebt gehaald niet weg in een .php file die je vervolgens weer include? Wat je vervolgens kunt doen is ervoor zorgen dat je de code zelfs in een functie in een class zet, zodat je geen problemen krijgt met scoping, voorbeeldje;

PHP:

<?
# Dit bestand is geschreven vanuit PHP bla bla bla...
class foo{
    function bar(){
        #plaats hier uw PHP code vanuit de DB
     }
}
?>

is dat geen optie? Natuurlijk nogsteeds niet heel netjes, maar imao wel netter dan het gebruik van eval()

[Verwijderd]

skabouter schreef op dinsdag 10 februari 2009 @ 19:48:

is dat geen optie? Natuurlijk nogsteeds niet heel netjes, maar imao wel netter dan het gebruik van eval()

Waarom is het netter? Ik zie eigenlijk weinig verschil.

Het eigenlijke probleem los je er ook niet mee op, namelijk het probleem dat je niet met een betere oplossing bent gekomen.

[skabouter]

Verwijderd schreef op dinsdag 10 februari 2009 @ 19:51:
[...]

Waarom is het netter? Ik zie eigenlijk weinig verschil.

Het eigenlijke probleem los je er ook niet mee op, namelijk het probleem dat je niet met een betere oplossing bent gekomen.

Nah ja op de vraag van de topicstarter is geen 'goede' oplossing naar mijn weten, maar dat heeft MueR al duidelijk aangegeven.

Met deze methoden kan ik me voorstellen dat je wat meer controle kunt uitoefenen op de code die wordt uitgevoerd. Plus dat je extra gratis validatie en debugging erbij krijgt die gegeven wordt doordat het ebstand ge-include wordt. Verder blijft het natuurlijk dirty.

[.oisyn]

skabouter schreef op dinsdag 10 februari 2009 @ 19:48:
Natuurlijk nogsteeds niet heel netjes, maar imao wel netter dan het gebruik van eval()

Ja dan heb je het idd begrepen . Heb je eigenlijk weleens stilgestaan waarom het gebruik van eval() afgeraden wordt? Want nu ben je gewoon een omweg aan het verzinnen om eval() niet aan te roepen maar wat dezelfde functionaliteit geeft. Echter is het uiteraard die functionaliteit zelf die ten grondslag is aan de evilness van eval(). Het is niet dat de functie zelf bugt oid.

Dus waarom is eval() eigenlijk evil?
* potentieel erg gevaarlijk, afhankelijk van waar je input vandaan komt
* lastig te debuggen en te maintainen - vaak ongestructureerde code
* voor (vrijwel) elke situatie waarin je eval() kunt gebruiken is meestal wel een goede nette andere oplossing te vinden
* doorgaans slechtere performance dan de andere methoden (alhoewel dat op zichzelf geen reden is om het niet te gebruiken)
Dit zijn even de punten die ik zo snel kon bedenken, als iemand nog andere argumenten weet, geef maar een gil

Wat verandert het includen van files, wat hetzelfde is als eval() maar dan met een omweg, aan deze punten?

Het enige zinnige nut van eval() (en waar het ook voor gemaakt is) is als je direct code wilt uitvoeren. Als doel dus, niet als oplossing voor je probleem. Als je doel zelf verder weinig te maken heeft met het uitvoeren van code dan is eval() niet de oplossing.

[ Voor 84% gewijzigd door .oisyn op 10-02-2009 20:11 ]

[NMe]

Noork schreef op dinsdag 10 februari 2009 @ 19:33:
[...]

En daarmee is het eindresultaat van een tutorial ook altijd prut. Kun je niks zinnigers toevoegen?

Zullen we verder maar lief blijven doen tegen elkaar?

[Noork]

NMe schreef op dinsdag 10 februari 2009 @ 20:37:
[...]

Zullen we verder maar lief blijven doen tegen elkaar?

Okay

.oisyn schreef op dinsdag 10 februari 2009 @ 19:57:
[...]
Dus waarom is eval() eigenlijk evil?
.........
Wat verandert het includen van files, wat hetzelfde is als eval() maar dan met een omweg, aan deze punten?

Dat eval() potentieel gevaarlijk is, is nu wel duidelijk. Maar het ligt natuurlijk ook aan de toepassing. Wellicht is het een prima oplossing voor de TS.

Maar het includen van files heeft wel enkele voordelen. Je hoeft deze nl. alleen aan te maken wanneer je wijzigingen in je db hebt gedaan. Dat scheelt dus weer wat connecties.

[Cartman!]

Ik herhaal maar weer wat ik n paar uur geleden zei:

Noork: dat verandert niets aan het probleem dat ie dan een verkeerde aanpak heeft bedacht, je maakt dan meer andere vieze workaround om maar geen eval te gebruiken.

Het probleem is gewoon een enorme denkfout, code op willen slaan in een database en daarna weer uitvoeren. En of je nu eval() gebruikt, de zooi wegschrijft naar files om ze dan uit te voeren of wat dan ook maakt niet meer uit...je hebt de fout gewoon al gemaakt. De TS moet gewoon voor zichzelf nagaan hoe hij het originele probleem kan oplossen ipv. workarounds proberen die eval() omzeilen maar eigenlijk stiekem hetzelfde doen.

[Verwijderd]

Cartman! schreef op dinsdag 10 februari 2009 @ 22:48:
Ik herhaal maar weer wat ik n paar uur geleden zei:


[...]


Het probleem is gewoon een enorme denkfout, code op willen slaan in een database en daarna weer uitvoeren.

Nou nou, wat een denkfout zeg...iedereen die programmeert doet het. Een FS is ook gewoon een database, daar zet je ook code in die je later graag uitgevoert ziet worden. Je sourcefiles bijvoorbeeld.

Of zeg ik nu iets wat heel raar klinkt?

[TeeDee]

Verwijderd schreef op dinsdag 10 februari 2009 @ 23:05:
[...]
Nou nou, wat een denkfout zeg...iedereen die programmeert doet het.

Mwah, met alle respect, maar iemand die serieus is doet dat niet.

Een FS is ook gewoon een database, daar zet je ook code in die je later graag uitgevoert ziet worden. Je sourcefiles bijvoorbeeld.

Als ik bv. geen execute rechten op dat file zet gebeurt er niks. Dat is om te beginnen al een stuk lastiger via een DB te doen. Ten 2e denk je dat je de ideale, super handige oplossing gevonden hebt. Wat, in het geval van een website, als iemand besluit een complete "rm -rf" code in je DB te zetten middels een contact formulier en eens besluit om dit uit te gaan voeren. "Tuurlijk, dit handige dingetje (automagisch code in mijn DB injecteren omdat het zo lekker snel gaat) gebruik ik alleen." Totdat je geroot bent omdat er ergens een eval uitgevoerd wordt. Sourcefiles op je FS zijn makkelijker af te bakenen en te controleren. Verder zijn er al een aantal redenen voor het gebruik van eval geplaatst.

Eval is niet te controleren. Tenzij je een shitload aan onsamenhangende code daaromheen gaat maken om dat wel te doen. Wat let je dan om die code simpelweg in een file, library of weet ik veel wat te plaatsen. Waarom nog een abstractie laag ergens aan toevoegen?

[boe2]

Persoonlijk vind ik sql syntax meer "evil" dan eval, aangezien je hiermee veel gemakkelijker schade kan aanrichten. Het is ook veel gemakkelijker om de structuur van een database te achterhalen én aan te passen via sql injectie dan eender welk soort kwaad uit te voeren door kwaadaardige code in die eval te proberen krijgen, tenzij je al op de hoogte bent van de gehele structuur van je code en alle bijhorende classes.

*edit* ik dacht niet buiten het programma + bijhorende database gebeuren. Als je het misbruikt om het OS te manipuleren is het wel "iets" gevaarlijker ja

[ Voor 16% gewijzigd door boe2 op 11-02-2009 00:16 ]

[TeeDee]

Boeboe schreef op woensdag 11 februari 2009 @ 00:14:
Persoonlijk vind ik sql syntax meer "evil" dan eval, aangezien je hiermee veel gemakkelijker schade kan aanrichten. Het is ook veel gemakkelijker om de structuur van een database te achterhalen én aan te passen via sql injectie dan eender welk soort kwaad uit te voeren door kwaadaardige code in die eval te proberen krijgen, tenzij je al op de hoogte bent van de gehele structuur van je code en alle bijhorende classes.

Parameterised querys en fatsoenlijke errorhandling en dan ben je daar ook vanaf. Wil je het helemaal gers doen: pak een O/R mapper, zoals ook al reeds aangegeven. LLBLGen, Hibernate whatever.
Ook hier geldt: weet wat je doet, bedenk wat de problemen van jouw ietsie-pietsie code kunnen zijn. Tuurlijk is SQL ook te misbruiken;

SQL:

    CREATE PROCEDURE [DynamicTPSBuilder] (@SQL VARCHAR(8000) ) AS BEGIN
      SET NOCOUNT ON
      SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
      EXEC (@SQL)
      RETURN(-1)
    END

Dit is de SQL variant van PHP's eval.

[ Voor 9% gewijzigd door TeeDee op 11-02-2009 09:01 . Reden: SQL statement aangepast. ]

[.oisyn]

Boeboe schreef op woensdag 11 februari 2009 @ 00:14:
Persoonlijk vind ik sql syntax meer "evil" dan eval, aangezien je hiermee veel gemakkelijker schade kan aanrichten.

Idd, een database wijzigen is idd véél schadelijker dan custom code op een server kunnen runnen
.edit: bliep, daar was je al achter, ik had even over je edit heengelezen

[ Voor 10% gewijzigd door .oisyn op 11-02-2009 01:07 ]

[Voutloos]

Noork schreef op dinsdag 10 februari 2009 @ 22:41:
Wellicht is het een prima oplossing voor de TS.

Newsflash: De ts houdt zich van begin af aan al compleet afzijdig in deze discussie en het is imo nog steeds niet duidelijk wat de bedoeling was. Tenzij je de bedoeling weet, en weet dat je met de vuistregel kan breken is eval() gewoon niet een prima oplossing.

Klaar. En php code wegschrijven en dan includen is zo mogelijk nog stommer. Dan heb je alle slechte punten van eval(), maar dan ook nog extra slecht te herkennen.

Dit topic gaat echt nergens over, behalve dan dat een aantal mensen graag posts hier maken welke prima in een bestaand topic passen: [alg] Slechtste programmeervoorbeelden deel 4

[Janoz]

Verwijderd schreef op dinsdag 10 februari 2009 @ 23:05:
[...]

Nou nou, wat een denkfout zeg...iedereen die programmeert doet het. Een FS is ook gewoon een database, daar zet je ook code in die je later graag uitgevoert ziet worden. Je sourcefiles bijvoorbeeld.

Of zeg ik nu iets wat heel raar klinkt?

Je argumentatie loopt mis op 1 punt. Tijdens de uitvoer van je applicatie is het de bedoeling dat de applicatie de inhoud van de database aan kan passen. Tijdens de uitvoer blijft de source echter stabiel. Schrijfrechten op de directory waarin de sources staan is not done en wordt als een security hole gezien. Vanuit het perspectief van de uitvoerende code is het FS deel waar de sources staan dus absoluut niet als een (writable) database te zien.

[drm]

Janoz:
Je argumentatie loopt mis op 1 punt. Tijdens de uitvoer van je applicatie is het de bedoeling dat de applicatie de inhoud van de database aan kan passen. Tijdens de uitvoer blijft de source echter stabiel. Schrijfrechten op de directory waarin de sources staan is not done en wordt als een security hole gezien. Vanuit het perspectief van de uitvoerende code is het FS deel waar de sources staan dus absoluut niet als een (writable) database te zien.

Dat is wel op te lossen. Je verbindt gewoon met een user die alleen select-rechten heeft op die tabel.

Volgens mij is het vooral een wan-ontwerp. Als je deze oplossing bedenkt zit je op een verkeerd spoor omdat het ontwerp van je systeem ondoorzichtig wordt, het systeem zelf wordt slecht onderhoudbaar, waarschijnlijk instabiel en mogelijk onveilig. Als dat niet genoeg redenen zijn om deze aanpak niet te kiezen dan houdt het op.