Klickbare Links anzeigen
Peter Carl
ich habe (als völliger Laie) eine kleine Website zum Laufen gebracht,
auf der u.A. eine php-Seite Daten aus einer SQL-Datenbank ausliest. Aus
der Datenbank möchte ich auch Linkadressen zur Verfügung stellen, die
anklickbar sind. Geht das?
Für eine Antwort besten Dank im Voraus,
Peter Carl
Jörg Ellermann
> Hallo,
>
> ich habe (als völliger Laie) eine kleine Website zum Laufen gebracht,
> auf der u.A. eine php-Seite Daten aus einer SQL-Datenbank ausliest. Aus
> der Datenbank möchte ich auch Linkadressen zur Verfügung stellen, die
> anklickbar sind. Geht das?
<a href="<? echo $adresse ?>"><? echo $adresse ?></a>
Oder verstehe ich die Frage falsch?
Christoph Herrmann
> <a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
>
> Deinen schlechten Stil solltest einem Anfänger nicht als Lösung bieten.
> ;) Man sollte das ganze im übrigen gegen XSS absichern (gerade bei
> anfänglichen Versuchen bleibt die Sicherheit ja meist auf der Strecke)...
<a href="<?php echo $adresse; ?>"><?php echo $adresse; ?></a>
ähh, Semikolons vergessen...
--
Mit freundlichen Grüßen,
Christoph Herrmann
Christoph Herrmann
> <a href="<? echo $adresse ?>"><? echo $adresse ?></a>
>
> Oder verstehe ich die Frage falsch?
<a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
Deinen schlechten Stil solltest einem Anfänger nicht als Lösung bieten.
;) Man sollte das ganze im übrigen gegen XSS absichern (gerade bei
anfänglichen Versuchen bleibt die Sicherheit ja meist auf der Strecke)...
--
Thomas Hamacher
> Jörg Ellermann schrieb:
>> <a href="<? echo $adresse ?>"><? echo $adresse ?></a>
>> Oder verstehe ich die Frage falsch?
>
> <a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
>
> Deinen schlechten Stil solltest einem Anfänger nicht als Lösung bieten.
> ;) Man sollte das ganze im übrigen gegen XSS absichern (gerade bei
> anfänglichen Versuchen bleibt die Sicherheit ja meist auf der Strecke)...
Warum sollte man? Was willst du hier mit XSS erreichen?
--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)
Peter Carl
> <a href="<? echo $adresse ?>"><? echo $adresse ?></a>
Kann sein, dass ich mich nicht klar ausgedrückt habe. Also: in der
Datenbank steht in einem Textfeld ein Link, z.B. www.spiegel.de. Den
Text kann ich problemlos auslesen, aber der steht halt dann als Text da
und kann nicht angeklickt werden. Die Codezeile auf der php-Seite sieht
so aus:
<?php echo $row_Recordset1['Links']; ?></td>
Muss das Ganze dann so aussehen ...
<a href="<?php echo $row_Recordset1['Links']; ?></td>
... damit der Browser den Text als Link interpretiert?
Danke für die Geduld,
Peter
Niels Braczek
> <a href="<?php echo $adresse; ?>"><?php echo $adresse; ?></a>
>
> ähh, Semikolons vergessen...
Ich finde zwar auch, dass man sie setzen sollte, erforderlich sind sie
jedoch hier nicht.
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 |
------------------------------------------------------------------
Michael Müller
> ... damit der Browser den Text als Link interpretiert?
<a href="HTTP://WWW.MUSTER.DE">TEXT</a>
Dann steht auf der Seite TEXT, und wenn man draufklickt kommt man auf
HTTP://WWW.MUSTER.DE
Deine Aufgabe mit PHP besteht nun darin, für HTTP://WWW.MUSTER.DE durch
eine Variable zu ersetzen (und TEXT evtl durch die selbe Variable, wenn
du die URL als Linktext haben willst)
Das wird dann wohl so aussehen:
<a href="<?php echo $row_Recordset1['Links']; ?>"><?php echo
$row_Recordset1['Links']; ?></a></td>
Hoffe geholfen zu haben, und nicht am Problem vorbeigeschrammt zu sein ;)
Michael
Dirk Sohler
> Christoph Herrmann schrieb:
>> <a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
>>
>> Deinen schlechten Stil solltest einem Anfänger nicht als Lösung bieten.
>
> [...]
> ähh, Semikolons vergessen...
Nein, komplett „falsch“ gemacht.
--
Blubb
Peter Carl
> Hoffe geholfen zu haben, und nicht am Problem vorbeigeschrammt zu sein ;)
> Michael
Hast Du, vielen Dank! Ich habe das gleichmal reingebastelt!
Schönes Wochenende,
Peter
Markus Malkusch
> Jörg Ellermann schrieb:
>> <a href="<? echo $adresse ?>"><? echo $adresse ?></a>
>>
>> Oder verstehe ich die Frage falsch?
>
> <a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
>
> Deinen schlechten Stil solltest einem Anfänger nicht als Lösung bieten.
Ich persönliche benutze "<?=" ständig in meinen Templates. Was ist daran
schlecht? OK, "<? echo" vs. "<?=" ist schon umständlich, aber darum ging es
Dir offensichtlich nicht.
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>
Norbert Melzer
> Christoph Herrmann:
>> Jörg Ellermann schrieb:
>>> <a href="<? echo $adresse ?>"><? echo $adresse ?></a>
>>>
>>> Oder verstehe ich die Frage falsch?
>>
>> <a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
>>
>> Deinen schlechten Stil solltest einem Anfänger nicht als Lösung bieten.
>
> Ich persönliche benutze "<?=" ständig in meinen Templates. Was ist daran
> schlecht? OK, "<? echo" vs. "<?=" ist schon umständlich, aber darum ging es
> Dir offensichtlich nicht.
Es ging ihm um die Verwendung der Short-Tags. Du kannst heute schon nicht
garantieren, daß Short-Tags auf nem Server erlaubt sind wenn Du portabel
sein willst. Spätestens aber mit PHP 6 werden die Shorttags nicht mehr
funktionieren. Um <? bin ich nicht traurig, aber <?= als echo Kürzel bin
ich tatsächlich ein wenig traurig, war richtig schön für templates. Naja,
jetzt nutze ich für templates eine kleine eigene engine in der ich etwas
schreibe was identisch ist mit PHP Shorttags und entsprechend in
PHP-Longtags umgewandelt wird. Ist allerdings noch im frühen
entwicklungsstadium. Momentan muss ich den "Compiler" bei jeder Änderung
einmal von Hand starten. Ich will da nen schönen automatismus rein haben,
ähnlich wie bei Smartytemplates und den gecachten...
MfG
Norbert
Christoph Herrmann
> Ich persönliche benutze "<?=" ständig in meinen Templates. Was ist daran
> schlecht? OK, "<? echo" vs. "<?=" ist schon umständlich, aber darum ging es
> Dir offensichtlich nicht.
Einem Neuling würde ich nicht gerade einen Stil beibringen, der mit der
nächsten PHP Version hinfällig ist, wenn es auch eine "offiziellere"
Variante gibt, die er benutzen kann.
Oder sehe ich als Einziger ein Problem darin, dass diese Tags (bei "<?="
weiß ich gerade nicht, ob das auch weiterhin unterstützt wird, ich habe
diese noch nie benötigt/benutzt) bald nicht mehr unterstützt werden?
Christoph Herrmann
> Nein, komplett „falsch“ gemacht.
Würdest du deine Aussage auch begründen, sodass wir alle was davon
haben? Ansonsten ist deine Aussage relativ Sinnfrei.
Christoph Herrmann
> Warum sollte man? Was willst du hier mit XSS erreichen?
Was ist für dich da jetzt unklar? Was XSS ist und was dies bewirken kann
sollten ja klar sein, ansonsten einfach mal danach googeln. :)
Kannst das Beispiel ja einfach mal nehmen und bissle mit Script Tags und
JavaScript rumspielen. Noch bissle DOM dazu und du hast schöne
Designmöglichkeiten die Seite nach deinen Vorlieben zu gestalten.
[OT]
Sry wenn ich etwas sarkistisch wirke, aber wenn man jeden Tag bissle an
einem Referat über Hitler arbeitet... ^^
[/OT]
Thomas Hamacher
> Thomas Hamacher schrieb:
>> Warum sollte man? Was willst du hier mit XSS erreichen?
> Was ist für dich da jetzt unklar? Was XSS ist und was dies bewirken kann
> sollten ja klar sein, ansonsten einfach mal danach googeln. :)
Ich weiss was XSS ist, aber du anscheinend nicht. Wie willst du dieses
konkrete Script angreifen, wenn $adresse nicht mal von einem Benutzer
eingegeben wird?
XSS wird erst dann ein Thema, wenn Benutzereingaben wieder auf der Seite
dargestellt werden. Das ist hier aber nicht der Fall.
> Kannst das Beispiel ja einfach mal nehmen und bissle mit Script Tags und
> JavaScript rumspielen. Noch bissle DOM dazu und du hast schöne
> Designmöglichkeiten die Seite nach deinen Vorlieben zu gestalten.
Die habe ich als Autor des Scriptes sowieso, so what?
David Fuhr
> Michael Müller schrieb:
>
>> Hoffe geholfen zu haben, und nicht am Problem vorbeigeschrammt zu sein ;)
>> Michael
>
> Hast Du, vielen Dank! Ich habe das gleichmal reingebastelt!
Um deine HTML-Kenntnisse etwas aufzubessern solltest du mal hier [1]
vorbeischauen. Da wird auch erklärt, wie man Links erstellt [2].
[1] http://de.selfhtml.org/html/
[2] http://de.selfhtml.org/html/verweise/definieren.htm
Christoph Herrmann
> Ich weiss was XSS ist, aber du anscheinend nicht. Wie willst du dieses
> konkrete Script angreifen, wenn $adresse nicht mal von einem Benutzer
> eingegeben wird?
>
> XSS wird erst dann ein Thema, wenn Benutzereingaben wieder auf der Seite
> dargestellt werden. Das ist hier aber nicht der Fall.
Stimmt, er will ja nur Links aus einer Datenbank ausgeben (gerade
nochmal nachgelesen). Hab bei sowas immer im Hinterkopf gehabt es geht
um Links von Benutzern, deswegen die Aussage man sollte hier auf XSS
achten... (wobei es ja kein Nachteil hätte dies trotzdem zu
berücksichtigen) Aber hast natürlich Recht, wenn die Links nicht
ursprünglich von Benutzereingaben stammen sondern vom Autor selbst,
spielt dies hier keine Rolle.
Martin Lemke
> Kann sein, dass ich mich nicht klar ausgedrückt habe. Also: in der
> Datenbank steht in einem Textfeld ein Link, z.B. www.spiegel.de.
www.spiegel.de ist kein Link.
Kann es sein, dass Dir elementares Grundwissen zu html fehlt? Der Browser
sollte auch nicht irgend welche Zeichengketten als Link interpretieren.
Was ein Link ist, solltest Du korrekt in html bereitstellen.
Dies ist eine Link:
<a href='http://www.spiegel.de'>www.spiegel.de</a>
So etwas in php umzusetzen, sollte keine große erläuterungsbedürftige
Fragestellung darstellen.
Martin
Peter Carl
> Um deine HTML-Kenntnisse etwas aufzubessern solltest du mal hier [1]
> vorbeischauen. Da wird auch erklärt, wie man Links erstellt [2].
Gruß,
Peter
Peter Carl
> Kann es sein, dass Dir elementares Grundwissen zu html fehlt?
Exakt das ist der wunde Punkt. Mir fehlt nicht nur das Grundwissen,
sondern im Augenblick auch die Zeit dazu, mir es anzueignen. Deswegen
bin ich sehr dankbar für eure Antworten. So Schritt für Schritt lern ich
doch das eine oder andere.
Was hinter den Kulissen von DW, das ich benutze, abgeht, ist mir leider
weitgehend schleierhaft ...
Gruß,
Peter
Niels Braczek
> Was hinter den Kulissen von DW, das ich benutze, abgeht, ist mir leider
> weitgehend schleierhaft ...
Nach meiner Erfahrung lernt man am schnellesten und am meisten, wenn man
auf den ganzen KlickiBunti-Kram verzichtet. Ganz abgesehen davon, dass
man dann sehr viel mehr Kontrolle über das Ergebnis hat.
Peter Carl
> Nach meiner Erfahrung lernt man am schnellesten und am meisten, wenn man
> auf den ganzen KlickiBunti-Kram verzichtet. Ganz abgesehen davon, dass
> man dann sehr viel mehr Kontrolle über das Ergebnis hat.
Gebe Dir voll inhaltlich recht!
Gruß,
P.C.
Matthias Esken
> Was hinter den Kulissen von DW, das ich benutze, abgeht, ist mir leider
> weitgehend schleierhaft ...
Schalte in den Textmodus.
Webseiten macht man sowieso entweder mit Eclipse oder vi ...
Gruß,
Matthias
Claus Reibenstein
> Christoph Herrmann schrieb:
>
>> <a href="<?php echo $adresse ?>"><?php echo $adresse ?></a>
>
> <a href="<?php echo $adresse; ?>"><?php echo $adresse; ?></a>
>
> ähh, Semikolons vergessen...
Die an dieser Stelle nicht notwendig sind.
Gruß. Claus
Markus Malkusch
> Einem Neuling würde ich nicht gerade einen Stil beibringen, der mit der
> nächsten PHP Version hinfällig ist
Scheiße, das wäre in der Tat fatal.
Ich war mir nicht dessen bewusst, dass die PHP-Entwickler so heftig drauf
sind. Ich kann mir auf die Schnelle keine Quelle ergooglen. Du kannst mir
da sicher weiterhelfen.
Markus Malkusch
> Es ging ihm um die Verwendung der Short-Tags. Du kannst heute schon nicht
> garantieren, daß Short-Tags auf nem Server erlaubt sind wenn Du portabel
> sein willst.
Doch. Wenn ich mir einen Server aussuche, auf dem PHP laufen muss, dann kann
ich auch einen aussuchen, auf dem man Shorttags einschalten kann.
> Spätestens aber mit PHP 6 werden die Shorttags nicht mehr
> funktionieren.
Das ist (sofern das wirklich stimmt) in der Tat fatal und wird mich eine
Menge Zeit kosten.
> Naja, jetzt nutze ich für templates eine kleine eigene engine in der ich
> etwas schreibe was identisch ist mit PHP Shorttags und entsprechend in
> PHP-Longtags umgewandelt wird.
Daran denke ich auch gerade. Aber ich habe sowas von Null Bock d'rauf.
Weniger Arbeit und besser wird's sicher wenn man die PHP-Autoren
überredet "<?=" zu behalten. Irgendwie finde ich es schon dreist
Sprachelemente aus einer /stabilen/ Sprache zu entfernen.
Martin Lemke
Vielen Dank für Deine Ehrlichkeit.
> So Schritt für Schritt lern ich doch das eine oder andere.
Das ist definitiv der falsche Ansatz. Das Programmiertechnsische
Handwerkszeug stellt bei jeder Problemlösung im Grunde den kleineren Part
dar.
Wenn man für irgend ein Problem eine Lösung sucht, muss man sich zu
allererst in genau die dies betreffende Materie einarbeiten, sofern man
diese noch nicht beherrscht. -- Wer ist schon auf jedem Gebiet ein Experte?
Martin
Niels Braczek
> Christoph Herrmann:
>
>> Einem Neuling würde ich nicht gerade einen Stil beibringen, der mit der
>> nächsten PHP Version hinfällig ist
>
> Scheiße, das wäre in der Tat fatal.
>
> Ich war mir nicht dessen bewusst, dass die PHP-Entwickler so heftig drauf
> sind. Ich kann mir auf die Schnelle keine Quelle ergooglen. Du kannst mir
> da sicher weiterhelfen.
http://www.php.net/~derick/meeting-notes.html, Abschnitt 6.7: <? bleibt.
Dennoch ist die Verwendung von short open tags schlechter Stil. Es gibt
eine Variante, die nicht mit XML kollidiert und auf jedem Server
unabhängig von individuellen Einstellungen funktioniert. Alle anderen
Varianten verbieten sich somit von selbst.
Ulf Kadner
> http://www.php.net/~derick/meeting-notes.html, Abschnitt 6.7: <? bleibt.
Das Teil ist von 2005 :-). In php.internals hab ich gelesen das es
nicht bleibt. Im letzten PHP-Magazin stands auch.
MfG, Ulf
--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^
Claus Reibenstein
> Norbert Melzer:
>
>> Es ging ihm um die Verwendung der Short-Tags. Du kannst heute schon nicht
>> garantieren, daß Short-Tags auf nem Server erlaubt sind wenn Du portabel
>> sein willst.
>
> Doch. Wenn ich mir einen Server aussuche, auf dem PHP laufen muss, dann kann
> ich auch einen aussuchen, auf dem man Shorttags einschalten kann.
Bitte informiere Dich, was "portabel" bedeutet.
Unabhängig davon irrst Du. Aussuchen kannst Du Dir nur das, was
angeboten wird. Auf der (relativ) sicheren, aber auch teuren Seite bist
Du mit einem Root-Server. Wenn Du das Geld dazu hast und genug von
Systemadministration verstehst, kannst Du das ruhig tun.
Allerdings ist auch diese Sicherheit trügerisch. Spätestens dann, wenn
Du eine weitere Sprache, die "<?" benötigt, in Verbindung mit PHP nutzen
möchtest oder PHP auf Version 6 aktualisierst, ist es aus mit Short Open
Tags.
Links zu diesem Thema:
http://de.php.net/manual/de/ini.core.php
(Beschreibung von "short_open_tag")
http://de.php.net/manual/de/language.basic-syntax.php
(Hinweis zu "Example#1")
>> Spätestens aber mit PHP 6 werden die Shorttags nicht mehr
>> funktionieren.
>
> Das ist (sofern das wirklich stimmt) in der Tat fatal und wird mich eine
> Menge Zeit kosten.
Ist unter Linux ein 4-Zeiler, etwa so:
for F in *.php
do mv "$F" "$F.old"
sed -e 's/<?=/<?php echo /g' -e 's/<?/<?php /g' $F.old >$F
done
Selbst auf einem langsamen Rechner mit mehreren tausend PHP-Files dürfte
solch eine Konstruktion in relativ kurzer Zeit durchgelaufen sein.
Besser wäre es natürlich gewesen, es gleich von Anfang an richtig zu
machen :-)
> Weniger Arbeit und besser wird's sicher wenn man die PHP-Autoren
> überredet "<?=" zu behalten.
Lies Dir die o.g. Artikel durch. Wenn Du dann immer noch der Meinung
bist, dass Short Open Tags "besser" wären ...
> Irgendwie finde ich es schon dreist
> Sprachelemente aus einer /stabilen/ Sprache zu entfernen.
Definiere "stabile Sprache". Stabil kann IMHO bestenfalls der
Interpreter, Compiler oder was auch immer sein, aber nicht die Sprache.
Außerdem hat niemand vor, aus den _aktuellen_ Versionen etwas zu
entfernen. Die fraglichen Konstrukte sollen lediglich ab einer
_künftigen_ Version nicht mehr enthalten sein.
Programmiersprachen sind nun mal keine statischen Gebilde, sondern
entwickeln sich weiter. Gelegentlich kommt es dabei schon mal vor, dass
althergebrachte Sprachkonstrukte dabei überarbeitet oder auch entfernt
werden müssen. Solche "Änderungen, die dem Fortschritt dienen", findest
Du praktisch in _allen_ Programmiersprachen. PHP stellt diesbezüglich
keine Ausnahme dar.
Wenn Du - warum auch immer - trotz allem bei Short Open Tags bleiben
möchtest, kannst Du das gerne tun, wenn Du
- bei Versionen kleiner 6 bleibst,
- kein XML o.ä. benutzt,
- einen Server nutzt, der Short Open Tags zulässt,
- sicherstellst, dass Deine Programme nie auf einem anderen Server
laufen sollen.
Gruß. Claus
Helmut Hullen
Du (4spammersonly) meintest am 02.12.07:
>> Das ist (sofern das wirklich stimmt) in der Tat fatal und wird mich
>> eine Menge Zeit kosten.
> Ist unter Linux ein 4-Zeiler, etwa so:
> for F in *.php
> do mv "$F" "$F.old"
> sed -e 's/<?=/<?php echo /g' -e 's/<?/<?php /g' $F.old >$F
> done
s/<? /<?php /g
dürfte etwas besser funktionieren.
Viele Gruesse!
Helmut
Markus Malkusch
> Bitte informiere Dich, was "portabel" bedeutet.
Habe ich schon erwähnt dass mir nicht bewusst war, dass es in PHP6
abgeschafft wird?
> Unabhängig davon irrst Du. Aussuchen kannst Du Dir nur das, was
> angeboten wird.
Und es gibt eben genug Anbieter die mir den Schalter short_open_tag
anbieten. Ich sehe auch keinen vernünftigen Grund den auszuschalten.
> Auf der (relativ) sicheren, aber auch teuren Seite bist
> Du mit einem Root-Server.
Klar, und wenn der Provider kein PHP hat hol ich mir auch gleich einen
Rootserver.
> Allerdings ist auch diese Sicherheit trügerisch. Spätestens dann, wenn
> Du eine weitere Sprache, die "<?" benötigt, in Verbindung mit PHP nutzen
> möchtest
Es ist äußerst unwahrscheinlich dass meine Templates *vor* PHP von jemand
anderem interpretiert werden.
> Lies Dir die o.g. Artikel durch. Wenn Du dann immer noch der Meinung
> bist, dass Short Open Tags "besser" wären ...
Danke. Ohne Dich wäre ich nie darauf gekommen, dass ich Steueranweisungen
durch ein <?= '<?...?>' ?> ausgeben muss.
> Definiere "stabile Sprache".
Sprachkonstrukte bleiben erhalten. Insbesondere solche, die PHP zum
Interpretieren anweisen.
Konni Scheller
> Ich persönliche benutze "<?=" ständig in meinen Templates. Was ist daran
> schlecht? OK, "<? echo" vs. "<?=" ist schon umständlich, aber darum ging es
> Dir offensichtlich nicht.
Ich halte nicht viel davon. Es haut immer den XML-Parser durcheinander
:-)
Außerdem verwende ich dann eher Konstrukte wie
define ('HTML_TEMPLATE','<a href="%s">%s</a>');
und dann
printf(HTML_TEMPLATE,$linkziel,$linktext);
Sieht irgendwie sauberer aus ;)
Servus,
Konni
--
Inzwischen ohne Signatur
Konni Scheller
> Webseiten macht man sowieso entweder mit Eclipse oder vi ...
*hüstel*
Konni, der nach wie vor BBEdit verwendet...
--
Inzwischen ohne Signatur
Claus Reibenstein
> Claus Reibenstein:
>
>> Bitte informiere Dich, was "portabel" bedeutet.
>
> Habe ich schon erwähnt dass mir nicht bewusst war, dass es in PHP6
> abgeschafft wird?
Bist Du schon mal auf die Idee gekommen, dass Antworten nicht im
luftleeren Raum stehen, sondern sich eventuell direkt auf die davor
stehenden Zitate beziehen könnten? Offensichtlich ist Dir dieser
Zusammenhang entgangen.
>> Unabhängig davon irrst Du. Aussuchen kannst Du Dir nur das, was
>> angeboten wird.
>
> Und es gibt eben genug Anbieter die mir den Schalter short_open_tag
> anbieten.
Noch.
> Ich sehe auch keinen vernünftigen Grund den auszuschalten.
Dir wurden genügend vernünftige Gründe genannt.
> Es ist äußerst unwahrscheinlich dass meine Templates *vor* PHP von jemand
> anderem interpretiert werden.
Davor vielleicht nicht, aber möglicherweise danach.
>> Lies Dir die o.g. Artikel durch. Wenn Du dann immer noch der Meinung
>> bist, dass Short Open Tags "besser" wären ...
>
> Danke. Ohne Dich wäre ich nie darauf gekommen, dass ich Steueranweisungen
> durch ein <?= '<?...?>' ?> ausgeben muss.
Das ist interessant. Auf der einen Seite möchtest Du - wie alle
tippfaulen Hacker - Short Open Tags haben, um dann auf der anderen Seite
sonstige Steueranweisungen umständlich per PHP zu erzeugen, die Du durch
simples Abschalten der Short Open Tags genau so bequem nutzen könntest
wie normale PHP-Tags.
>> Definiere "stabile Sprache".
>
> Sprachkonstrukte bleiben erhalten. Insbesondere solche, die PHP zum
> Interpretieren anweisen.
Ich fürchte, eine solche Sprache gibt es nicht und wird es wohl auch nie
geben.
Gruß. Claus
frank paulsen
> Allerdings ist auch diese Sicherheit trügerisch. Spätestens dann, wenn
> Du eine weitere Sprache, die "<?" benötigt, in Verbindung mit PHP nutzen
> möchtest oder PHP auf Version 6 aktualisierst, ist es aus mit Short Open
> Tags.
das ist sehr bedauerlich.
> Ist unter Linux ein 4-Zeiler, etwa so:
>
> for F in *.php
> do mv "$F" "$F.old"
> sed -e 's/<?=/<?php echo /g' -e 's/<?/<?php /g' $F.old >$F
> done
>
> Selbst auf einem langsamen Rechner mit mehreren tausend PHP-Files dürfte
> solch eine Konstruktion in relativ kurzer Zeit durchgelaufen sein.
mit der fuer sed seit einiger zeit verfuegbaren option fuer inplace
editing (-i oder --in-place) waere es kuerzer, wuerde aber natuerlich
genau meine paar seiten zerdengeln, auf denen ich die handhabung von
"<?=" als templates diskutiere.
nahezu jede antwort, die ein globales parserloses ersetzen ueber einen
grossen datenbestand empfiehlt, verkennt den tatsaechlichen aufwand grandios.
--
frobnicate foo
Niels Braczek
> Niels Braczek wrote:
>
>> http://www.php.net/~derick/meeting-notes.html, Abschnitt 6.7: <? bleibt.
>
> Das Teil ist von 2005 :-).
Ich kenne kein anderen offizielles Dokument.
> In php.internals hab ich gelesen das es
> nicht bleibt. Im letzten PHP-Magazin stands auch.
Hast du's etwas genauer? Google-Suche in ersterem und Durchblättern von
letzterem ergab kein Ergebnis.
Michael Fesser
>Claus Reibenstein:
>
>> Bitte informiere Dich, was "portabel" bedeutet.
>
>Habe ich schon erwähnt dass mir nicht bewusst war, dass es in PHP6
>abgeschafft wird?
Ob komplett abgeschafft oder nur per default deaktiviert - die Frage
steht noch im Raum. Spielt aber einklich keine wirkliche Rolle, denn
short open tags waren seit je her nur zweite Wahl.
>> Unabhängig davon irrst Du. Aussuchen kannst Du Dir nur das, was
>> angeboten wird.
>
>Und es gibt eben genug Anbieter die mir den Schalter short_open_tag
>anbieten. Ich sehe auch keinen vernünftigen Grund den auszuschalten.
Code ohne short open tags ist portabler. Das ist Grund genug. Wenn es
nur um unnötige Tipperei geht - viele Editoren bieten entsprechende
Möglichkeiten, um z.B. "<?=" automagisch durch "<?php echo" zu ersetzen.
>> Definiere "stabile Sprache".
>
>Sprachkonstrukte bleiben erhalten. Insbesondere solche, die PHP zum
>Interpretieren anweisen.
Ein "<?" ist nicht PHP-spezifisch, es könnte ebenso die an den Server
angeschlossene Kaffeemaschine starten. Ein "<?php" hingegen _ist_ PHP-
spezifisch und wird korrekt interpretiert.
Micha
Inge Bein
> .oO(Markus Malkusch)
Test:
.oO° (Michael Fesser) ...
Nein, zu klein ;)
Dirk Sohler
> Dirk Sohler schrieb:
>> Nein, komplett „falsch“ gemacht.
>
> Würdest du deine Aussage auch begründen, sodass wir alle was davon
> haben? Ansonsten ist deine Aussage relativ Sinnfrei.
Jeder hat zwar seinen Stil, aber anstatt wild zu mischen, und ständig
zwischen PHP und HTML hin-und-her-zu-schalten, würde ich es so machen
echo '<a href="'.$adresse.'">'.$adresse.'</a>';
--
Blubb
Claus Reibenstein
Und ich würde es so machen:
echo "<a href='$adresse'>$adresse</a>";
Aber was hat das mit Deiner oben zitierten Aussage zu tun? Inwieweit
beantwortet das Christophs berechtigte Frage?
Gruß. Claus
Sven Drieling
Hallo,
> Ulf Kadner schrieb:
>> Niels Braczek wrote:
>>
>>> http://www.php.net/~derick/meeting-notes.html, Abschnitt 6.7: <? bleibt.
>>
>> Das Teil ist von 2005 :-).
>
> Ich kenne kein anderen offizielles Dokument.
Im
PHP Release Management Wiki
http://wiki.pooteeweet.org/PhP60
ist unter 'Under discussion':
kill "<%" but keep "<?"
aufgeführt.
Und unter 'Dropped Items'
15. add support for <?php="foo" ?>
tschuess
[|8:)
Claus Reibenstein
> Im
>
> PHP Release Management Wiki
> http://wiki.pooteeweet.org/PhP60
>
> ist unter 'Under discussion':
>
> kill "<%" but keep "<?"
>
> aufgeführt.
Das heißt also: Es ist noch nichts entschieden. Das lässt ja noch hoffen.
"<%" (ASP-Tags) habe ich nie benutzt. Ich wusste nicht mal, dass die
überhaupt möglich sind.
> Und unter 'Dropped Items'
>
> 15. add support for <?php="foo" ?>
Das hätte sogar mir gefallen. Schade eigentlich.
Gruß. Claus
Ulf Kadner
> Ulf Kadner schrieb:
>> Im letzten PHP-Magazin stands auch.
>
> Hast du's etwas genauer? Google-Suche in ersterem und Durchblättern von
> letzterem ergab kein Ergebnis.
Mein Fehler. Was ich meine ist nicht das PHP-Magazin sondern das
aktuelle PHP-Journal ab Seite 32.
Aber offensichtlich haben die da unrecht. Der Link den Dir Sven gepostet
hat scheint offensichlich die beste Quelle zu sein.
Ulf Kadner
> Und es gibt eben genug Anbieter die mir den Schalter short_open_tag
> anbieten. Ich sehe auch keinen vernünftigen Grund den auszuschalten.
Als würde das eine Rolle spielen. Es geht doch nicht darum was Dir als
Entwickler gerad in den Kram past sondern was langfristig gesehen
bessere Chancen hat als PHP-Code zu funktionieren. Kurzsichtiges Denken
kann man sich als Softwareentwickler nicht leisten. Es sei den man baut
nur Software für sich selbst.
> Sprachkonstrukte bleiben erhalten. Insbesondere solche, die PHP zum
> Interpretieren anweisen.
War klar das das Argument kommt. Wenn Du von Anfang an den Empfehlenung
des PHP-Teams diesbezüglich gefolgt wärst würde sich Dir diese
Problematik garnicht auszwängen. Leute die sich daran gehalten haben
interessieren sich nicht für Deine aus was auch immer für Gründen
entstandenen unnötigen Ansprüche.
Gerade Entwickler wie Du sind das Problem das PHP kaum sinnvolle
Neuerungen bekommt oder geplante Neuerungen entfallen. (Ist nicht
persöhnlich gemeint!) Wenn alle (oder die Mehrheit) derjenigen die sich
PHP-Programmierer nennen diesen Empfehlungen zur Nichtverwendung von
Short-OpenTags gefolgt wären würde sich heute garnicht die Frage stellen
ob diese wegfallen sollen. Die gäbs wohl schon nicht mehr.
Christoph Herrmann
> Gerade Entwickler wie Du sind das Problem das PHP kaum sinnvolle
> Neuerungen bekommt oder geplante Neuerungen entfallen. (Ist nicht
> persöhnlich gemeint!) Wenn alle (oder die Mehrheit) derjenigen die sich
> PHP-Programmierer nennen diesen Empfehlungen zur Nichtverwendung von
> Short-OpenTags gefolgt wären würde sich heute garnicht die Frage stellen
> ob diese wegfallen sollen. Die gäbs wohl schon nicht mehr.
genau aus dem Grund verstehe ich diese Diskussion hier nicht. Warum ist
es wichtig, ob diese Tags noch weiterhin unterstützt bleiben? Geht doch
ganz einfach den klaren Weg und nehmt normale Tags. Wenn das alle machen
würden, könnte man PHP endlich von Altlasten befreien und sich um
sinnvollere Sachen kümmern...
--
Mit freundlichen Grüßen,
Christoph Herrmann
Michael Fesser
Tja, und mir rollen sich bei solch unübersichtlichem Mischmasch von
einfachen und doppelten Anführungszeichen sowie Punkten die Zehennägel
hoch. Sowas schreit geradezu nach vergessenen Anführungszeichen.
Ich würde es durchaus auch so machen:
printf('<a href="%s">%s</a>', $adresse, $adresse);
Aber abgesehen vom persönlichen Stil - was war denn nun komplett
„falsch“ gemacht?
Micha
Konni Scheller
> Warum ist
> es wichtig, ob diese Tags noch weiterhin unterstützt bleiben?
Eigentlich liegt das auf der Hand. Wenn dein Provider jetzt auf PHP6
umstellt, wo diese Tags nicht mehr unterstützt werden würden täten
könnten, ;) dann würden plötzlich eine MENGE Leute riesige Probleme mit
ihrer (teilweise gekauften!) Software haben.
Also aktualisiert der Provider eben *nicht*, damit die Software weiter
funktioniert. Und das bremst natürlich die Weiterentwicklung.
man Abwärtskompatibilität...
Claus Reibenstein
> Christoph Herrmann <herr...@dragonprojects.de> wrote:
>
>> Warum ist es wichtig, ob diese Tags noch weiterhin unterstützt
>> bleiben?
>
> Eigentlich liegt das auf der Hand. Wenn dein Provider jetzt auf PHP6
> umstellt, wo diese Tags nicht mehr unterstützt werden würden täten
> könnten, ;) dann würden plötzlich eine MENGE Leute riesige Probleme
> mit ihrer (teilweise gekauften!) Software haben.
Eine _gekaufte_ PHP-Software, die Short Open Tags verwendet, ist kaputt
und gehört dem Hersteller um die Ohren gehauen!
> Also aktualisiert der Provider eben *nicht*, damit die Software
> weiter funktioniert. Und das bremst natürlich die Weiterentwicklung.
>
> man Abwärtskompatibilität...
Abwärtskompatibilität um jeden Preis kann die Weiterentwicklung genauso
bremsen und tut dies gelegentlich auch.
Gruß. Claus
Christoph Herrmann
> Eigentlich liegt das auf der Hand. Wenn dein Provider jetzt auf PHP6
> umstellt, wo diese Tags nicht mehr unterstützt werden würden täten
> könnten, ;) dann würden plötzlich eine MENGE Leute riesige Probleme mit
> ihrer (teilweise gekauften!) Software haben.
>
> Also aktualisiert der Provider eben *nicht*, damit die Software weiter
> funktioniert. Und das bremst natürlich die Weiterentwicklung.
>
> man Abwärtskompatibilität...
Abwärtskompatibilität <> Weiterentwicklung
Den Widerspruch gibt es doch immer. :) Aber ich denke die Altlast ist
lange genug mitgeschleift worden (ich sehe immer noch keinen Grund,
warum man diese Tags den Normalen vorziehen sollte außer weniger
Schreibarbeit) und wird auch noch lange nach dem Release von PHP 6 noch
unterstützt. Schließlich gibt es heute noch Provider die PHP 4 unterstützen.
Also wo liegt hier das Problem. ;)
Ulf Kadner
> Warum ist
> es wichtig, ob diese Tags noch weiterhin unterstützt bleiben? Geht doch
> ganz einfach den klaren Weg und nehmt normale Tags. Wenn das alle machen
> würden, könnte man PHP endlich von Altlasten befreien und sich um
> sinnvollere Sachen kümmern...
Ich finde allerdings auch das den PHP-Entwicklern der Mut zu
schwergewichtigen Änderungen fehlt. Wenn die weiter so in Ihrer
Einstellung verharren wird irgendwann keiner mehr PHP nutzen wollen da
es mit anderen modernen Sprachen wesentlich
angenehmer/leichter/schneller umsetzbar ist.
Nur mal als Beispiel will ich ASP.NET nennen (auf nem Linux mit Mono als
Grundlage) Das teste ich gerad ausgiebig und bin begeistert. Ist
schneller als PHP, reines OOP und nutzt sehr moderne Paradigmen.
Allerdings ist das dann Geschmackssache.
Ich hatte eigentlich gehofft das PHP in Version 6 nen wesentlich
größeren Schritt nach vorn macht und den ganzen alten Rotz von Bord
wirft. Aber dank zahlreicher sturer Entwickler wird das wohl auch in
version 7 nicht der Fall sein.
Die PHP-Entwickler berufen sich z.B. bei der Anfrage ob man denn nicht
endlich eine stärkere Typisierung (voll typisierte Parameter und
Variablen z.B) einführen könnte darauf das dies historisch so gewachsen
sei und absolut undenkbar wäre für PHP.
Klar. ist das so gewachsen, aber im allgemeinen schafften es auch andere
Sprachen dieses Feature einzuführen. Seit PHP5 gibts ja auch eine
teilweise typisierte Parametrisierung. Sollte man das nicht mal zum Ende
bringen und das vollständig implementieren?
Niels Braczek
> Im
>
> PHP Release Management Wiki
> http://wiki.pooteeweet.org/PhP60
>
> ist unter 'Under discussion':
>
> kill "<%" but keep "<?"
>
> aufgeführt.
Danke für den Link.
"Under discussion" heißt aber doch, dass das noch nicht abschließend
entschieden ist.
Christoph Herrmann
> Ich finde allerdings auch das den PHP-Entwicklern der Mut zu
> schwergewichtigen Änderungen fehlt. Wenn die weiter so in Ihrer
> Einstellung verharren wird irgendwann keiner mehr PHP nutzen wollen da
> es mit anderen modernen Sprachen wesentlich
> angenehmer/leichter/schneller umsetzbar ist.
ASP.NET kenne ich nicht, aber was ich unter Java so getestet habe muss
ich sagen, dass gerade der Einstieg bei weitem schwerer von statten geht
und etwaige Ergebnisse nicht so schnell produzierbar sind wie unter PHP.
> Nur mal als Beispiel will ich ASP.NET nennen (auf nem Linux mit Mono als
> Grundlage) Das teste ich gerad ausgiebig und bin begeistert. Ist
> schneller als PHP, reines OOP und nutzt sehr moderne Paradigmen.
> Allerdings ist das dann Geschmackssache.
Java zieht ebenso an PHP vorbei. Nur leider spricht da das ganz große
Manko der Servervoraussetzung eine zu große Rolle (jeder Unterstützt
PHP, kein Webspace würde Java unterstützen).
> Ich hatte eigentlich gehofft das PHP in Version 6 nen wesentlich
> größeren Schritt nach vorn macht und den ganzen alten Rotz von Bord
> wirft. Aber dank zahlreicher sturer Entwickler wird das wohl auch in
> version 7 nicht der Fall sein.
>
> Die PHP-Entwickler berufen sich z.B. bei der Anfrage ob man denn nicht
> endlich eine stärkere Typisierung (voll typisierte Parameter und
> Variablen z.B) einführen könnte darauf das dies historisch so gewachsen
> sei und absolut undenkbar wäre für PHP.
Abwärtskompatibilität ist kein Argument für Stillstand (meiner Meinung
nach)...
> Klar. ist das so gewachsen, aber im allgemeinen schafften es auch andere
> Sprachen dieses Feature einzuführen. Seit PHP5 gibts ja auch eine
> teilweise typisierte Parametrisierung. Sollte man das nicht mal zum Ende
> bringen und das vollständig implementieren?
genau das in eine Thema, das mir noch etwas fehlt. :) Aber wenn ich
sehe, wie viel Entwickler Objektorientierung nutzen bzw. im Gegensatz
dazu diese strikt Ablehnen, kann ich die Bedenken der PHP Entwickler
etwas verstehen...
Thomas Hamacher
>>> Warum ist es wichtig, ob diese Tags noch weiterhin unterstützt
>>> bleiben?
>> Eigentlich liegt das auf der Hand. Wenn dein Provider jetzt auf PHP6
>> umstellt, wo diese Tags nicht mehr unterstützt werden würden täten
>> könnten, ;) dann würden plötzlich eine MENGE Leute riesige Probleme
>> mit ihrer (teilweise gekauften!) Software haben.
> Eine _gekaufte_ PHP-Software, die Short Open Tags verwendet, ist kaputt
> und gehört dem Hersteller um die Ohren gehauen!
Schwachsinn! Wenn du die Konfiguration um die Software herum änderst
ohne vorher mit dem Hersteller darüber zu sprechen, dann ist das als
Kunde dein Problem. Wenn ich für meine Software die Erweiterung XYZ
benötige, dann ist die Software auch nicht kaputt, wenn der unfähige
Admin dann nach einem Serverumzug oder PHP-Update die entsprechende
Erweiterung nicht mehr bereitstellt.
Ausserdem konnte hier noch niemand eine zuverlässige Aussage machen, ob
die Short-Tags jetzt in PHP6 rausfallen oder nicht. Ulf hat da wohl in
irgendeinem PHP-Magazin was gelesen, aber das einzige "offizielle"
Dokument hat Niels gepostet und daraus geht *nicht* hervor, dass die
Tags entfallen. Also ist die Diskussion rein akademisch und ohne
jegliche Relevanz für die Praxis.
>> Also aktualisiert der Provider eben *nicht*, damit die Software
>> weiter funktioniert. Und das bremst natürlich die Weiterentwicklung.
>> man Abwärtskompatibilität...
> Abwärtskompatibilität um jeden Preis kann die Weiterentwicklung genauso
> bremsen und tut dies gelegentlich auch.
ACK. Aber dreimal darfst du raten, warum die Hoster nicht einfach
umstellen. Sie könnten ja genau mit deinen Worten argumentieren und
einfach behaupten, dass sie Software kaputt sei...
--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)
Peter Carl
> Für eine Antwort besten Dank im Voraus,
Herzlichen Dank für die hilfreichen Antworten. Auch wenn mein Vorgehen
im Augenblick stümperhaft ist, dank Eurer Hilfe hab ich das
fertigbekommen, was ich wollte.
Beste Grüße,
Peter
Konni Scheller
> Eine _gekaufte_ PHP-Software, die Short Open Tags verwendet, ist kaputt
> und gehört dem Hersteller um die Ohren gehauen!
Warum? Es gab Zeiten, da galt so eine Software nicht als kaputt.
> > Also aktualisiert der Provider eben *nicht*, damit die Software
> > weiter funktioniert. Und das bremst natürlich die Weiterentwicklung.
> >
> > man Abwärtskompatibilität...
>
> Abwärtskompatibilität um jeden Preis kann die Weiterentwicklung genauso
> bremsen und tut dies gelegentlich auch.
Davon rede ich die ganze Zeit. Dass ich etwas zu erklären versuche,
bedeutet nicht, dass ich dem zustimme.
Konni Scheller
> Ich finde allerdings auch das den PHP-Entwicklern der Mut zu
> schwergewichtigen Änderungen fehlt.
Ja.
> Wenn die weiter so in Ihrer
> Einstellung verharren wird irgendwann keiner mehr PHP nutzen wollen da
> es mit anderen modernen Sprachen wesentlich
> angenehmer/leichter/schneller umsetzbar ist.
Die Gefahr sehe ich eigentlich nicht.
Einer der Haupt-"Vorteile" von PHP (wie auch von HTML) ist eben, dass
man schnell was hinrotzen kann, das auch funktioniert. Zumindest so
lange, bis einem keiner erklärt, warum es so nicht geht.
> Ich hatte eigentlich gehofft das PHP in Version 6 nen wesentlich
> größeren Schritt nach vorn macht und den ganzen alten Rotz
was genau?
> von Bord wirft.
Ich fürchte, für jeden alten Rotz gibt es einen, der ihn als Kleber
verwendet...
> Die PHP-Entwickler berufen sich z.B. bei der Anfrage ob man denn nicht
> endlich eine stärkere Typisierung (voll typisierte Parameter und
> Variablen z.B) einführen könnte darauf das dies historisch so gewachsen
> sei und absolut undenkbar wäre für PHP.
Aua. Aua. Aua.
> Klar. ist das so gewachsen, aber im allgemeinen schafften es auch andere
> Sprachen dieses Feature einzuführen. Seit PHP5 gibts ja auch eine
> teilweise typisierte Parametrisierung. Sollte man das nicht mal zum Ende
> bringen und das vollständig implementieren?
100% Ack.
Thomas Hamacher
> Ulf Kadner <dr_l...@gmx.net> wrote:
> Einer der Haupt-"Vorteile" von PHP (wie auch von HTML) ist eben, dass
> man schnell was hinrotzen kann, das auch funktioniert. Zumindest so
> lange, bis einem keiner erklärt, warum es so nicht geht.
>> Klar. ist das so gewachsen, aber im allgemeinen schafften es auch andere
>> Sprachen dieses Feature einzuführen. Seit PHP5 gibts ja auch eine
>> teilweise typisierte Parametrisierung. Sollte man das nicht mal zum Ende
>> bringen und das vollständig implementieren?
> 100% Ack.
Meinst du nicht, dass sich das widerspricht? PHP ist doch auch auf Grund
der schwachen Typisierung so einfach, weil man sich keinen Kopf machen
muss und Äpfel mit Birnen vergleichen kann.
Ich wäre hier eher den anderen Weg gegangen und hätte (eben damit es
konsequent ist) das Type-Hinting gar nicht erst implementiert. Das ist
doch sowieso nutzlos, solange man nicht jeden nativen Datentyp in ein
Objekt packt.
Niels Braczek
> Ausserdem konnte hier noch niemand eine zuverlässige Aussage machen, ob
> die Short-Tags jetzt in PHP6 rausfallen oder nicht. Ulf hat da wohl in
> irgendeinem PHP-Magazin was gelesen, aber das einzige "offizielle"
> Dokument hat Niels gepostet und daraus geht *nicht* hervor, dass die
> Tags entfallen. Also ist die Diskussion rein akademisch und ohne
> jegliche Relevanz für die Praxis.
Fakt ist: <?php funktioniert immer, <? nur manchmal.
Fakt ist: Bei Verwerndung von <? gibt es Probleme mit XML, bei <?php nicht.
Meines Erachtens entfällt damit die Wahlmöglichkeit und <?php ist Muss.
Ich beurteile die Qualität eines Skriptes durchaus auch anhand dieses
Kriteriums. Die Wahrscheinlichkeit, dass ein Skript mit short open tags
durchfällt ist sehr hoch; höchstwahrscheinlich wurde auch in anderen
bereichen geschlampt.
Stefan Froehlich
> Ich wäre hier eher den anderen Weg gegangen und hätte (eben damit
> es konsequent ist) das Type-Hinting gar nicht erst implementiert.
> Das ist doch sowieso nutzlos, solange man nicht jeden nativen
> Datentyp in ein Objekt packt.
Ah, aber wenn, dann...
Du kannst beim Type-Hinting auch Interfaces angeben, was dann bei
der Verwendung der Funktion eine sehr praktische Sache ist. Und
gezwungen wird ja ohnehin keiner - alles kann, nichts muss :-)
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Einsame Klasse! Stefan.
(Sloganizer)
Thomas Hamacher
> Thomas Hamacher schrieb:
>> Ausserdem konnte hier noch niemand eine zuverlässige Aussage machen, ob
>> die Short-Tags jetzt in PHP6 rausfallen oder nicht. Ulf hat da wohl in
>> irgendeinem PHP-Magazin was gelesen, aber das einzige "offizielle"
>> Dokument hat Niels gepostet und daraus geht *nicht* hervor, dass die
>> Tags entfallen. Also ist die Diskussion rein akademisch und ohne
>> jegliche Relevanz für die Praxis.
> Fakt ist: <?php funktioniert immer, <? nur manchmal.
Ja. Portable Software sollte sich weder auf das eine, noch auf das
andere (s.u.) verlassen, aber Software die das nutzt generell als kaputt
zu bezeichnen halte ich für übertrieben.
Vielleicht wurde sich ja bei einer Individuallösung für einen Kunden
bewusst dafür entschieden, weil die Umgebung definierbar ist oder weil
man eben <?=$var?> in Templates verwenden will und sich deshalb auch
einen Hoster mit aktivierten Short-Open-Tags ausgesucht hat.
Wenn sich jetzt die Umgebung ändert, dann hat man Pech gehabt oder muss
sich nach einer neuen Umgebung umschauen. Das hätte man aber auch, wenn
plötzlich statt PHP nur noch Perl oder Java zur Verfügung stünde.
> Fakt ist: Bei Verwerndung von <? gibt es Probleme mit XML, bei <?php nicht.
Wenn deine portable Software "überall" laufen soll, dann musst du auch
damit rechnen, dass Short-Open-Tags aktiviert sind und du kannst eben
keine Scripte mit <?xml ?>-Header ohne echo-Wrapper[tm] verwenden, weil
es dann kracht. Von daher ist das kein Argument gegen Short-Open-Tags,
sondern ein Zeichen für "kaputte" Software.
> Meines Erachtens entfällt damit die Wahlmöglichkeit und <?php ist Muss.
> Ich beurteile die Qualität eines Skriptes durchaus auch anhand dieses
> Kriteriums. Die Wahrscheinlichkeit, dass ein Skript mit short open tags
> durchfällt ist sehr hoch; höchstwahrscheinlich wurde auch in anderen
> bereichen geschlampt.
Mit dieser Aussage wirst du auch wahrscheinlich in den meisten Fällen
recht haben. Jedoch heisst das für mich eigentlich nur, dass schlechte
Programmierer dazu tendieren <? zu verwenden. Der Umkehrschluss ist
nicht zulässig :)
Davon mal ganz abgesehen stellt sich für mich die Frage gar nicht, da
ich eine Template-Engine verwende und mir i.d.R. auch die Umgebung
aussuchen kann.
Thomas Hamacher
> On Mon, 03 Dec 2007 17:36:09 +0100 Thomas Hamacher wrote:
>> Ich wäre hier eher den anderen Weg gegangen und hätte (eben damit
>> es konsequent ist) das Type-Hinting gar nicht erst implementiert.
>> Das ist doch sowieso nutzlos, solange man nicht jeden nativen
>> Datentyp in ein Objekt packt.
> Ah, aber wenn, dann...
Ja. Dann noch die Operator-Overloading-Extension aus PECL und ab geht
die Post :). Wenn da nicht der enorme Speicherhunger wäre und die miese
Performance.
Johannes Mueller
> Fakt ist: Bei Verwerndung von <? gibt es Probleme mit XML, bei <?php
> nicht. Meines Erachtens entfällt damit die Wahlmöglichkeit und <?php
> ist Muss. Ich beurteile die Qualität eines Skriptes durchaus auch
> anhand dieses Kriteriums. Die Wahrscheinlichkeit, dass ein Skript mit
> short open tags durchfällt ist sehr hoch; höchstwahrscheinlich wurde
> auch in anderen bereichen geschlampt.
Ich hatte Probleme mit dem Zend Framework, weil da ein Spaßvogel <? statt
<?php in einigen Klassen benutzt hatte. :)
Grüße
Johannes
--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.
Magnus Rosenbaum
> s/<? /<?php /g
Das würde aber alle Short-Tags übersehen, denen kein Leerzeichen folgt.
Also: s/<? \?/<?php /g
--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641
Konni Scheller
> Meinst du nicht, dass sich das widerspricht?
Eigentlich nicht.
> Ich wäre hier eher den anderen Weg gegangen und hätte (eben damit es
> konsequent ist) das Type-Hinting gar nicht erst implementiert. Das ist
> doch sowieso nutzlos, solange man nicht jeden nativen Datentyp in ein
> Objekt packt.
Das ist ein Anfang, und mich freut das sehr. Fehlersuche ist deutlich
einfacher.
Servus,
Konni
(mit notices on)
--
Inzwischen ohne Signatur
Niels Braczek
> Helmut Hullen wrote:
>> s/<? /<?php /g
>
> Das würde aber alle Short-Tags übersehen, denen kein Leerzeichen folgt.
> Also: s/<? \?/<?php /g
<?xml => <?php xml
Martin Lemke
> oder vi ...
Warum sollte man sich das antun?
M.
Magnus Rosenbaum
> <?xml => <?php xml
Ja, richtig, aber in dem Code mit Short-Tags hat ein <?xml ja ohnehin
nicht funktionieren können, also wird es - sofern das PHP-Skript
funktioniert - dort auch nicht enthalten sein. Und wir müssen ja auch die
Stellen ersetzen wo auf das Short-Tag ohne Whitespace direkt ein Kommando
folgt. Bei Short-Tags ist das im Gegensatz zu den "Long-Tags" ja erlaubt.
Aber alles nur theoretisch, mir ist nämlich eingefallen, dass ein <? in
einem String von PHP inzwischen (das war früher als anders) nicht mehr als
Open-Tag interpretiert wird. Folgendes funktioniert:
<? echo "<?"; ?>
Also wird das mit dem Ersetzen schon viel komplizierter. Wer wirklich
seine Short-Tags durch "Long-Tags" ersetzen will kann dafür ja mein
phptidy hernehmen: http://cmr.cx/phptidy/
cu, Magnus
Claus Reibenstein
> Matthias Esken schrieb:
>
>> oder vi ...
>
> Warum sollte man sich das antun?
Diese Frage kann nur jemand stellen, der sich noch nie richtig mit
diesem guten, schnellen, zuverlässigen und mächtigen Werkzeug
auseinandergesetzt hat.
Gruß. Claus
benjamin radtke
echo '<a href="',$link,'">',$link,'</a>';
MfG Benny ;-)
Ulf Kadner
> Außerdem verwende ich dann eher Konstrukte wie
>
> define ('HTML_TEMPLATE','<a href="%s">%s</a>');
>
> und dann
>
> printf(HTML_TEMPLATE,$linkziel,$linktext);
>
> Sieht irgendwie sauberer aus ;)
Das sieht nicht nur so aus! ;-)
(s)printf würde ich auch immer der Vorzug geben.
Sehr vorbildlich Dein Code!
Konni Scheller
> (s)printf würde ich auch immer der Vorzug geben.
>
> Sehr vorbildlich Dein Code!
Danke, danke. ich habe mich oft genug mit schlechten PHP
auseinandersetzen müssen.
Mittlerweile verwende ich phpunit und natürlich eclipse, man wird
animiert, sehr viel Kommentare zu schreiben. Seit ich PHP5 verwende,
macht auch Objektorientierung Spaß.
Nur zu wenig Zeit... im Frühjahr sollten wir noch einmal über ein
Treffen nachdenken.
Christoph Herrmann
> Das sieht nicht nur so aus! ;-)
> (s)printf würde ich auch immer der Vorzug geben.
mit welchem Vorteil? Ich finde man kommt auf diese Weise auf eine große
Anzahl an Konstanten, was in der Regel unübersichtlich werden kann.
PS damit wir noch etwas mehr Auswahl haben, bei mir würde es so aussehen:
$xmlnode->addChild('a')->setAttribute('href',
$linkziel)->setValue($linktext);
Hat bei mir den Vorteil, dass Attribute und Werte von Nodes ein
"htmlentities()" verpasst bekommen und somit gegen XSS relativ sicher sind.
Norbert Melzer
Er/Sie/Es ist klein und mächtig. Inzwischen läuft er sogar auf meinem PDA
und ich nutze ihn äusserst intensiv. Und ich habe mich bisher noch nicht
mit den Scriptingmöglichkeiten ausseinandergesetzt.
MfG
Norbert
PS: Gibt es eigentlich eine Deutsche Überswetzung zum VimBook? Wenn ja, wie
ist die ISBN?
Dirk Sohler
> Aber abgesehen vom persönlichen Stil - was war denn nun komplett
> „falsch“ gemacht?
War ’ne Vermutung. Ich habe den Styleguide für PHP nicht im Kopf, aber
eine wilde vermischung von PHP und normalem HTML ist da iirc nicht zu
finden :)
--
Blubb
Thomas Hamacher
> Thomas Hamacher <da...@nurfuerspam.de> wrote:
>> Meinst du nicht, dass sich das widerspricht?
> Eigentlich nicht.
Also es ist deiner Meinung nach einer der Hauptvorteile von PHP, dass
man schnell was hinrotzen kann und auf der anderen Seite sprichst du
davon, dann man PHP statisch typen sollte. Das widerspricht sich im
Bezug auf die Einfachheit.
>> Ich wäre hier eher den anderen Weg gegangen und hätte (eben damit es
>> konsequent ist) das Type-Hinting gar nicht erst implementiert. Das ist
>> doch sowieso nutzlos, solange man nicht jeden nativen Datentyp in ein
>> Objekt packt.
> Das ist ein Anfang, und mich freut das sehr. Fehlersuche ist deutlich
> einfacher.
Ja, mal sehen was kommt. Nehmen wir mal den fiktiven Code:
public function sum(int $x, int $y) {
return $x + $y;
}
echo sum(8, 9);
Angenommen das Type-Hinting würde für die primitiven Datentypen ebenso
eingeführt, wie es jetzt für Objekte implementiert wurde. Dann würde
etwas wie
echo sum($_GET['x'], $_GET['y'])
zu einem Fehler führen, da man erst explizit nach int casten muss. Die
Frage ist, ob man das will. Ich betrachte die dynamische Typisierung
eher als Stärke von PHP, sonst kann man gleich Java nehmen.
Konni Scheller
> >> oder vi ...
> >
> > Warum sollte man sich das antun?
>
> Er/Sie/Es ist klein und mächtig.
Was vi dann ohne Zweifel mit Dr. Evil gemeinsam hat.
Konni Scheller
> Also es ist deiner Meinung nach einer der Hauptvorteile von PHP, dass
> man schnell was hinrotzen kann und auf der anderen Seite sprichst du
> davon, dann man PHP statisch typen sollte. Das widerspricht sich im
> Bezug auf die Einfachheit.
Eigentlich nicht(2) ;-) Man kann schnell etwas testen, ohne einen
Riesenschlonz mit einbinden zu müssen. Danach sollte man sich aber
hinsetzen und es sauber machen. Sollte.
> Ja, mal sehen was kommt. Nehmen wir mal den fiktiven Code:
>
> public function sum(int $x, int $y) {
> return $x + $y;
> }
>
> echo sum(8, 9);
>
> Angenommen das Type-Hinting würde für die primitiven Datentypen ebenso
> eingeführt, wie es jetzt für Objekte implementiert wurde. Dann würde
> etwas wie
>
> echo sum($_GET['x'], $_GET['y'])
DAS will man auch nicht.
> zu einem Fehler führen, da man erst explizit nach int casten muss.
Ja. Und das wäre gut so.
Um deinen fiktiven Code zu zitieren:
public int function sum(int $x, int $y) {
return $x + $y;
}
wäre noch besser.
Christoph Herrmann
> Also es ist deiner Meinung nach einer der Hauptvorteile von PHP, dass
> man schnell was hinrotzen kann und auf der anderen Seite sprichst du
> davon, dann man PHP statisch typen sollte. Das widerspricht sich im
> Bezug auf die Einfachheit.
Findest du, dass Typensicherheit sich in längerer Entwicklungszeit
niederschlägt? Ich nicht. Ob ich mir nur Gedanken über die Datentypen
mache oder diese Gedanken gleichzeitig niederschreibe kommt in etwa auf
das Gleiche raus.
> Ja, mal sehen was kommt. Nehmen wir mal den fiktiven Code:
>
> public function sum(int $x, int $y) {
> return $x + $y;
> }
>
> echo sum(8, 9);
>
> Angenommen das Type-Hinting würde für die primitiven Datentypen ebenso
> eingeführt, wie es jetzt für Objekte implementiert wurde. Dann würde
> etwas wie
>
> echo sum($_GET['x'], $_GET['y'])
Ist ja eigentlich auch ein Fehler wenn man Strings übergibt, wenn man
eigentlich Zahlen will. Daher führe ich bei der Validierung, ob
Zahlenwerte in Formularen z.B. eingegeben wurden auch ein Cast in den
richtigen Datentyp durch.
> zu einem Fehler führen, da man erst explizit nach int casten muss. Die
> Frage ist, ob man das will. Ich betrachte die dynamische Typisierung
> eher als Stärke von PHP, sonst kann man gleich Java nehmen.
Ich denke doch, dass das Allgemeinwissen über die beiden Sprachen weit
genug reicht, dass die Unterschiede zwischen PHP und Java etwas mehr
umfassen als nur die Typisierung.
Ulf Kadner
> public function sum(int $x, int $y) {
>
> eingeführt, wie es jetzt für Objekte implementiert wurde. Dann würde
> etwas wie
>
> echo sum($_GET['x'], $_GET['y'])
>
> zu einem Fehler führen, da man erst explizit nach int casten muss.
Das ist ja einer der vielen Vorteile dessen.
> Frage ist, ob man das will.
Die Frage ist warum sollte man das nicht wollen. Gerad Typisierte
Parameter erparen einen in unterschiedlichen Szenarien ne Menge
Zusatzcode zum prüfen dessen was da kommt.
> ... sonst kann man gleich Java nehmen.
Na ich weis ja nicht...
Hadanite Marasek
> man schnell was hinrotzen kann und auf der anderen Seite sprichst du
> davon, dann man PHP statisch typen sollte. Das widerspricht sich im
> Bezug auf die Einfachheit.
Schön ist es aber, wenn ich die Option habe. Java zwingt mich zur
Gründlichkeit, was mir eben dann zuwiderläuft, wenn ich nur ein Konzept
testen möchte.
--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html
Hadanite Marasek
>
> define ('HTML_TEMPLATE','<a href="%s">%s</a>');
>
> und dann
>
> printf(HTML_TEMPLATE,$linkziel,$linktext);
>
> Sieht irgendwie sauberer aus ;)
Mein Ansatz ist eine Funktion namens xmltag, die $tag und $attribute
(assoziatives array) frisst. Beispiel:
$a["href"] = $link;
$a["class"] = $class;
if(!empty($id)) {
$a["id"] = $id;
}
echo xmltag("a", $a, FALSE).$name."</a>";
bzw. der Verwandte xmlEnclose:
echo xmlEnclose("a", $a, $name);
Ist sehr viel leichter zu erweitern...
Christoph Herrmann
> Mein Ansatz ist eine Funktion namens xmltag, die $tag und $attribute
> (assoziatives array) frisst. Beispiel:
>
> $a["href"] = $link;
> $a["class"] = $class;
> if(!empty($id)) {
> $a["id"] = $id;
> }
>
> echo xmltag("a", $a, FALSE).$name."</a>";
>
> bzw. der Verwandte xmlEnclose:
>
> echo xmlEnclose("a", $a, $name);
>
> Ist sehr viel leichter zu erweitern...
Also ich kann beide Argumente verstehen, die einen setzen XML Writer
ein, die anderen bauen das HTML lieber mit Strings zusammen. Aber eine
halbherzige Mischung sehe ich nicht gerade als leicht Erweiterbar an...
Thomas Hamacher
> Thomas Hamacher schrieb:
>> Also es ist deiner Meinung nach einer der Hauptvorteile von PHP, dass
>> man schnell was hinrotzen kann und auf der anderen Seite sprichst du
>> davon, dann man PHP statisch typen sollte. Das widerspricht sich im
>> Bezug auf die Einfachheit.
> Findest du, dass Typensicherheit sich in längerer Entwicklungszeit
> niederschlägt? Ich nicht. Ob ich mir nur Gedanken über die Datentypen
> mache oder diese Gedanken gleichzeitig niederschreibe kommt in etwa auf
> das Gleiche raus.
Was hat die Entwicklungszeit mit der Einfachheit zutun? Wenn ich nicht
über etwas nachdenken muss, dann ist es einfacher, als wenn ich es muss,
oder?
>> Ja, mal sehen was kommt. Nehmen wir mal den fiktiven Code:
>> public function sum(int $x, int $y) {
>> return $x + $y;
>> }
>>
>> echo sum(8, 9);
>>
>> Angenommen das Type-Hinting würde für die primitiven Datentypen ebenso
>> eingeführt, wie es jetzt für Objekte implementiert wurde. Dann würde
>> etwas wie
>>
>> echo sum($_GET['x'], $_GET['y'])
> Ist ja eigentlich auch ein Fehler wenn man Strings übergibt, wenn man
> eigentlich Zahlen will.
Nein. Ich kenne PHP und ich weiss wie PHP automatisch castet. Also ist
es kein Fehler, wenn ich mich darauf verlasse, dass $x und $y im
numerischen Kontext zu einem sinnvollen Wert gecastet wird.
>> zu einem Fehler führen, da man erst explizit nach int casten muss. Die
>> Frage ist, ob man das will. Ich betrachte die dynamische Typisierung
>> eher als Stärke von PHP, sonst kann man gleich Java nehmen.
> Ich denke doch, dass das Allgemeinwissen über die beiden Sprachen weit
> genug reicht, dass die Unterschiede zwischen PHP und Java etwas mehr
> umfassen als nur die Typisierung.
Ja. Das war auch mehr auf die statischen Typen bezogen, weil mich mein
Pseudocode schon sehr an Java erinnert. Mit nem Rückgabewert und ohne
das "function" würde es ein Java-Compiler sogar übersetzen.
Thomas Hamacher
> Hadanite Marasek schrieb:
>> Mein Ansatz ist eine Funktion namens xmltag, die $tag und $attribute
>> (assoziatives array) frisst. Beispiel:
>> $a["href"] = $link;
>> $a["class"] = $class;
>> if(!empty($id)) {
>> $a["id"] = $id;
>> }
>> echo xmltag("a", $a, FALSE).$name."</a>";
> Also ich kann beide Argumente verstehen, die einen setzen XML Writer
> ein, die anderen bauen das HTML lieber mit Strings zusammen. Aber eine
> halbherzige Mischung sehe ich nicht gerade als leicht Erweiterbar an...
ACK. Dann eher
echo xmltag('a', $a, false, $name);
und das schliessende Tag wird automatisch eingefügt.
Hadanite Marasek
>
> echo xmltag('a', $a, false, $name);
>
> und das schliessende Tag wird automatisch eingefügt.
xmltag("img", $img, TRUE); macht einen inline-Tag.
xmltag("a", $a, FALSE); einen offenen Tag.
Das was Du meinst mache ich mit xmlEnclose, was ich in meinem Beispiel
erwähnt habe.
Hadanite Marasek
>
> Also ich kann beide Argumente verstehen, die einen setzen XML Writer
> ein, die anderen bauen das HTML lieber mit Strings zusammen. Aber eine
> halbherzige Mischung sehe ich nicht gerade als leicht Erweiterbar an...
Mit erweiterbar meine ich: an einem Array kann ich eher was ändern/eine
Bedingung reinbauen als bei einem String. Zudem macht mir das Ding noch
ein htmlspecialchars() auf die Attributwerte, was will ich mehr?
Magnus Rosenbaum
> Ich habe den Styleguide für PHP nicht im Kopf,
Was für einen Styleguide meinst Du denn?
Ich kenne eigentlich (leider) nur den von PEAR und da steht soviel ich
weiß über PHP-Tags vs. echo nichts drin:
http://pear.php.net/manual/de/standards.php
Christoph Herrmann
> Was hat die Entwicklungszeit mit der Einfachheit zutun? Wenn ich nicht
> über etwas nachdenken muss, dann ist es einfacher, als wenn ich es muss,
> oder?
Als ich mache mir auch in PHP Gedanken über meine Datentypen (muss ich
ja eh, ich schreib diese extra in die API Doku rein ^^). Also wenn du
rechnest macht es schon einen Unterschied ob ich jetzt Strings,
Ganzzahlen oder Fließkommazahlen übergebe. Was da passiert, was zu was
gecastet wird sollte mit berücksichtigt werden. Aber kann ja sein, dass
ich da alleine bin mit meiner Meinung. :)
> Nein. Ich kenne PHP und ich weiss wie PHP automatisch castet. Also ist
> es kein Fehler, wenn ich mich darauf verlasse, dass $x und $y im
> numerischen Kontext zu einem sinnvollen Wert gecastet wird.
automatisch casten macht Java auch in gewissen Rahmen. Aber klar, in dem
Falle geb ich dir Recht, aber man muss sich dessen halt auch bewusst
sein, was da passiert.
> Ja. Das war auch mehr auf die statischen Typen bezogen, weil mich mein
> Pseudocode schon sehr an Java erinnert. Mit nem Rückgabewert und ohne
> das "function" würde es ein Java-Compiler sogar übersetzen.
Joa, übersetzen ist auch so ein Unterschied zu PHP. :)
Christoph Herrmann
> Mit erweiterbar meine ich: an einem Array kann ich eher was ändern/eine
> Bedingung reinbauen als bei einem String. Zudem macht mir das Ding noch
> ein htmlspecialchars() auf die Attributwerte, was will ich mehr?
was spricht bei dir gegen einen richtigen XML Writer? (irgendwo im
diesem Thread habe ich das Beispiel gebracht wie ich die Lösung mit
einem XML Writer machen würde als weitere Möglichkeit)
Der macht auch das was deine Funktionen machen, kümmert sich aber
komplett um die Syntax und die korrekte Verschachtelung der öffnenden
und schließenden Tags. (Weitere Beispiele oder meinen XML Writer gebe
ich dir gerne per PM, falls Interesse besteht)
Im übrigen, mehrere Attribute über ein assotiatives Array zu übergeben
ist mir auch noch nie in den Sinn gekommen. Darf man sich diese Idee
kopieren? ;) (Naja, verbieten darfst es eh nicht, aber der Höflichkeit
halber frag ich mal ^^)
steffen bruentjen
>Hadanite Marasek schrieb:
>Im übrigen, mehrere Attribute über ein assotiatives Array zu übergeben
>ist mir auch noch nie in den Sinn gekommen. Darf man sich diese Idee
>kopieren? ;) (Naja, verbieten darfst es eh nicht, aber der Höflichkeit
>halber frag ich mal ^^)
Ich bin auch mal soweit gegangen, dass ich möglichst viel einfaches
HTML in Programmierkonstrukte zu pressen versucht habe. Die Idee ist
eben naheliegend, weil alles eine Entsprechung in PHP hat und sich so
scheinbar sehr elegant lösen lässt.
Aber vergleiche z.B. eine dieser Zeilen
printf("<a class='ln' onclick='whatever()' href='%s'>%s</a>", $l, $l);
echo "<a class='ln' onclick='whatever()' href='$l'>$l</a>";
mit diesem:
$attributes = array(
'class' => 'ln',
'onclick' => 'whatever()',
'href' => $l
);
xmltag('a', $attributes, $l);
Ein einziger Blick auf eine der oberen Zeilen verrät dem Leser, was
dahinter steckt. Ganz im Gegenteil zur zweiten Lösung. Es gibt keinen
Königsweg, aber man sollte angemessene Maßstäbe suchen, um sich für
eine Möglichkeit zu entscheiden, da wären z.B. Flexibilität,
Konsistenz und selbstbeschreibender Code. Hier suggeriert die zweite
Möglichkeit einen komplexen Sachverhalt (die Erzeugung eines Links auf
10 Zeilen ausgebreitet!), der definitiv nicht da ist. Flexibel ist der
Code und damit erlaubt er auch eine konsistente Verwendung, aber
selbstbeschreibend? Keinesfalls, aber das mag jeder für sich
beurteilen.
Dann gab es ja im Thread noch diese Möglichkeit:
define('HTML_TEMPLATE_A','<a href="%s">%s</a>');
printf(HTML_TEMPLATE_A, $l, $l);
Das sieht für dieses Beispiel ganz gut aus, aber sobald sich Tags
verschachteln (Listen, Formulare, Tabellen, ...) oder man ein neues
Attribut (class='...') einfügen möchte, hat man schon wieder weitaus
mehr overhead (wenn das überhaupt noch sinnvoll zu lösen ist). Ich
verstehe nicht ganz, was daran vorbildlich sein soll - es ist alles
andere als flexibel, was eine konsistente Verwendung unmöglich macht.
Eine XML-Struktur per XMLWriter zu erzeugen, ist immer noch eine gute
Möglichkeit, vor allem weil korrektes XML erzeugt wird. Leider ist der
XML Baum nicht auf einen Blick zu sehen.
Bei der Verwendung von Templates hat man auf jeden Fall volle
Flexibilität (was den XML Code angeht) und selbstbeschreibenden Code
(das XML Dokument liegt direkt vor der Nase, alles andere findet sich
Programm-Quelltext). Ohne Frage haben Templates auch ihre Nachteile,
aber darum geht es hier nicht.
Insofern hängt eine gute Lösung immer vom Anwendungsfall ab, und der
kann Templates, XMLWriter oder Standardausgaben (echo, printf)
nahelegen. xHTML ist sehr intuitiv und auch halbwegs übersichtlich,
deshalb rechtfertigen nur echte Vorteile ein
"Programmiersprachen-Wrapping".
schöne grüße, steffen
Christoph Herrmann
> Ich bin auch mal soweit gegangen, dass ich möglichst viel einfaches
> HTML in Programmierkonstrukte zu pressen versucht habe. Die Idee ist
> eben naheliegend, weil alles eine Entsprechung in PHP hat und sich so
> scheinbar sehr elegant lösen lässt.
>
> Aber vergleiche z.B. eine dieser Zeilen
>
> printf("<a class='ln' onclick='whatever()' href='%s'>%s</a>", $l, $l);
> echo "<a class='ln' onclick='whatever()' href='$l'>$l</a>";
>
> mit diesem:
>
> $attributes = array(
> 'class' => 'ln',
> 'onclick' => 'whatever()',
> 'href' => $l
> );
>
> xmltag('a', $attributes, $l);
>
> Ein einziger Blick auf eine der oberen Zeilen verrät dem Leser, was
> dahinter steckt. Ganz im Gegenteil zur zweiten Lösung. Es gibt keinen
Also ich finde die zweite Lösung ebenfalls selbstsprechend. Natürlich
muss man vorher wissen, was die Funktion macht. Setzt man diese häufiger
ein ist dieses Vorwissen aber gegeben und somit sollte es kein
Verständnisproblem geben.
> Dann gab es ja im Thread noch diese Möglichkeit:
>
> define('HTML_TEMPLATE_A','<a href="%s">%s</a>');
> printf(HTML_TEMPLATE_A, $l, $l);
>
> Das sieht für dieses Beispiel ganz gut aus, aber sobald sich Tags
> verschachteln (Listen, Formulare, Tabellen, ...) oder man ein neues
> Attribut (class='...') einfügen möchte, hat man schon wieder weitaus
> mehr overhead (wenn das überhaupt noch sinnvoll zu lösen ist). Ich
> verstehe nicht ganz, was daran vorbildlich sein soll - es ist alles
> andere als flexibel, was eine konsistente Verwendung unmöglich macht.
Gebe ich dir volkommen recht, diese Lösung empfinde ich auch als nicht
ideal und sehr starr. Im Prinzip benötigt man für jeden Anwendungsfall
(link mit class, link mit title usw.) eine eigene Variable und das macht
das ganze sehr komplex ohne wirkliche Vorteile.
> Eine XML-Struktur per XMLWriter zu erzeugen, ist immer noch eine gute
> Möglichkeit, vor allem weil korrektes XML erzeugt wird. Leider ist der
> XML Baum nicht auf einen Blick zu sehen.
Genau wie deine Funktion eine reines Verständnisproblem. Ein paar
Übungen mit einem XML Writer und du siehst sofort was da gemacht wird.
> Bei der Verwendung von Templates hat man auf jeden Fall volle
> Flexibilität (was den XML Code angeht) und selbstbeschreibenden Code
> (das XML Dokument liegt direkt vor der Nase, alles andere findet sich
> Programm-Quelltext). Ohne Frage haben Templates auch ihre Nachteile,
> aber darum geht es hier nicht.
>
> Insofern hängt eine gute Lösung immer vom Anwendungsfall ab, und der
> kann Templates, XMLWriter oder Standardausgaben (echo, printf)
> nahelegen. xHTML ist sehr intuitiv und auch halbwegs übersichtlich,
> deshalb rechtfertigen nur echte Vorteile ein
> "Programmiersprachen-Wrapping".
Da hast natürlich recht, wobei ich wohl nur die Alternativen print und
XML Writer in Erwägung ziehen würde. Ersteres ist sehr schnell gemacht
für sehr kleiner Projekte. Letzteres bietet unheimlich viel Möglichkeiten.
XML Writer:
Per boolean kannst (bei mir jetzt mein ich) bestimmen, ob die Ausgabe
mit oder ohne Formatierung willst (also lesbar oder sehr platzsparend
und schnell übertragbar) und alle Übergaben kannst per "htmlentities"
absichern. Außerdem kannst einer Methode einfach ein XML Knoten geben
zum Anhängen dessen Inhaltes und brauchst dich weder um korrekte Syntax
noch um korrekte Verschachtelung zu kümmern (nur die Semantische
Korrektheit musst selbst schauen).
Dafür ist es allerdings etwas langsamer von der Performance her und auch
gewöhnungsbedürftig von der Verwendung.
Christoph Herrmann
> $attributes = array(
> 'class' => 'ln',
> 'onclick' => 'whatever()',
> 'href' => $l
> );
>
> xmltag('a', $attributes, $l);
aso, habe die Möglichkeit bei mir eingebaut, von daher unterscheidet
sich mein XML Writer nicht wirklich viel von deiner Lösung:
$xmlnode->addChild('a')->setAttributes(array('class' => 'ln',
'onclick' => 'whatever()',
'href' => $l));
Konni Scheller
> define('HTML_TEMPLATE_A','<a href="%s">%s</a>');
> printf(HTML_TEMPLATE_A, $l, $l);
>
> Das sieht für dieses Beispiel ganz gut aus, aber sobald sich Tags
> verschachteln (Listen, Formulare, Tabellen, ...) oder man ein neues
> Attribut (class='...') einfügen möchte, hat man schon wieder weitaus
> mehr overhead (wenn das überhaupt noch sinnvoll zu lösen ist). Ich
> verstehe nicht ganz, was daran vorbildlich sein soll - es ist alles
> andere als flexibel, was eine konsistente Verwendung unmöglich macht.
Es kommt eben ganz darauf an. Ich wollte hier auch ein "kleines"
Beispiel bringen und nicht erzählen, dass ich für so etwas schon ganze
Klassen schreibe, die von einer Rendererklasse abgeleitet sind.
Der Anwendungsfall "klickbare Adressenliste erzeugen" würde schon wieder
ganz andere übergabemechanismen nahelegen.
Das ist ein generelles Problem bei der Erzeugung wiederverwendbaren
Codes.
> Eine XML-Struktur per XMLWriter zu erzeugen, ist immer noch eine gute
> Möglichkeit, vor allem weil korrektes XML erzeugt wird. Leider ist der
> XML Baum nicht auf einen Blick zu sehen.
Und das ist ein klassisches Beispiel einer übergeneralisierten Lösung:
es wird so viel generalisiert, dass es in der Form nichts gewinnt.
steffen bruentjen
>steffen bruentjen schrieb:
>> $attributes = array(
>> 'class' => 'ln',
>> 'onclick' => 'whatever()',
>> 'href' => $l
>> );
>>
>> xmltag('a', $attributes, $l);
>>
>> Ein einziger Blick auf eine der oberen Zeilen verrät dem Leser, was
>> dahinter steckt. Ganz im Gegenteil zur zweiten Lösung. Es gibt keinen
>
>Also ich finde die zweite Lösung ebenfalls selbstsprechend. Natürlich
>muss man vorher wissen, was die Funktion macht. Setzt man diese häufiger
>ein ist dieses Vorwissen aber gegeben und somit sollte es kein
>Verständnisproblem geben.
Wenn man, wie Du, den DOM-Ansatz wählt, müssen die Attribute in
strukturierter Form übergeben werden. Dieser ist es zu verdanken, dass
gültiges XML rauskommt und man sich keine Sorgen über die
well-formedness machen muss. Eine Wrapper-Klasse zur Vereinfachung ist
natürlich vollkommen ok - so muss man nicht alle Attribute einzeln
über $element->setAttribute($name, $value) übergeben, sondern kann das
bequem mit einem assoziativen Array machen.
Der Autor von xmltag() hat allerdings eine solche Funktion
geschrieben:
function xmltag($tagname, $attributes)
{
$str = '';
foreach ($attributes as $key => $val)
{
$str .= " $key='$val'";
}
return "<$tagname$str>";
}
mit
echo xmltag('a', $attributes) . "Link-Text</a>";
Hier ist es meiner Meinung nach nur überflüssige Strukturierung an der
falschen Stelle.
>> Eine XML-Struktur per XMLWriter zu erzeugen, ist immer noch eine gute
>> Möglichkeit, vor allem weil korrektes XML erzeugt wird. Leider ist der
>> XML Baum nicht auf einen Blick zu sehen.
>Genau wie deine Funktion eine reines Verständnisproblem. Ein paar
>Übungen mit einem XML Writer und du siehst sofort was da gemacht wird.
Mag sein, dass
<buch isbn="...">
<autor>Hesse</autor>
</buch>
für Dich schlechter zu lesen ist als
$root = new DOMDocument();
$buch = $root->createElement("buch");
$autor = $root->createElement("autor");
$name = $root->createTextNode("Hesse");
$root->appendChild($buch);
$buch->setAttribute("isbn", "...");
$buch->appendChild($autor);
$autor->appendChild($name);
:)
d.h. ich glaube, ich hab Dich falsch verstanden. Ich hatte angenommen,
dass Du eine Wrapper-Klasse für ein DOM-Framework geschrieben hast, um
die Vorteile des Frameworks zu nutzen und gleichzeitig die sehr
theoretische Bedienung zu umgehen. Aber Du hast Deine eigene DOM-alike
Klasse geschrieben.
Schöne Grüße, Steffen
Christoph Herrmann
> echo xmltag('a', $attributes) . "Link-Text</a>";
>
> Hier ist es meiner Meinung nach nur überflüssige Strukturierung an der
> falschen Stelle.
Wenn nur die Hälfte des Tags über die Funktion gemacht wird finde ich es
ebenfalls unsinnig. Daher mein Einwand der halbherzigen Umsetzung.
> Mag sein, dass
>
> <buch isbn="...">
> <autor>Hesse</autor>
> </buch>
>
> für Dich schlechter zu lesen ist als
>
> $root = new DOMDocument();
> $buch = $root->createElement("buch");
> $autor = $root->createElement("autor");
> $name = $root->createTextNode("Hesse");
> $root->appendChild($buch);
> $buch->setAttribute("isbn", "...");
> $buch->appendChild($autor);
> $autor->appendChild($name);
>
> :)
Deswegen mag ich DOM nicht, weil es mir etwas zu komplex von der
Bedienung her ist. :)
Vielleicht gefällt dir mein Ansatz ja besser ^^:
$xml = new XmlDocument('buch');
$xml->setAttribute('isbn', '')->addChild('autor')->setValue('Hesse');
> d.h. ich glaube, ich hab Dich falsch verstanden. Ich hatte angenommen,
> dass Du eine Wrapper-Klasse für ein DOM-Framework geschrieben hast, um
> die Vorteile des Frameworks zu nutzen und gleichzeitig die sehr
> theoretische Bedienung zu umgehen. Aber Du hast Deine eigene DOM-alike
> Klasse geschrieben.
Stimmt. Ich hab einen XML Writer komplett selbst aufgebaut um alle meine
Anforderungen (abschaltbares htmlentities zum Beispiel und die sehr
einfache Bedienung) zu besitzen. Und es gibt einen Parser auf Basis von
SimpleXML, der geschriebenes XML in meine Klassenstruktur überführt.
Christoph Herrmann
> steffen bruentjen <dev...@steffen.bruentjen.de> wrote:
>> Eine XML-Struktur per XMLWriter zu erzeugen, ist immer noch eine gute
>> Möglichkeit, vor allem weil korrektes XML erzeugt wird. Leider ist der
>> XML Baum nicht auf einen Blick zu sehen.
>
> Und das ist ein klassisches Beispiel einer übergeneralisierten Lösung:
> es wird so viel generalisiert, dass es in der Form nichts gewinnt.
Also für mich persönlich erschlägt ein XML Writer mit seinen Vorteilen
alle anderen Lösungen. Was du unter einer übergeneralisierten Lösung
verstehst weiß ich nicht, aber bisher sind mir keine für mich relevanten
Nachteile bekannt.
Felix Alter
Claus Reibenstein schrieb:
> Und ich würde es so machen:
>
> echo "<a href='$adresse'>$adresse</a>";
>
Ich nicht.
<a href='http://so.und.so'> ist nämlich falsch.
Christoph Herrmann
und was willst du uns damit nun sagen? Völlig sinnfrei der Beitrag würde
ich behaupten. Falls du daraus anspielen willst, dass die Adresse nicht
geprüft wird, dann sag das einfach.
PS: Eine Validierung würde ich bei der Eingabe einer Adresse vom
Benutzer machen und nicht bei deren Ausgabe, daher an der Stelle völlig
irrelevant.