[php] variabelen vraagje

[Verwijderd]

Ik heb al redelijk wat ervaring met php programmeren en het meeste het ik geleerd uit "zelfstudie". Het nadeel daarvan is dat je een beetje blijft hangen in eerdere ervaringen.

zo zag ik laatst in de Computer Totaal (geloof ik) een stukje in een php handleiding waar ze het volgende deden.

PHP:

$var = "tussen";
$string = "de boom staat {$var} de struiken".

echo $string;

wat verschilt dit van:

PHP:

$var = "tussen";
$string = "de boom staat ". $var ." de struiken".

echo $string;

Ik gebruik zelf altijd de onderste methode, maar vroeg me af wat het verschil is tussen beide manieren?

[Verwijderd]

hm het vershil... goede vraag...

je kunt toch ook zo:

PHP:

<?
$var = "tussen";
$string = "de boom staat $var de struiken";

echo $string;
?>

de kwestie oplossen?

ik denk trouwens dat het gewoon notatievormen zijn... zoals je ook met

if en else den ? en : kunt gebruiken...

[ Voor 43% gewijzigd door Verwijderd op 01-10-2003 10:55 ]

[Erkens]

het verschil is dat de onderste duidelijker is dat er gebruik gemaakt wordt van een variabele.
Waardoor de code dus leesbaarder wordt.

Tevens dacht ik dat het een paar microsecjes sneller was

Verwijderd schreef op 01 October 2003 @ 10:54:
if en else den ? en : kunt gebruiken...

? en : gebruik je meestal bij een simpele vergelijking waarbij je een waarde wilt toekennen aan een var:

PHP:

$id = (isset($_GET['id'])?$_GET['id']:1);

[ Voor 45% gewijzigd door Erkens op 01-10-2003 10:58 ]

[Verwijderd]

Erkens schreef op 01 oktober 2003 @ 10:57:
[...]

? en : gebruik je meestal bij een simpele vergelijking waarbij je een waarde wilt toekennen aan een var:

mja ok, maar het is in principe een verkapte if/else lus toch

[ Voor 18% gewijzigd door Verwijderd op 01-10-2003 10:58 ]

[jan-marten]

Concatenaten en tussen {} zetten gaat sneller dan een variabele zo in de string te plaatsen.

[crisp]

idd een verduidelijking dat het om een variabele gaat, verder heeft het nog een ander voordeel:

PHP:

$string = "je naam is $_GET['naam']"; // werkt niet
$string = "je naam is {$_GET['naam']}"; // werkt wel

echter is dit nog steeds sneller:

PHP:

$string = 'je naam is '.$_GET['naam'];

[Soultaker]

Er is geen functioneel verschil; de uitwerking is hetzelfde. Het zijn gewoon twee manieren om hetzelfde doel te bereiken; welke je mooier vindt, hangt een beetje van je eigen voorkeur af.

In het eerste geval wordt een string door PHP verwerkt door er de variabele in in te voegen; in het tweede geval plak je een aantal complete strings aan elkaar. Dat heeft wel een aantal gevolgen voor de efficiëntie, maar ik vind dat zelf nogal onintressant. Als het jou wel interesseert, kun je zoeken op PHP benchmarks (hier op GoT en op Google).

Wat wel belangrijk is, is dat je je realiseert dat er verschil bestaat tussen enkele en dubbele quotes (' en "); strings met dubbele quotes ("foo $var bar") worden bij de evaluatie door PHP verder verwerkt, waarbij variabelen en dergelijke in de string ingevoegd kunnen worden. Strings met enkele quotes ('foobar') worden alleen tijdens het parsen verwerkt en zijn in de executie dus wat efficiënter; de evaluatie ervan is goedkoper. Als je dan toch kiest voor de constructie met stringconcatenatie ('foo'.$var.'bar') gebruik dan gewoon enkele quotes, waar mogelijk.

Zelf kies ik trouwens bijna altijd voor de tweede variant (met enkele quotes, dus), maar dan vooral omdat ik me erger aan de afwijkende manier van arrays invoegen en de onmogelijkheid om expressies te evalueren in de strings. In principe ben ik wel heel erg voor het scheiden van formattering en inhoud; in Python gebruik ik dan ook regelmatig dit soort constructies:

Python:

print '<a href="%s">%s</a>' % (url, title);

Jammer genoeg zijn die in PHP niet beschikbaar.

edit:

crisp schreef op 01 October 2003 @ 11:01:

PHP:

$string = "je naam is $_GET['naam']"; // werkt niet
$string = "je naam is {$_GET['naam']}"; // werkt wel

Je kunt de array wel gebruiken maar dan moet je de quotes weer weglaten (dat vind ik zelf dus erg lelijk):

PHP:

$string = "je naam is $_GET[naam]"; // werkt weer wel!

Dit geeft ook geen warnings met error_reporting op E_ALL, terwijl $_GET[naam] dat buiten de string wel zou doen, natuurlijk.

[ Voor 23% gewijzigd door Soultaker op 01-10-2003 11:03 ]

[Erkens]

Soultaker schreef op 01 October 2003 @ 11:01:
In principe ben ik wel heel erg voor het scheiden van formattering en inhoud; in Python gebruik ik dan ook regelmatig dit soort constructies:

Python:

print '<a href="%s">%s</a>' % (url, title);

Jammer genoeg zijn die in PHP niet beschikbaar.

http://nl2.php.net/manual/nl/function.sprintf.php
http://nl2.php.net/manual/nl/function.printf.php

[ Voor 11% gewijzigd door Erkens op 01-10-2003 11:04 ]

[crisp]

Soultaker schreef op 01 October 2003 @ 11:01:
[...]

Je kunt de array wel gebruiken maar dan moet je de quotes weer weglaten (dat vind ik zelf dus erg lelijk):

PHP:

$string = "je naam is $_GET[naam]"; // werkt weer wel!

Dit geeft ook geen warnings met error_reporting op E_ALL, terwijl $_GET[naam] dat buiten de string wel zou doen, natuurlijk.

Ik kan je garanderen dat dit in ieder geval een notice oplevert met error_reporting op E_ALL

[Verwijderd]

Mijn manier van proggen:

PHP:

$naam = 'Ivy';

// Als er geen HTML in zit (dubbele aanh. tekens):
echo "Hallo, " . $naam . " is de naam.";

// Als er wel HTML in zit (enkele aanh. tekens):
echo '<input type="text" value="' . $naam . '">';

Puur voor de duidelijkheid, je variabelen worden een andere kleur en wat de aanhalingstekens betreft (enkel / dubbel): dit is gewoon handig omdat je in HTML dubbele gebruikt en doordat je dan echo't met enkele hoef je ze niet steeds te escapen..

/me vraagt zichzelf af waarom hij niet constant enkele aanh tekens gebruikt voor het echo'en ... ?

[ Voor 40% gewijzigd door Verwijderd op 01-10-2003 11:09 ]

[Verwijderd]

sodeju wat een boel reacties en leermomenten!

ik vind zelf:

PHP:

$var = "tussen"; 
$string = "de boom staat ". $var ." de struiken."; 

echo $string;

mooier, de variabele wordt er dan uitgelicht en met een editor met kleurherkenning gekleurd.
maar performance technisch zou ik dus beter dit kunnen doen?

PHP:

$var = 'tussen'; 
$string = 'de boom staat '. $var .' de struiken.' ;

echo $string;

en die ? en : ken ik eigenlijk niet... gebruik altijd een volledig uitgeschreven if else
eens zoeken op php.net of ik daar meer over kan vinden.

edit:
OMG! werkt dit ook?

PHP:

// Als er wel HTML in zit (enkele aanh. tekens): 
echo '<input type="text" value="' . $naam . '">';

ik doe altijd:

PHP:

echo "<input type=\"text\" value=\"".  $var ."\">";

maakt dit ook weer geen bal uit, of zijn hier weer performance verschillen?

[ Voor 37% gewijzigd door Verwijderd op 01-10-2003 11:14 ]

[Verwijderd]

Verwijderd schreef op 01 October 2003 @ 11:09:
sodeju wat een boel reacties en leermomenten!

OMG! werkt dit ook?

PHP:

// Als er wel HTML in zit (enkele aanh. tekens): 
echo '<input type="text" value="' . $naam . '">';

ik doe altijd:

PHP:

echo "<input type=\"text\" value=\"".  $var ."\">";

maakt dit ook weer geen bal uit, of zijn hier weer performance verschillen?

Of

PHP:

echo "<input type='text' value=' '". $var ." '>";

[Soultaker]

crisp schreef op 01 October 2003 @ 11:06:
Ik kan je garanderen dat dit in ieder geval een notice oplevert met error_reporting op E_ALL

Nee, echt niet! Ik zei juist dat ik het ontzettend lelijk vond; als het consequent was, had ik het ook irritant gevonden, maar minder lelijk. Het geeft dus geen warning, maar om jou te overtuigen heb ik het nog even online uitgeprobeerd:
Voorbeeld (source)
Haal je de dubbele quotes weg, dan geeft het uiteraard weer wel een foutmelding.

[crisp]

Verwijderd schreef op 01 October 2003 @ 11:09:
sodeju wat een boel reacties en leermomenten!

[...]

edit:
OMG! werkt dit ook?

PHP:

// Als er wel HTML in zit (enkele aanh. tekens): 
echo '<input type="text" value="' . $naam . '">';

ik doe altijd:

PHP:

echo "<input type=\"text\" value=\"".  $var ."\">";

maakt dit ook weer geen bal uit, of zijn hier weer performance verschillen?

Alles tussen dubbele quotes wordt eerst geparsed, tussen enkele quotes niet. Theoretisch is het gebruik van enkele quotes, als je weet dat er toch niets geparsed hoeft te worden, dus sneller. In praktijk merk je het nauwelijks.

Wel is 1 van de voordelen inderdaad dat je geen dubbele quotes in HTML meer hoeft te escapen. Nu kan je natuurlijk in HTML ook enkele quotes om je attributen gebruiken, maar er is een goede reden waarom dubbele quotes in HTML de voorkeur genieten - namelijk het feit dat de dubbele quote een entity heeft, nl "

Aanschouw het volgende:

PHP:

// dit gaat altijd goed
$string = 'een string met "kwootjes"';
echo '<input type="text" value="'.htmlentities($string).'" />';

// dit gaat goed fout
$string = "een string met 'kwootjes'";
echo "<input type='text' value='".htmlentities($string)."' />";

omdat een enkele quote geen entitie heeft gaat het bij gebruik van enkele quotes voor attributen dus altijd fout als je een variabele output waar ook een enkele quote in zit

[Erkens]

Verwijderd schreef op 01 October 2003 @ 11:21:
[...]

Of

PHP:

echo "<input type='text' value=' '". $var ." '>";

dan heb je enkele quotes in je HTML, en dus is dat een ander resultaat

[Verwijderd]

Verwijderd schreef op 01 oktober 2003 @ 11:09:
edit:
OMG! werkt dit ook?

PHP:

// Als er wel HTML in zit (enkele aanh. tekens): 
echo '<input type="text" value="' . $naam . '">';

ik doe altijd:

PHP:

echo "<input type=\"text\" value=\"".  $var ."\">";

maakt dit ook weer geen bal uit, of zijn hier weer performance verschillen?

Scheelt je bij een beetje website van formaat 36.312 back-slashes..

[Verwijderd]

Erkens schreef op 01 October 2003 @ 11:23:
[...]

dan heb je enkele quotes in je HTML, en dus is dat een ander resultaat

ok, maar het werkt wel

ik heb in ieder geval nog nooit een foutmelding gezien op deze manier

[Verwijderd]

dan is deze weer mooier, omdat je deze HTML code ook zo weer als standaard HTML kan gebruiken en andersom.

PHP:

echo '<input type="text" value="' . $naam . '"> \n';

formaat 36.312 back-slashes

lol, maak daar maar het dubbele van

[ Voor 32% gewijzigd door Verwijderd op 01-10-2003 11:25 ]

[Erkens]

Verwijderd schreef op 01 October 2003 @ 11:24:
[...]


ok, maar het werkt wel

ik heb in ieder geval nog nooit een foutmelding gezien op deze manier

het kan misschien wel werken, maar je mag in HTML geloof ik alleen dubbele quotes gebruiken (als ik fout zit moet iemand me maar even verbeteren) dat de browers het wel slikken is iets anders

[Soultaker]

Erkens schreef op 01 oktober 2003 @ 11:28:
het kan misschien wel werken, maar je mag in HTML geloof ik alleen dubbele quotes gebruiken (als ik fout zit moet iemand me maar even verbeteren) dat de browers het wel slikken is iets anders

Je zit fout; zowel in SGML als XML zijn zowel dubbele als enkele quotes toegestaan (maar zie Crisp's reactie voor een uitleg waarom dubbele quotes, in ieder geval voor HTML, doorgaans gewoon handiger zijn).

[ Voor 4% gewijzigd door Soultaker op 01-10-2003 11:29 ]

[crisp]

Soultaker schreef op 01 October 2003 @ 11:22:
[...]

Nee, echt niet! Ik zei juist dat ik het ontzettend lelijk vond; als het consequent was, had ik het ook irritant gevonden, maar minder lelijk. Het geeft dus geen warning, maar om jou te overtuigen heb ik het nog even online uitgeprobeerd:
Voorbeeld (source)
Haal je de dubbele quotes weg, dan geeft het uiteraard weer wel een foutmelding.

Dan is PHP dus ook niet consequent in z'n foutmeldingen; ik had op z'n minst een --use of undefined constant foo, assumed 'foo'-- melding verwacht; valt me weer tegen

[Erkens]

Soultaker schreef op 01 October 2003 @ 11:29:
[...]

Je zit fout; zowel in SGML als XML zijn zowel dubbele als enkele quotes toegestaan (maar zie Crisp's reactie voor een uitleg waarom dubbele quotes, in ieder geval voor HTML, doorgaans gewoon handiger zijn).

even overheen gelezen

crisp schreef op 01 October 2003 @ 11:22:
Nu kan je natuurlijk in HTML ook enkele quotes om je attributen gebruiken, maar er is een goede reden waarom dubbele quotes in HTML de voorkeur genieten - namelijk het feit dat de dubbele quote een entity heeft, nl [b][norml]"[/][/]

offtopic:
zo is tenminste het verhaal van crisp beter te lezen ivm html rechten

edit:
huh? waarom wordt die ook bij mij geparsed?
dan maar [norml] eromheen

[ Voor 9% gewijzigd door Erkens op 01-10-2003 11:33 ]

[Verwijderd]

crisp schreef op 01 October 2003 @ 11:30:
[...]

Dan is PHP dus ook niet consequent in z'n foutmeldingen; ik had op z'n minst een --use of undefined constant foo, assumed 'foo'-- melding verwacht; valt me weer tegen

offtopic:
Haha, PHP-pesimist..

[ Voor 15% gewijzigd door Verwijderd op 01-10-2003 11:39 ]

[crisp]

constanten worden tussen dubbele quotes dus helemaal niet geparsed:

PHP:

<?php
$array = array('foo' => '*foo*',
               'bar' => '*bar*');
define ('foo', 'bar');

echo "foo";  // foo
echo foo; // bar

echo "$array[foo]"; // *foo*
echo $array[foo]; // *bar*
?>

[Verwijderd]

PHP:

//toon het taakmenu
$taken_menu = ''.
'<tr> \n' .
    '<td colspan="2" class="bold" height="35" valign="bottom">Gekoppelde taken</td> \n' .
'</tr> \n' .
'<tr> \n' .
    '<td valign="top" colspan="2">Geen taken gekoppeld</td> \n' .
'</tr> \n';

print( $taken_menu );

levert:

code:

\n Gekoppelde taken \n 
\n \n Geen taken gekoppeld \n 
\n

waarom print hij de newline chars nu?
als ik de html tussen dubbele quotes zet worden ze niet afgedrukt?

edit:
heeft het er dan nu mee te maken dat alles tussen '' quotes niet meer wordt geparsed? Dus de \n's worden zo lina recta doorgegooid naar de html, zonder dat ze vervangen worden voor newlines?
klinkt wel aannemelijk eigenlijk...
hoe doen jullie dat bij lange html's als ik alles aan elkaar plak wordt het ook een puinhoop in de output.

edit again:
het topic is al 2 pagina's lang had nog niet doorgeklikt

[ Voor 60% gewijzigd door Verwijderd op 01-10-2003 12:13 ]

[Maxonic]

@crisp:

En wat leverd echo 'foo'; hier op?

@Iceflame:

Zoals boven al gezegt is worden strings tussen enkele quotes niet geparsed maar direct gekopieerd.
\n blijft dus gewoon \n want PHP blijft er met de handjes vanaf.
Je zou in dit geval $foo = '<html code>blabla'."\n"; moeten gebruikern maar dat is ook weer zo krom.

[ Voor 107% gewijzigd door Maxonic op 01-10-2003 12:07 ]

[Verwijderd]

Maxonic schreef op 01 October 2003 @ 12:04:
@crisp:

En wat leverd echo 'foo'; hier op?

@Iceflame:

Zoals boven al gezegt is worden strings tussen enkele quotes niet geparsed maar direct gekopieerd.
\n blijft dus gewoon \n want PHP blijft er met de handjes vanaf.
Je zou in dit geval $foo = '<html code>blabla'."\n"; moeten gebruikern maar dat is ook weer zo krom.

Je geeft daar zelf je antwoord al, aangezien wat tussen enkele quotes staat niet geparsed wordt

[drm]

crisp:
Aanschouw het volgende:

PHP:

// dit gaat altijd goed
$string = 'een string met "kwootjes"';
echo '<input type="text" value="'.htmlentities($string).'" />';

// dit gaat goed fout
$string = "een string met 'kwootjes'";
echo "<input type='text' value='".htmlentities($string)."' />";

omdat een enkele quote geen entitie heeft gaat het bij gebruik van enkele quotes voor attributen dus altijd fout als je een variabele output waar ook een enkele quote in zit

Een enkele quote heeft geen entity? Elke character heeft een entity Ze hebben alleen niet allemaal een naam

Sterker nog, je kunt htmlentities opdracht geven om ook single quotes te escapen. "Aanschouw dus maar het volgende:"

PHP:

<?
$my_string = "has' some \" quotes";

echo '<input type="text" value="', htmlentities ( $my_string, ENT_QUOTES ), '" />';
?>

Ik zelf geef de voorkeur aan een wrappertje daarvoor:

PHP:

function html ( $str ) {
   return htmlentities ( $str, ENT_QUOTES );
}

scheelt weer wat leesbaarheid en tikwerk

[Maxonic]

Even een andere vraag:
Past wel in het topic denk ik

PHP:

$foo = "";

{
    if($foo)
    // false

    if(IsSet($foo))
    // true

    if($foo == "")
    // true
}

unset($foo);

{
    if($foo)
    // false

    if(IsSet($foo))
    // false

    if($foo == "")
    // true
}

Kan ik hieruit concluderen dat een lege string niet NULL is maar NULL wel een lege string is?

[ Voor 10% gewijzigd door Maxonic op 01-10-2003 12:15 ]

[Verwijderd]

Zoals boven al gezegt is worden strings tussen enkele quotes niet geparsed maar direct gekopieerd.
\n blijft dus gewoon \n want PHP blijft er met de handjes vanaf.
Je zou in dit geval $foo = '<html code>blabla'."\n"; moeten gebruikern maar dat is ook weer zo krom.

daar was ik idd al bang voor.
Hoe doen jullie dat met grote html pagina's? Als je alles achter/aan elkaar plakt wordt de output een zooitje.
Nou heeft een browser hier niet zoveel moeite mee, maar ik heb al gemerkt dat HTML emails in bv Outlook een stuk minder vergeeflijk zijn. Daar komen er !-tekens midden in je html te staan waar de te lange regels zijn afgebroken.

[Maxonic]

[vergeef me]

Ik maak altijd gewoon een hele lap tekst incl. $vars. (Daarbij druk ik op enter voor newline )
Vervolgens haal ik het door eval() heen.

Zo werkt het template systeem dat ik gebruik ook.
Die propt een lap tekst uit de database in een variable $var.
eval ("\$var = \"$var\";");
en dan echo $var;
Tada.. alles staat nog netjes onder elkaar.
[/vergeef me]

[crisp]

drm schreef op 01 October 2003 @ 12:13:
[...]
Een enkele quote heeft geen entity? Elke character heeft een entity Ze hebben alleen niet allemaal een naam
[...]

mierenneuker een enkele quote heeft geen named entity, en wordt standaard ook niet omgezet door htmlentities (zo goed?)

Verwijderd schreef op 01 October 2003 @ 12:16:
[...]

daar was ik idd al bang voor.
Hoe doen jullie dat met grote html pagina's? Als je alles achter/aan elkaar plakt wordt de output een zooitje.
Nou heeft een browser hier niet zoveel moeite mee, maar ik heb al gemerkt dat HTML emails in bv Outlook een stuk minder vergeeflijk zijn. Daar komen er !-tekens midden in je html te staan waar de te lange regels zijn afgebroken.

PHP:

define('CR', "\n");
echo 'zinnetje 1'.CR.'zinnetje2';

Maxonic schreef op 01 October 2003 @ 12:22:
[vergeef me]

Ik maak altijd gewoon een hele lap tekst incl. $vars. (Daarbij druk ik op enter voor newline )
Vervolgens haal ik het door eval() heen.

Zo werkt het template systeem dat ik gebruik ook.
Die propt een lap tekst uit de database in een variable $var.
eval ("\$var = \"$var\";");
en dan echo $var;
Tada.. alles staat nog netjes onder elkaar.
[/vergeef me]

eval = vies

[Maxonic]

[b]crisp schreef op 01 October 2003 @ 12:32

[...]

eval = vies

Dat heb ik idd al op erg veel plaatsen gelezen en van erg veel mensen gehoord maar zou iemand het voor mij misschien even willen beargumenteren? bvd

[crisp]

Maxonic schreef op 01 October 2003 @ 12:36:
[...]


Dat heb ik idd al op erg veel plaatsen gelezen en van erg veel mensen gehoord maar zou iemand het voor mij misschien even willen beargumenteren? bvd

eval is traag, foutgevoelig en je hebt geen goede methoden om fouten netjes op te vangen. Daarbij is eval in bijna alle gevallen overbodig omdat er betere/mooiere alternatieven voorhanden zijn. In jouw geval:

PHP:

$title = 'testje';
$template = '<title>$title</title>';
eval("\$output = \"$template\";");
echo $output;

zou je ook zo kunnen doen:

PHP:

$title = 'testje';
$template = '<title>%TITLE%</title>';
$output = str_replace('%TITLE%', $title, $template);
echo $output;

[Maxonic]

Maar als ik enkele KB's aan code daar doorheen wil halen met enkele honderden verschillende variables dan heb ik alleen al een hele lap text voor al die replace operaties nodig.
Dat lijkt me nogal traag.. en overbodig

Of is er zoeits: (pseudocode)

code:

Zoek in $text naar %{iets}%
  replace voor alle {iets}
     %{iets}% met (de value van) $iets

edit:
Alle variables die je mogelijk tegenkomt in een array zetten blijft daarbij nog een hele lijst.

[ Voor 23% gewijzigd door Maxonic op 01-10-2003 13:16 ]

[Janoz]

Ja, zie manual mbt str_replace

[drm]

Maxonic:
Kan ik hieruit concluderen dat een lege string niet NULL is maar NULL wel een lege string is?

Nee, dat kun je niet concluderen. Er zijn namelijk twee verschillende "gelijk aan" operatoren in PHP. Eén checkt de waarde, de ander checkt de waarde en het type.

PHP:

<?
function println ( $str ) { 
   echo $str, "\n"; 
} 

$str = ''; 
$int_str = '0';
$int = 0; 
$null = NULL; 

echo '<pre>';
if ( $str == $int )       println ( '$str == $int' ); 
if ( $str == $null )      println ( '$str == $null' ); 
if ( $str == $int_str )   println ( '$str == $int_str' ); 
if ( $int == $int_str )   println ( '$int == $int_str' ); 

if ( $str === $int )   println ( '$str === $int' ); 
if ( $str === $null )  println ( '$str === $null' ); 
// etcetera
echo '</pre>';
?>

Work it out en je zult de verschillen wel zien.

zie ook comparison operators.

[ Voor 6% gewijzigd door drm op 01-10-2003 13:16 ]

[Macros]

Ik gebruik voor hardcoded html meestal deze constructie:

PHP:

$url = 'http://www.tweakers.net';
$name  = 'Tweakers';
$html = <<< END
   <a href='$url'> $tweakers</a>
   Je kan dan gewoon " en ' gebruiken, zonder dat ze de string eindigen en hij parsed vars zoals in " " strings, echt ideaal.
    Je kan ook gelijk zo doen:
    echo <<< END
    om het meteen uit te printen
    Nu gebruik ik het code woord END om de string te eindigen, maar je kan elk woord gebruiken dat je wilt. Hij eindigd de string ook daadwerkelijk als je het woord aan het begin van de regel zet.
    Ook handig voor als je HTML en PHP highlightin in je editor hebt :)
    Doei!
END
echo $html;

[ACM]

crisp schreef op 01 October 2003 @ 11:01:
idd een verduidelijking dat het om een variabele gaat, verder heeft het nog een ander voordeel:

PHP:

$string = "je naam is $_GET['naam']"; // werkt niet
$string = "je naam is {$_GET['naam']}"; // werkt wel

Beide zijn correcte php-code, de eerste wil echter de entry 'naam' en de tweede de entry naam.
Zelf vind ik dat min of meer een bug van de php-parser, want het is natuurlijk onzin dat binnen de [] ineens het gedrag veranderd als de context buiten de variabele anders is.

En idd, je krijgt geen warning als je de '' weglaat, want die entry van de array bestaat tenslotte gewoon (en je bent al "in een string"). Je krijgt misschien een warning als je de '' laat staan, omdat die entry niet bestaat.

echter is dit nog steeds sneller:

PHP:

$string = 'je naam is '.$_GET['naam'];

De enige reden die ik zinvol acht om te kiezen tussen de verschillende methoden is dat je het prettiger vind werken. De verschillen in performance zijn zo marginaal dat ik toch echt de onderhoudbaarheid hoger in het vaandel zou houden dan de performance.

[drm]

Macros:
Ik gebruik voor hardcoded html meestal deze constructie:

PHP:

snip

Mja, de heredoc syntax heet die. Die is geleend van Perl, maar ik vind 'm allesbehalve prettig lezen. Dat heb je met dingen die van Perl geleend zijn

Kan ook te maken hebben met het feit dat de editor die ik gebruik de highlighting voor heredoc niet goed doet.

[ Voor 31% gewijzigd door drm op 01-10-2003 13:23 . Reden: quote erbij 8)7 ]

[Janoz]

Persoonlijk ben ik helemaal niet bezig met het genereren van html op deze manier. Mijn laatste grote project wat ik in php gemaakt heb had de volgende struktuur:

PHP:

<?
//berg includes met de werkelijke functionaliteit
?>
<html>
 <head>
 </head>
 <body>
  Blaat heel html gedoen ed met af en toe een <?=$variabel ?> onderdeel.
<?
foreach ($array as $label => $value) {
?>
Herhaald stukje waarin <?=$label ?> en of <?=$value ?> worden gebruikt.
<?
}
?>
 </body>
</html>

Voordeel is ten eerste natuurlijk de duidelijke scheiding tussen functionaliteit en weergave hebt. Je kunt een phpnoob gewoon een site laten maken en vervolgens het dynamische deel hier zo inplakken. Je kunt dit zelfs nog wel uitleggen aan een vormgever. Daarnaast is deze pagina gewoon te edditen in een wysiwyg editor.

[drm]

Janoz:
Persoonlijk ben ik helemaal niet bezig met het genereren van html op deze manier. [snip]

Exact de manier zoals ik het doe. Eventueel nog wat nested includes mocht dat nodig zijn.

edit:
ACM

[ Voor 61% gewijzigd door drm op 01-10-2003 15:36 ]

[Maxonic]

drm schreef op 01 October 2003 @ 13:15:
[...]
Nee, dat kun je niet concluderen.
[...]
Work it out en je zult de verschillen wel zien.

zie ook comparison operators.

Ok duidelijk, ze zijn dus niet identiek maar wel gelijkwaardig. Maar is dit toch niet iets waar je vaak bewust stil bij moet staan.
Ik bedoel, PHP cast toch alles automatisch heen en weer.