Probleme mit Variablenvariablen
Marc Wiemers
ich bin recht verzweifelt. Ich habe unter Debian linux lenny php5
installiert. Ich möchte gerne Variablen aus Variablen generieren.
Also:
$n = 1;
$arte = "Test";
$var = ${$arte . $n};
$$var = "Hallo";
echo "$var ist: ${$arte . $n}";
Leider gibt das Echo nur den Variablennamen aus.
Ich habe schon einiges Probiert.
Nach dem Beispiel vom php.net sollte es funktionieren:
<?
$arg = "foo";
$val = "bar";
//${$arg$val} = "in valid"; // Invalid
${$arg . $val} = "working";
echo $foobar; // "working";
//echo $arg$val; // Invalid
//echo ${$arg$val}; // Invalid
echo ${$arg . $val}; // "working"
?>
Kann es sein, dass irgendetwas im php.ini eingestellt werden muß. Ich weiß
nicht weiter.
Vielen Dank für Hilfe.
Marc
Gregor Kofler
> Hallo,
>
> ich bin recht verzweifelt. Ich habe unter Debian linux lenny php5
> installiert. Ich möchte gerne Variablen aus Variablen generieren.
Warum? Habe jetzt schon etliche Jahre mit PHP verbracht, ohne jemals
variable Variablen benötigt zu haben.
> Kann es sein, dass irgendetwas im php.ini eingestellt werden muß. Ich weiß
> nicht weiter.
Nope.
Ach ja:
Wahrscheinlich willst du (aus deinen Ausführungen werd ich nicht so
recht schlau; und short-tags sind böse):
<?php
$n = 1;
$arte = "Test";
$var = $arte.$n;
$$var = "Hallo";
echo "$var ist: ${$arte . $n}";
?>
Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Niels Braczek
> Ich möchte gerne Variablen aus Variablen generieren.
Nein, das möchtest du nicht. Du möchtest dein Konzept reparieren.
Variable Variablen sind böse[tm].
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Marc Wiemers
Gregor Kofler wrote:
> Ach ja:
>
> Wahrscheinlich willst du (aus deinen Ausführungen werd ich nicht so
> recht schlau; und short-tags sind böse):
>
> <?php
>
> $n = 1;
> $arte = "Test";
> $var = $arte.$n;
> $$var = "Hallo";
>
> echo "$var ist: ${$arte . $n}";
>
> ?>
Genau das will ich aber es geht nicht. echo gibt dann kein Hallo aus.
Was gibt es für Alternativen wenn das böse ist?
Marc
Christoph Herrmann
> Was gibt es für Alternativen wenn das böse ist?
kommt darauf an was du damit erreichen willst.
--
Mit freundlichen Grüßen,
Christoph Herrmann
Stefan Braumeister
> Hallo Gregor,
>
> Gregor Kofler wrote:
>
>> Ach ja:
>>
>> Wahrscheinlich willst du (aus deinen Ausführungen werd ich nicht so
>> recht schlau; und short-tags sind böse):
>>
>> <?php
>>
>> $n = 1;
>> $arte = "Test";
>> $var = $arte.$n;
>> $$var = "Hallo";
>>
>> echo "$var ist: ${$arte . $n}";
>>
>> ?>
>
> Genau das will ich aber es geht nicht. echo gibt dann kein Hallo aus.
Dann kontrolliere noch mal ob du wirklich 1:1 obigen Code verwendet
hast. Wie rufsat du den Code auf: php -f testfile?
Ansonsten kannst du auch noch mit gdb debuggen, wenn es wirklich nicht
geht kannst du ja nochmal deine PHP Pakete de/installieren
>
> Was gibt es für Alternativen wenn das böse ist?
Was willst du damit erreichen.
>
> Marc
Ralph 'rkhb' Bauer
>> Wahrscheinlich willst du (aus deinen Ausführungen werd ich nicht so
>> recht schlau; und short-tags sind böse):
>>
>> <?php
>>
>> $n = 1;
>> $arte = "Test";
>> $var = $arte.$n;
>> $$var = "Hallo";
>>
>> echo "$var ist: ${$arte . $n}";
>>
>>>
>
Gregors Vorschlag weicht geringfügig von Deiner Vorgabe ab. Bei Dir steht:
$var = ${$arte . $n};
Das heißt im Klartext: $var = $Test1 und gibt eine Notice "Undedefined
variable", weil $Test1 zu diesem Zeitpunkt noch nicht definiert ist.
Bei Gregor steht:
$var = $arte.$n;
Ohne geschweifte Klammern. Das heißt im Klartext: $var = "Test1" und führt
zu Deinem gewünschtem Ergebnis.
> Was gibt es für Alternativen wenn das böse ist?
Gregor meint nur Short-Tags, also "<?". Diese müssen extra in der php.ini
freigeschaltet werden. Nimm besser immer normale Tags: "<?php". Dann klappts
auch mit dem Nachbarcomputer.
viele grüße
ralph
Andreas Thiele
"Marc Wiemers" <jupit...@gmx.de> schrieb im Newsbeitrag news:flresc$82v$1...@saphir.steine.home...
Hi Marc,
Du machst einen kleinen Fehler. $Test1 ist nicht initialisiert.
mit
> $var = ${$arte . $n};
Setzt Du $var auf den Wert aus $Test1. Wenn Du $Test1 vorher setzt,
kannst Du sehen, was passiert:
$Test1="Welt";
$n=1;
$arte="Test";
$var=${$arte.$n};
$$var="Hallo";
echo $var."*".$Test1."*".$Welt."*".$$var;
erzeugt bei mir: Welt*Welt*Hallo*Hallo
Verstanden? Ich glaube, was Du eigentlich wolltest ist:
$n=1;
$arte="Test";
$var=$arte.$n;
$$var="Hallo";
echo $var."*".$$var;
Das erzeugt den Output: Test1*Hallo
Du warst also einmal zu indirect. Wahrscheinlich hast Du geglaubt,
mit $var = ${$arte.$n} konntest Du in $var eine Referenz auf $Test1
erzeugen. Das ist aber nicht so. ${$arte.$n} wird *nur* interpretiert und
ergibt. wie gesagt, den Inhalt von $Test1 (also "").
Gruß Andreas
Andreas Thiele
>"Niels Braczek" <nbra...@freenet.de> schrieb im Newsbeitrag news:flrn52$s9d$02$1...@news.t-online.com...
>Marc Wiemers schrieb:
>
>> Ich möchte gerne Variablen aus Variablen generieren.
>
>Nein, das möchtest du nicht. Du möchtest dein Konzept reparieren.
>Variable Variablen sind böse[tm].
Das halte ich für zu sehr vereinfacht.
Die PHP-Sprachentwickler erlauben den Anwendungsentwicklern einen gewissen
Zugriff auf Funktionalitäten des Interpreters. Was man damit anstellen kann,
kann man z.B. in "Structure and Interpretation of Computer Programs" von
Abelson & Sussman nachlesen.
Ich möchte sagen, dass ist schon eine scharfe Waffe - mit der kann man sich
allerdings auch leicht ins Bein schießen :))
Gruß Andreas
Jonas Werres
> Variable Variablen sind böse[tm].
Naja, in Template-Engines könnte ich mir das vorstellen.
Marc Wiemers
ja was will ich damit.
Die Variable kommt aus einer Abfrage mehrerer Checkboxen.
<INPUT TYPE=hidden Name=Autor1 VALUE=0>
<INPUT TYPE=hidden Name=Autor1 VALUE=123>
<INPUT TYPE=hidden Name=Autor1 VALUE=243>
<INPUT TYPE=hidden Name=Autor2 VALUE=0>
<INPUT TYPE=hidden Name=Autor2 VALUE=234>
<INPUT TYPE=hidden Name=Autor2 VALUE=456>
diese möcht ich gerne auswerten. Wobei ich nicht weiß wieviele Autor es
gibt. Ich habe schon versucht mit isset (${$autor.$n} abzufragen was aber
auch schon nicht ging. Dann haben ich eine Variable anzahlAutoren eingefügt
leider gibt aber ${$test.$n} dann auch nicht das gewünschte aus.
Vielleicht gibt es einen besseren Weg das Auszuwerten?
Vielen Dank für eine Antwort!
Marc
Christoph Herrmann
> ja was will ich damit.
> Die Variable kommt aus einer Abfrage mehrerer Checkboxen.
> <INPUT TYPE=hidden Name=Autor1 VALUE=0>
> <INPUT TYPE=hidden Name=Autor1 VALUE=123>
> <INPUT TYPE=hidden Name=Autor1 VALUE=243>
>
> <INPUT TYPE=hidden Name=Autor2 VALUE=0>
> <INPUT TYPE=hidden Name=Autor2 VALUE=234>
> <INPUT TYPE=hidden Name=Autor2 VALUE=456>
>
> diese möcht ich gerne auswerten. Wobei ich nicht weiß wieviele Autor es
> gibt. Ich habe schon versucht mit isset (${$autor.$n} abzufragen was aber
> auch schon nicht ging. Dann haben ich eine Variable anzahlAutoren eingefügt
> leider gibt aber ${$test.$n} dann auch nicht das gewünschte aus.
Das funktioniert aber nur, wenn register_globals angeschaltet ist oder
simuliert wird. In Verbindung mit solchen Konstrukten können schnell mal
unitialisierte Variablen (wie schon im anderen Beitrag erwähnt) heraus
kommen was beides zusammen ein Sicherheitsrisiko verursacht.
> Vielleicht gibt es einen besseren Weg das Auszuwerten?
> Vielen Dank für eine Antwort!
$counter = 1;
while(isset($_POST['Autor' . $counter]))
{
print $_POST['Autor' . $counter];
++$counter;
}
In der Variante wird nicht auf Variablen, sondern auf die Indizes des
POST Array zugegriffen, wo deine Daten nach dem Bestätigen des Formulars
liegen (solange method="post" im Formtag angegeben wurde). Bevor man
diese speichert in Datenbank oder Datei natürlich noch validieren und
gegebenenfalls maskieren.
Jonas Werres
> <INPUT TYPE=hidden Name=Autor1 VALUE=123>
> <INPUT TYPE=hidden Name=Autor1 VALUE=243>
>
> <INPUT TYPE=hidden Name=Autor2 VALUE=0>
> <INPUT TYPE=hidden Name=Autor2 VALUE=234>
> <INPUT TYPE=hidden Name=Autor2 VALUE=456>
Großschreibung schon nciht schön (und ich glaube, bei XHTML ist die auch
nciht emhr erlaubt?), aber gemischt? (Name)
2. Sind das Hidden-Felder. Keine Checkboxen. Gleiche namen amchen da
keine Sinn, weil ein Wert den anderen überschreibt.
3. Kann man in Formularen Arrays benutzen:
> <input type="checkbox" id="author1" name="autor[]" value="0"> <label
for="autor1">Autor 1</label>
> <input type="checkbox" id="author1" name="autor[]" value="0"> <label
for="autor1">Autor 1</label>
> <input type="checkbox" id="author1" name="autor[]" value="0"> <label
for="autor1">Autor 1</label>
> <input type="checkbox" id="author1" name="autor[]" value="0"> <label
for="autor1">Autor 1</label>
...
Michael Fesser
>ja was will ich damit.
>Die Variable kommt aus einer Abfrage mehrerer Checkboxen.
><INPUT TYPE=hidden Name=Autor1 VALUE=0>
><INPUT TYPE=hidden Name=Autor1 VALUE=123>
><INPUT TYPE=hidden Name=Autor1 VALUE=243>
>
><INPUT TYPE=hidden Name=Autor2 VALUE=0>
><INPUT TYPE=hidden Name=Autor2 VALUE=234>
><INPUT TYPE=hidden Name=Autor2 VALUE=456>
Das sind zwar keine Checkboxen, aber egal. Aber auch dieser Code oben
kann nicht funktionieren - Du wirst immer nur das letzte Element jeden
Namens bekommen, also 243 für 'Autor1' und 456 für 'Autor2'. Willst Du
alle haben, noch dazu in beliebiger Anzahl, dann benutze Array-Syntax:
<input type="checkbox" name="autor1[]" value="0">
<input type="checkbox" name="autor1[]" value="123">
<input type="checkbox" name="autor1[]" value="243">
<input type="checkbox" name="autor2[]" value="0">
<input type="checkbox" name="autor2[]" value="234">
<input type="checkbox" name="autor2[]" value="456">
Siehe dazu auch
11.10. Wie kann man Checkboxen verarbeiten?
http://php-faq.de/q/q-formular-checkbox.html
How do I get all the results from a select multiple HTML tag?
http://www.php.net/manual/en/faq.html.php#faq.html.select-multiple
Wird das Formular nun abgeschickt (angenommen per POST), dann sind -
sofern etwas ausgewählt wurde - $_POST['autor1'] und $_POST['autor2']
Arrays und enthalten die Werte der jeweils ausgewählten Checkboxen.
HTH
Micha
Michael Fesser
>> <INPUT TYPE=hidden Name=Autor1 VALUE=0>
>> <INPUT TYPE=hidden Name=Autor1 VALUE=123>
>> <INPUT TYPE=hidden Name=Autor1 VALUE=243>
>>
>> <INPUT TYPE=hidden Name=Autor2 VALUE=0>
>> <INPUT TYPE=hidden Name=Autor2 VALUE=234>
>> <INPUT TYPE=hidden Name=Autor2 VALUE=456>
>
>1. Gehören Attribute in HTML in Anführungszeichen.
Jein. Wenn der Wert nur aus Zahlen, Buchstaben und einer Handvoll
weiterer Zeichen besteht, dann geht's auch ohne. Aber besserer Stil
ist es natürlich, grundsätzlich alle Attributwerte in (einfache oder
doppelte) Anführungszeichen zu setzen. In X(HT)ML ist das ohnehin
vorgeschrieben.
>Ich finde
>Großschreibung schon nciht schön (und ich glaube, bei XHTML ist die auch
>nciht emhr erlaubt?)
Korrekt. X(HT)ML ist case-sensitive, HTML nicht.
Micha
Niels Braczek
>> Nein, das möchtest du nicht. Du möchtest dein Konzept reparieren.
>> Variable Variablen sind böse[tm].
>
> Naja, in Template-Engines könnte ich mir das vorstellen.
Da nimmt man Hashes. Statt $$var einfach $data[$var]. Man braucht in
üblichen Anwendungen keine variablen Variablen.
Niels Braczek
>>"Niels Braczek" <nbra...@freenet.de> schrieb im Newsbeitrag news:flrn52$s9d$02$1...@news.t-online.com...
>>Marc Wiemers schrieb:
>>
>>> Ich möchte gerne Variablen aus Variablen generieren.
>>
>>Nein, das möchtest du nicht. Du möchtest dein Konzept reparieren.
>>Variable Variablen sind böse[tm].
>>...
>
> Das halte ich für zu sehr vereinfacht.
Ich kenne keine Problemstellung (außerhalb von Debugging zumindest), die
sich nicht mit Hashes lösen ließe.
> Ich möchte sagen, dass ist schon eine scharfe Waffe - mit der kann man sich
> allerdings auch leicht ins Bein schießen :))
So ein Werkzeug gehört definitiv nicht in Hände von Leuten, die danach
fragen müssen, wie es funktioniert.
Gregor Kofler
>> Nein, das möchtest du nicht. Du möchtest dein Konzept reparieren.
>> Variable Variablen sind böse[tm].
>
> Naja, in Template-Engines könnte ich mir das vorstellen.
Hab ich auch nur assoziative Arrays.
Claus Reibenstein
> ..oO(Jonas Werres)
>
>>> <INPUT TYPE=hidden Name=Autor1 VALUE=0>
>>> <INPUT TYPE=hidden Name=Autor1 VALUE=123>
>>> <INPUT TYPE=hidden Name=Autor1 VALUE=243>
Hier weist Du _einem_ Namen mehrere Werte zu. Das wird nicht
funkionieren. Du musst schon unterschiedliche Namen verwenden oder
Arrays benutzen.
>> 1. Gehören Attribute in HTML in Anführungszeichen.
>
> Jein. Wenn der Wert nur aus Zahlen, Buchstaben und einer Handvoll
> weiterer Zeichen besteht, dann geht's auch ohne.
Falsch. Sie gehören _immer_ in Anführungszeichen. Dass es bei den
meisten Browsern auch ohne funktioniert, ändert daran nichts.
Gruß. Claus
Claus Reibenstein
> Variable Variablen sind böse[tm].
-v
Gruß. Claus
Niels Braczek
> Niels Braczek schrieb:
>
>> Variable Variablen sind böse[tm].
>
> -v
Das gehört in die gleiche Schublade wie register_globals=on oder eval().
Wenn man *genau* weiß, was man tut, ist es ok - ansonsten Finger weg.
Debugging wird erheblich erschwert. Man weiß nicht mehr, welche
Variablen im aktuellen Scope existieren. Man kann mit variablen
Variablen nichts machen, was man nicht auch mit assoziativen Arrays
erreichen kann.
Michael Fesser
>Michael Fesser schrieb:
>
>> Jein. Wenn der Wert nur aus Zahlen, Buchstaben und einer Handvoll
>> weiterer Zeichen besteht, dann geht's auch ohne.
>
>Falsch. Sie gehören _immer_ in Anführungszeichen. Dass es bei den
>meisten Browsern auch ohne funktioniert, ändert daran nichts.
| In certain cases, authors may specify the value of an attribute
| without any quotation marks. The attribute value may only contain
| letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45),
| periods (ASCII decimal 46), underscores (ASCII decimal 95), and colons
| (ASCII decimal 58). We recommend using quotation marks even when it is
| possible to eliminate them.
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.2
Micha
Jonas Werres
halte ich bei Templates für nciht zu unterschätzen. Mich nervt schon das
ewige <?php echo $blah ?> bei Symfony im Gegensatz zu {$blah} bei Smarty
(ja, ich weiß, man kann das einbinden). Wenn dazu noch data[""] kommt,
wird es bei vielen Variablen ätzend.
In Templates, wo keine andere Logik drinsteckt, sehe ich auch kein
Problem mit Debugging.
Stefan David
> Michael Fesser schrieb:
>> ..oO(Jonas Werres)
>> Jein. Wenn der Wert nur aus Zahlen, Buchstaben und einer Handvoll
>> weiterer Zeichen besteht, dann geht's auch ohne.
> Falsch. Sie gehören _immer_ in Anführungszeichen. Dass es bei den
> meisten Browsern auch ohne funktioniert, ändert daran nichts.
Nicht ganz richtig. Ich würde es zwar nie anders machen, aber in der
HTML-Spezifikation[1] steht was anderes:
| In certain cases, authors may specify the value of an attribute
| without any quotation marks. The attribute value may only contain
| letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45),
| periods (ASCII decimal 46), underscores (ASCII decimal 95), and
| colons (ASCII decimal 58).
Wie gesagt: Bitte trotzdem nicht machen.
[1] "http://www.w3.org/TR/html401/intro/sgmltut.html#idx-attribute-6"
Grüße
Der Stefan
--
"Ich habe nichts gegen Autoritäten, aber ich kann es nicht leiden, wenn
mir jemand sagt, was ich zu tun oder zu lassen habe." (Bernd Stromberg)
http://weblog.ononlinework.de/
Ulf Kadner
>> Hab ich auch nur assoziative Arrays.
> Ja, ohne ist amn nciht aufgeschmissen. Aber es sieht schöner aus und das
> halte ich bei Templates für nciht zu unterschätzen. Mich nervt schon das
> ewige <?php echo $blah ?> bei Symfony im Gegensatz zu {$blah} bei Smarty
ja was denkst Du denn wie die Daten in Smarty gehalten werden? per magic
__get und __set etwa? Alles steht dort wie zu erwarten in einem
assoziativen array.
MfG, Ulf
Ulf Kadner
> Das gehört in die gleiche Schublade wie register_globals=on oder eval().
> Wenn man *genau* weiß, was man tut, ist es ok - ansonsten Finger weg.
>
> Debugging wird erheblich erschwert. Man weiß nicht mehr, welche
> Variablen im aktuellen Scope existieren. Man kann mit variablen
> Variablen nichts machen, was man nicht auch mit assoziativen Arrays
> erreichen kann.
Das hat sich wahrscheinlich jemand ausgedacht der Arrays nicht
verstanden hat. ;-)
MfG, Ulf
Niels Braczek
In Templates steht überhaupt kein PHP. Statt <?php echo $blah; ?> oder
{$blah} steht da zB. {blah}. Die Ersetzung wird von der Template-Engine
vorgenommen, nicht vom Template. YMMV.
Niels Braczek
Wahrscheinlich derselbe, der register_globals=on als Standard gesetzt
hat und uns den safe_mode beschert hat... ;-)
Marc Wiemers
Christoph Herrmann wrote:
>
> $counter = 1;
> while(isset($_POST['Autor' . $counter]))
> {
> print $_POST['Autor' . $counter];
> ++$counter;
> }
>
> In der Variante wird nicht auf Variablen, sondern auf die Indizes des
> POST Array zugegriffen, wo deine Daten nach dem Bestätigen des Formulars
> liegen (solange method="post" im Formtag angegeben wurde). Bevor man
> diese speichert in Datenbank oder Datei natürlich noch validieren und
> gegebenenfalls maskieren.
>
Vielen Dank für die Erklärung. So geht es.
Marc
Jonas Werres
> {$blah} steht da zB. {blah}. Die Ersetzung wird von der Template-Engine
> vorgenommen, nicht vom Template. YMMV.
Ich wüsste nicht, dass das in der Definition von Template-Engine steht.
Symfony z.B. kompiliert die Templates nicht, sondern macht einfach
PHP-Code. Dem Template zugewiesen wird per __get im Control-Objekt
($this->name) und ist dann im Template z.B. als $name verfügbar.
Claus Reibenstein
> Niels Braczek schrieb:
>
>> [variable Variablen]
>
> Das hat sich wahrscheinlich jemand ausgedacht der Arrays nicht
> verstanden hat. ;-)
Ich tippe eher auf ein Relikt (aka Altlast) aus jener Zeit, zu der PHP
noch keine assoziativen Arrays kannte. Oder gab's die schon immer?
Gruß. Claus
Jonas Werres
> ja was denkst Du denn wie die Daten in Smarty gehalten werden? per magic
> __get und __set etwa?
an, weil man dem Controlobjekt einfach die Variablen, die im Template
verfügbar sein sollen, als Attribute zuweist.
> Alles steht dort wie zu erwarten in einem
> assoziativen array.
Ja. Dazu muss man aber kompilieren. Es gibt Templateangines, die nicht
kompilieren. Savant, Symfony-Template, ... und da ist
<?php echo $date["name"] ?> auf die Datuer deutlich unangenehmer als
<?php echo $name ?>
Nicht lebensnotwendig, aber schöner. Und ich sehe keine Probleme,
solange die Templateengine jemand schreibt, der weiß, was er macht.
Niels Braczek
>
> Ich wüsste nicht, dass das in der Definition von Template-Engine steht.
Template-Engine != Template.
> Symfony z.B. kompiliert die Templates nicht, sondern macht einfach
> PHP-Code. Dem Template zugewiesen wird per __get im Control-Objekt
> ($this->name) und ist dann im Template z.B. als $name verfügbar.
Dann ist das ein Skript und kein Template. Wie ich schon sagte: YMMV.
Andreas Thiele
> Andreas Thiele schrieb:
>>> "Niels Braczek" <nbra...@freenet.de> schrieb im Newsbeitrag news:flrn52$s9d$02$1...@news.t-online.com...
>>> Marc Wiemers schrieb:
>>>
>>>> Ich möchte gerne Variablen aus Variablen generieren.
>>>
>>> Nein, das möchtest du nicht. Du möchtest dein Konzept reparieren.
>>> Variable Variablen sind böse[tm].
>>> ...
>>
>> Das halte ich für zu sehr vereinfacht.
>
> Ich kenne keine Problemstellung (außerhalb von Debugging zumindest), die
> sich nicht mit Hashes lösen ließe.
Ich finde, das ist nicht die Frage. Es gibt auch kein Problem, welches nicht
mit einem Assembler-Programm gelöst werden kann. Ist nur die Frage wie einfach
oder durchsichtig. Das Prinzip der 'variablen Variablen' stand doch vor deren
Einführung schon per eval() zur Verfügung. Konsequenter weise müsstest Du dann
die Enfernung von $$ und eval() aus php fordern.
>
>> Ich möchte sagen, dass ist schon eine scharfe Waffe - mit der kann man sich
>> allerdings auch leicht ins Bein schießen :))
>
> So ein Werkzeug gehört definitiv nicht in Hände von Leuten, die danach
> fragen müssen, wie es funktioniert.
>...
Eine sehr strenge Sicht. Dein Post gibt anderen Leuten Regeln vor.
Richtig finde ich allerdings, dass man solche Konstrukte nicht unnötig einsetzt,
dass heißt, man sollte seine Sprache schon kennen.
Andreas
Thomas Hamacher
>> Alles steht dort wie zu erwarten in einem assoziativen array.
> Ja. Dazu muss man aber kompilieren. Es gibt Templateangines, die nicht
> kompilieren. Savant, Symfony-Template, ... und da ist
> <?php echo $date["name"] ?> auf die Datuer deutlich unangenehmer als
> <?php echo $name ?>
Aber dazu brauchts keine variablen Variablen. Hier reicht extract() und
include() in einer Funktion:
function render($file, $vars) {
extract($vars);
include($file);
}
--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)
Niels Braczek
> Niels Braczek wrote:
>> Ich kenne keine Problemstellung (außerhalb von Debugging zumindest), die
>> sich nicht mit Hashes lösen ließe.
>
> Ich finde, das ist nicht die Frage. Es gibt auch kein Problem, welches nicht
> mit einem Assembler-Programm gelöst werden kann. Ist nur die Frage wie einfach
> oder durchsichtig.
Genau. eval() und variable Variablen tragen aber eher zur Obfuskierung
bei statt zur Transparenz.
> Das Prinzip der 'variablen Variablen' stand doch vor deren
> Einführung schon per eval() zur Verfügung. Konsequenter weise müsstest Du dann
> die Enfernung von $$ und eval() aus php fordern.
Nein, warum? In Händen von jemandem, der damit umzugehen weiß, mögen
diese Möglichkeiten ja sinnvoll sein - wenn ich persönlich das auch
nicht so sehe.
>> So ein Werkzeug gehört definitiv nicht in Hände von Leuten, die danach
>> fragen müssen, wie es funktioniert.
>
> Eine sehr strenge Sicht. Dein Post gibt anderen Leuten Regeln vor.
Mag sein. Ich gebe meine Erfahrung weiter. Meine Regeln[tm] sind
natürlich nicht bindend. Es erspart einem (und gerade Neulingen) jedoch
viele Probleme, sie zu befolgen. Ich tue es und erwarte es von allen,
die an Projekten unter meiner Aufsicht arbeiten. Was andere tun ist
deren Sache, solange sie nicht nach Lösung ihrer Probleme fragen müssen.
(Die Formulierung hört sich wahrscheinlich härter an als sie gemeint ist).
> Richtig finde ich allerdings, dass man solche Konstrukte nicht unnötig einsetzt,
> dass heißt, man sollte seine Sprache schon kennen.
Das ist der Punkt. Wer mit eval() und variablen Variablen umzugehen
weiß, soll sie meinetwegen benutzen. Allerdings wird jemand, der damit
umgehen kann, diese Konstrukte idR nicht brauchen.
Jonas Werres
Zeig mir eine Definition, die besagt, dass ein Template kein Template
mehr ist, wenn die Werte mittels <?php echo $wert ?> eingebunden wird.
Symfony macht es so und nennt das Template.
Oder verstehe ich Dich falsch?
Niels Braczek
>> Dann ist das ein Skript und kein Template. Wie ich schon sagte: YMMV.
>
> Zeig mir eine Definition, die besagt, dass ein Template kein Template
> mehr ist, wenn die Werte mittels <?php echo $wert ?> eingebunden wird.
Die Definition habe ich genannt. Mir ist klar, dass nicht alle einhellig
meiner Meinung sind, daher sagte ich YMMV.
> Symfony macht es so und nennt das Template.
> Oder verstehe ich Dich falsch?
Das verstehst du schon richtig. <?php echo $wert ?> ist in Templates IMO
schon grenzwertig, weil *prinzipiell* Logik im "Template" untergebracht
werden *kann*. Das entzieht der Anwendung die Kontrolle und ist deswegen
im Prinzip schlechtes Design. Oft wird es aus pragmatischen Gründen
trotzdem gemacht, was daran aber nichts ändert.
Ein weiterer Vorteil echter (=passiver) Templates ist die Unabhängigkeit
von irgendeiner Skriptsprache. Ob ein Template mittels PHP, Basic oder
COBOL befüllt wird, geht das Template (und den Web-Designer !=
Programmierer) nichts an.
Jonas Werres
> schon grenzwertig, weil *prinzipiell* Logik im "Template" untergebracht
> werden *kann*. Das entzieht der Anwendung die Kontrolle und ist deswegen
> im Prinzip schlechtes Design.
Sprache gemacht wie der Controlteil und könnte damit theoretisch Logik
enthalten.
Wenn man "könnte theoretisch" aufnimmt, dann gibt es ganz andere
Probleme. Vor allem, weil man ja auch in Smarty PHP reinpressen kann,
wenn man will.
> Ein weiterer Vorteil echter (=passiver) Templates ist die Unabhängigkeit
> von irgendeiner Skriptsprache. Ob ein Template mittels PHP, Basic oder
> COBOL befüllt wird, geht das Template (und den Web-Designer !=
> Programmierer) nichts an.
Natürlich nur, wenn es eine Engine gibt, die diese Templates auch
interpretiert. Wenn man die extra schreiben muss, könnte man (was
zugegebenermaßen ziemlich blöd wäre) auch eine schreiben, die <?php echo
$wert ?> verarbeitet.
Niels Braczek
>> Das verstehst du schon richtig. <?php echo $wert ?> ist in Templates IMO
>> schon grenzwertig, weil *prinzipiell* Logik im "Template" untergebracht
>> werden *kann*. Das entzieht der Anwendung die Kontrolle und ist deswegen
>> im Prinzip schlechtes Design.
> Warum? Die Datenschicht wird ja auch zumindest teilweise in der gleichen
> Sprache gemacht wie der Controlteil und könnte damit theoretisch Logik
> enthalten.
Die Datenschicht hat die Aufgabe, das Speichermedium zu abstrahieren.
Der Controller weiß bei korrekter Implementierung nicht, ob die Daten in
einer Datei oder in einer Datenbank stehen, oder ob die Daten live per
Tastatur oder Satellit ankommen.
> Wenn man "könnte theoretisch" aufnimmt, dann gibt es ganz andere
> Probleme. Vor allem, weil man ja auch in Smarty PHP reinpressen kann,
> wenn man will.
Smarty ist IMHO auch keine empfehlenswerte Template-Engine, eben weil
die Templates Logik enthalten (können).
>> Ein weiterer Vorteil echter (=passiver) Templates ist die Unabhängigkeit
>> von irgendeiner Skriptsprache. Ob ein Template mittels PHP, Basic oder
>> COBOL befüllt wird, geht das Template (und den Web-Designer !=
>> Programmierer) nichts an.
> Natürlich nur, wenn es eine Engine gibt, die diese Templates auch
> interpretiert. Wenn man die extra schreiben muss, könnte man (was
> zugegebenermaßen ziemlich blöd wäre) auch eine schreiben, die <?php echo
> $wert ?> verarbeitet.
Klar könnte man das. Das verletzt allerdings den semantischen Grundsatz.
<?php startet den PHP-Interpreter und sonst nichts.
'<?php echo $' als Starttag und '; ?>' als Endtag für Platzhalter sind
semantischer Unsinn.
Ulf Kadner
Keine Ahnung. seit ich mit PHP werkel (4.0.* also rund 8 Jahre) kenne
ich auch assoc. Arrays. Ob da bei PHP3 was anders war? Keine Ahnung...
MfG, Ulf