Bonsoir à tous,

Je trouve beaucoup plus pratique d'écrire "<?" et "<?=", plutôt que "<?php" et "<?php echo"...

il y a des gens qui disent de ne pas utiliser "<?" à cause des documents xhtml qui commencent par <?xml version="1.0" encoding="utf-8"?>

Je ne sais pas si c'est uniquement pour ça, mais si c'est le cas c'est vraiment pas un problème vu qu'il est possible de faire ça :
<?='<'?>?xml version="1.0" encoding="utf-8"?>

Donc voila je voudrais savoir ce que vous en pensez afin de pouvoir trancher définitivement cette question ...

Hello,

pour moi :
- le "<?" t'empêche d'avoir un code portable (certains hébergeurs le bloquent)
- cette syntaxe n'est pas forcément claire
- elle pose des problèmes pour la manipulation des fichiers XML (dont xhtml comme tu l'as souligné)
- vu que de toutes façons on évite les mélanges PHP/HTML, ce "raccourci" ne sert plus à rien

Voilou Pour moi c'est ce raccourci est une "Fausse Bonne Idée", je ne m'en sers plus depuis de nombreuses années et le déconseille à mes clients.

Oui je suis d'accord, mais bon...

On peut bloquer les "<?" via le php.ini avec short_open_tag, par défaut wamp le met à off, d'ailleurs je trouve ça un peu totalitaire...
Enfin il suffit de le mettre a "on" ou, au pire il suffit de passer un script pour remettre en "<?php" pour les hébergeurs qui posent problèmes, ou alors de les éviter, en tous cas ceux que j'utilise n'ont pas posé de problème à ce niveau.

Ce ne sont pas non plus les rares fois ou j'utilise un fichier XML qui pourraient justifier un tel alourdissement de mon code.
En terme de comparaison, c'est comme si je décidais de me crever les yeux pour éviter de devenir aveugle en regardant une éclipse.

Sinon je ne trouve pas que cette syntaxe manque de clarté... surtout que personnellement je trouve ça plus lourd et donc moins clair avec les "<?php"...


C'est vrai qu'éviter au maximum les mélanges HTML/PHP permet en quelques sortes de contourner le problème...


Enfin je trouve quand même dommage de devoir totalement se priver pour quelques raisons qui ne sont pas si primordiales à mes yeux...

Dans la doc de php :



Si tu te moques la portabilité de ton appli, pourquoi pas, et encore, je me souviens des applis en .php3 qu'il a fallu nettoyer pour pouvoir être hébergé sur des serveurs php4, quel merdier c'était.

Coté "alourdissement" je suppose que tu mets toujours le tag '?>' à la fin de tes scripts non ? Et bien je vais te faire un petit cadeau : enlève ce tag de fin, qui a plus de chances de te causer des soucis qu'autre chose (retour chariot en trop...), et utilise ces quelques octets gagnés pour ajouter le "php" en début de script.

Je ne sais pas comment tu structures ton code, mais s'il te semble plus clair avec une floppée de short tags, tu me fais un peu peur.

Edit : je poserais même la question à l'envers : vu les problèmes que soulève cette syntaxe face à l'énorme gain de quelques octets, à quoi bon risquer les ennuis ?

salut,

- vous pouvez créer un raccourci clavier dans votre éditeur pour <?php echo ?>
- d'où vient cette manie de ne pas coder le ?> fermant ?
Dans un soucis de qualité de code, portabilité, il vaut mieux prendre les bonnes habitudes.

Dernier point important :
dans les frameworks, il y a un mélange XHTML / PHP. On ne contourne donc pas le problème

Bonjour,

je ne suis pas sûr que ce code marche :

par contre j'utilises celui ci qui ne me pose aucun problème :


Pour l'histoire du 'mélange php/html', ca vient des personnes qui font des sites sous dreamweaver, et qui sont obligés d'y ajouter du php, et au lieu de tout transformer en php, se contentent d'ouvrir/fermer des balises php.

Pour ce qui est de la balise php fermante, je ne la mets plus depuis pas mal de temps, et.. ca m'arrive de l'enlever quand je la vois
La raison ?
T'as pas à te soucier de la fin du fichier, tu sais comment il se termine
> Si tu fais un fichier config php auquel tu es amené à ajouter des paramètres, par exemple, no soucis, tu les ajoutes. Sinon ? T'es obligé de recopier le fichier dans une variable, de le réécrire dans le fichier, 'sauf la dernière ligne', d'y ajouter ton code, et... d'ajouter la dernière ligne

Dans un cas tu ajoutes, dans l'autre tu.. perds du temps (bon, à mon avis..)

Et comme dit Kioob, j'ai moins de problèmes de 'header non envoyés', vu que ce fichier (ou les autres) n'a pas une ligne de trop, tout en bas.

Par contre, je mets indifféremment <? ou <?php, mais j'ai toujours pareil dans un même projet. Si je récup. un truc en <? je continue en <? Si je récup. un truc en <?php je continue idem.
Et pour finir, le premier (et en général le seul du fichier), je le mets toujours sur une ligne séparée.
Ca n'alourdis pas le code

Par contre, le code php est parsé, donc : aussi lourd à executer, d'une manière ou d'une autre.. (et.. c'est pas les quelques centièmes de micro-secondes gagnées qui vont changer grand chose..

Ben non justement j'utiliserais

justement, en utilisant ca, ca va planter lorsque tu vas t'en servir sur un serveur avec les shortopentag sur on.
portabilité

Arf, je l'avais pas pensé dans ce sens

Il me semble en plus que cela va disparaitre dans PHP 6.

Il ne restera que cette syntaxe : <?php=$variable?> et celle-ci disparaitra : <?=$variable?>

(j'ai perdu le lien qui en parlait, donc à vérifier)

PHP 6 se débarassant de beaucoup de "fausses bonnes idées" héritées des versions précédentes, ça ne m'étonnerait pas oui.

Bonjour,

<? et <?= ne vont pas être supprimé en Php6 et <?php= ne va pas être ajouté à la place

Source http://www.php.net/~derick/meeting-notes.html :

Personnellement j'utilise <?= précisément pour séparer le code de la présentation html en créant
des templates mais j'écris ces templates en php plutôt qu'avec le langage spécifique d'un moteur de template
(comme je vois de plus en plus de gens le faire d'ailleurs)

Par exemple:

me convient autant que:

ça ne me dérangerais pas de le remplacer par <?php=$login?>
par contre pour l'instant <?php echo $login?> je trouve que ça moche dans mes templates...
c'est juste une question de gouts quoi...

Sinon jusque la je suis encore jamais tombé sur un serveur qui refuse les short tags mais en prévision comme le dit Keyser
j'ai un script tout simple qui utilise les tokens et qui est donc 100% safe qui remplace tout les <?
dans tout mes fichiers php en 30 secondes si jamais le problème se posait.
(Si ça intéresse quelqu'un je peux le rechercher et le poster ici)

De plus j'imagine que les hébergements php qui ne permettent pas de choisir si on veut des short_open_tags à on ou à off
sont des mutualisés sur lesquels on a pas non plus d'optimisateur php et il serait donc utile d'au moins retirer les espaces, retours à ligne et commentaires (qui sont inutiles en production) avant d'uploader. La encore ça ce fait très facilement avec les tokens et on peut donc au passage remplacer aussi les <? par <?php si besoin est.

Ma conclusion ("personnelle"): je vois pas encore de raison de changer, si je devais le faire sur tout mes programmes ça me prendrait 30 secondes avec un script que j'ai déja alors peut être au niveau xml, la aussi j'ai pas encore rencontré de problème mais c'est vrai que mon expérience avec le xml en php n'est pas extensive.

Il serait sans doute intéressant d'approfondir ce dernier point, qu'est-ce qui pose tellement de problème en xml? Est ce vraiment si incontournable? ou est-ce la encore plutôt une question d'approche de chacun?


J.D.

Bonsoir,

détrompe toi justement, j'ai au moins rencontré l'hébergeur "réagi" dont le short open tags est/était désactivé pour PHP 5 (et ils utilisent APC pour info).

Pour ce qui est de l'équivalent templates / PHP, le soucis c'est que le code exact correspondant à une {login} est <?php echo htmlspecialchars( $login ) ?>
Voir même selon les moteurs : <?php echo html_entities( $this->login ) ?>
Ce qui apporte (selon moi) une solide couche sécuritaire en plus.



Edit : pour le point génant avec le XML, ne serait ce que pour du XHTML on a ces entêtes à placer ; ce qui en l'état provoque un "parse error". On est donc obligés d'utiliser PHP pour afficher ces tags, ce qui ne me semble pas très élégant.

Salut Kioob,

Merci pour ta réponse, donc effectivement dans le cas de "réagi" ce n'est pas comme je disais, mais par contre faire des htmlspecialchars ou un html_entities sur toutes les données à afficher alors que la plupart n'en ont pas besoin c'est un peu prendre un canon pour tuer une mouche, je pense à un prix, un login (souvent), une date, le nom d'un fichier (image par exemple), un numéro de téléphone ... les exemple sont nombreux. Moi je fais ça que sur les données sur lesquelles c'est nécessaire. Alors biensur on va me dire oui mais il y a un système de cache, je suis d'accord mais un système de cache c'est du temps encore de passé alors que la page n'en aurait peut être pas eu besoin sinon, en plus ça ne se prête pas à tout.

Jusque la donc je suis pas encore convaincu de changer d'approche.

Pour le xml sinon est-ce qu'il n'y a que avec ces balises de départ que ce n'est pas très élégant? Parce que du coup on parle même plus de problème la mais d'élégance concernant 8 caractères <?='<'?> toujours placé au même endroit. La aussi je crois que je peux vivre avec si ce n'est que ça.

Biensûr <?php= ce serait pas mal parce que ça permettrait de mettre tout le monde d'accord tout en laissant chacun libre mais bon apparemment ça va pas arriver....

C'est ton choix, mais pour ma part mon serveur interdit les short tags et je ne m'en porte que mieux, sur ce dernier utilisant des webservices, moi ça m'aurait fait "chier" d'écrire pour tous mes flux xml :



plutôt que tel que c'est actuellement :

Oui le htmlspecialchars / htmlentities est souvent fait "inutilement", mais il est là en temps que sécurité justement : le fait de limiter l'accès uniquement aux méthodes et propriétés de l'objet ceci cumulé à l'échappement quasi systématique procure à mon sens un solide niveau de sécurité. Alors oui ça a un coût en terme de performances, mais pour moi c'est comme les "mysql_real_escape_string" : je préfère ne pas prendre de risque et être certain d'écarter cette possibilité.
Tout ceci sans oublier les autres avantages d'un système de template, comme par exemple la compilation "statique" : même si la page utilise une dizaine de template, le code PHP généré est contenu dans un seul script, ce qui réduit "dramatiquement" le nombre d'include final. Au encore la génération d'etag : toutes les données affichées étant disponibles depuis le contexte de l'objet "template", il est très facile de générer un ETag avant l'affichage de la page... et donc de gérer le cache http de manière transparente et sans risque d'erreur.
Au final, tous les petits plus de ce genre offrent une navigation plus rapide à l'internaute, une sécurité fortement accrue, et une facilité de maintenance exemplaire. Pour ma part, j'aurais beaucoup de mal à me passer de mon moteur de template.

Mais bon.... je m'écarte un peu beaucoup du sujet ; tout ceci était pour dire que le {login} dans un moteur de template ne faisait pas "que" correspondre à un <?php echo $login ?> ; loin de là. Après il y a des moteurs de template qui acceptent la syntaxe PHP mais la modifient eux même.

Pour le XHTML je ne sais pas exactement, en tout il y a peu de chance d'avoir plus d'une dizaine de balises de ce genre en tous cas. J'en ai régulièrement 4 pour ma part. Et pour le XML de manière générale, j'en sais encore moins... il faudrait regarder du coté de la spec.

Pour le "<?php=" je ne serais pas d'accord non plus C'est là aussi le genre de raccourcis qui n'apportent rien au code selon moi, sinon d'en rendre la syntaxe encore un peu plus complexe à lire.

Je comprends très bien Dadou qu'on puisse ne pas aimer écrire ça

et je comprend aussi Kioob qu'on soit attaché au fonctionnalités très avancées de son moteur de template.

Moi personnellement je suis plus attaché à l'inverse pouvoir utiliser peu de librairie et faire un code
très light quand le projet le permet, rapide et fiable parce que j'ai moi même pris soin qu'il le soit.
J'ai toujours réussit à faire ce que je souhaitais et à faire tourner mon code où je voulais.

Par contre on s'éloigne effectivement un peu de la question de Keyser qui je crois voulais savoir
si il risquait de se trouver bloqué si il utilise ça <? ou ça <?= puisque comme moi il semble le préférer...

Par rapport à ce qui a été dit jusque ici je pense qu'on ne peut pas dire qu'il risque de se retrouver bloqué
puisque chacun des problèmes cités trouve apparemment une solution simple qui même dans le pire des
cas (serveur n'acceptant pas les short tags) ne demande pas des heures pour y rémédier.

Moi même je suis venu répondre à ce post parce qu'à la vue du nombre de personnes déconseillant d'utiliser
les short tags j'ai voulu savoir si à un moment donné on se retrouve bloqué en les utilisant.

Je suis pas borné si on me montre qu'il y a certains problèmes insolubles j'arrêterais aussi mais pour
l'instant ce n'est pas le cas.

Si en fait de compte on lui a bien répondu : en utilisant <? au lieu de <?php il risque que son site ne fonctionne plus (changement d'hebergeur, mise à jour, une config du serveur qui sautre... ) et devra se taper toutes les corrections pour le mettre en place. Quand tu prends la syntaxe préconisé, tu t'évites un risque d'erreur.

Sans oublier le coté "sécurité" : l'hébergeur met à jour sa version de PHP et vire le short open tags par mégarde => hop, tous les codes sources du site sont téléchargeables à cause de 3 petits caractères négligés.


Note : pour continuer dans le HS, un code "light" ne sera pas forcément plus rapide. Déjà une page qui ne gère pas les réponses 304 aura de très grandes chances d'être beaucoup plus lente d'accès à l'internaute. De même que l'utilisation de CSS / JS non versionnés impose des requêtes inutiles au navigateur.

C'est un peu le même principe que le cache de requete MySQL : il ralenti de 5% les requetes, mais dans 90% des cas il évite complètement l'exécution de la requête.

A oui pensons aussi au cas de l'hébergeur qui oublie carrément d'installer php

non je blague mais bon peut être qu'effectivement ça peut arriver mais si on part dans cette voie la il y a beaucoup de choses très néfastes qui peuvent arriver et qui n'implique même plus les short tags. en tout cas super la qualité de l'hébergeur qui vérifie même pas sa mise à jour avant de l'effectuer sur tout ses serveurs ... donnez moi l'adresse je fonce prendre un abo chez eux.

sinon Dadou je me fatigue pas à ressortir mon histoire de script (qui n'intéresse personne) qui modifie tout ça tout seul si jamais je changes d'hébergeur... je suis déjà effrayé à l'idée que ça m'arrive un jour ... tout ces ptits 'php' et 'php echo' que je vais devoir fastidieusement rechercher à la main dans tout mes codes pour les remplacer, ha je vais gallèrer la dessus c'est certain.

Note: je remets pas en question l'utilisation de system de cache et puis il y a pas qu'avec des templates qu'on peut avoir un système cache et puis c'est vraiment le sujet.


bon allé j'arrête de vous embêter merci en tout cas


<?php echo htmlspecialchars(htmlentities('Salut ')); ?>



PS: Attention les enfants rappelez vous bien les short tags c'est péché et si vous les utilisez on vous brulera avec les sorcières sur le buché

pff!! Ça arrive beaucoup plus souvent que tu ne sembles le croire.



Es tu sûr qu'il fonctionne sur tout tes scripts? qu'il ne te modifie pas des parties qu'il n'aurait pas du, ou qu'il n'en oublie pas?? je parle par expérience, j'ai déjà eu à convertir un projet comme cela, et bien cela à été loin d'être une partie de plaisir




Qu'on m'apporte les allumettes

Ben écoutes test, je viens de la réécrire parce qu'elle était inclue dans mon optimizateur qui fait aussi d'autres opérations que ça sur le code et que j'utilise tout le temps et il ne m'a jamais posé problème. token_get_all utilise le moteur de php pour parser le code donc normalement c'est quand même ce qu'il y a de plus fiable

J'ai également été confronté plusieurs fois à ce cas de figure et ça ne m'a jamais posé problème, un rechercher/remplacer dans plsrs fichiers... sinon il y a le code proposé par Dimalta.


J'aurais bien aimé mais malheureusement cette syntaxe ne fonctionne pas, il faut bien écrire : <?php echo $variable?>




LOL

Oui en fait, on s'éloigne du sujet, à la base, je demandais juste s'il y avait un risque sérieux dont j'ignorais la connaissance pour utiliser les short tags...

Il en ressort comme arguments :

- La portabilité: je connaissais déjà les tenants et les aboutissants et "pour moi" c'est un problème qui se règle en 30 secondes en temps voulu et dont je peux m'accomoder.

- Le XML : On a cité des façons d'y remédier...

Donc voila ce qui m'intéresserait c'est de savoir s'il y a d'autres problèmes sérieux, comme par exemple des problèmes plus poussés avec la compatibilité XML, mais pour l'instant ce n'est pas encore le cas !

Le simple rechercher / remplacer dans plusieurs fichiers n'est pas simple, il est possible de remplacer des chaînes de caractères qu'il ne faut pas, exemple :



qui changera aussi le <? de l'echo, par contre j'avoue ne pas connaître l'usage des tokens, et ce script semble plus fiable (je viens de le tester) mais qu'en est il en terme de perf?? sur le remplacement d'un script contenant plusieurs dizaines de milliers de fichiers?

Pourquoi y aurait il des problèmes plus "poussés" ? Le seul conflit avec XML (ou autre contenu) est évidement le fait que cela empèche l'utilisation des 2 caractères '<?' .

Après c'est comme tout : si les bénéfices de cette syntaxe vous semble mériter la prise de risque qui en découle, et bien soit, continuez comme ça. On n'ira pas vous en empêcher ; et ça ne changera évidement rien pour un petit site perso.

Ce que je trouve juste dommage c'est qu'à mon sens il n'y a justement aucun bénéfice. Donc c'est s'exposer volontairement à des soucis pour rien.

Bon, il n'est pas question de faire des 'rechercher/remplacer' sur un nombre important de fichiers. Ca correspond à jeter les dés en l'air, et s'attendre à un double 6...
Pour le problème du xml, c'est un faux problème, le php est un langage interprété, alors que le xml comme le html est le langage qui en résulte.

Bon, pour avoir vérifié dans une quinzaine d'opensource différents, ils sont tous sur "<?php".
( dotclear, wordpress, oscommerce, magento, phpadsnew, sugarsales, xaraya, modx, dotproject,...)

Pour le coté 'est ce que ca craint' ? La réponse est ' tout dépend si le problème de portabilité est un problème pour toi'

Voilà la conclusion

J'suis tout à fait d'accord quand je développe quelque chose que je dois partager avec d'autres avant de le mettre en ligne je remplace les short tags éventuels que j'aurais pu y mettre, de la même façon que je relis mes commentaires pour savoir si ils sont compréhensibles de tous. Hélas pour les commentaires j'ai pas encore trouvé de script qui les relisent automatiquement.

En tout cas merci encore pour ma part vous m'avez confirmé qu'il n'y a pas d'autres problèmes que ceux auxquels j'avais pensé à part l'éventuelle erreur de mise à jour du serveur de la part de l'hébergeur. Je suis donc rassuré vu que je passe mon code dans un optimisateur et qu'il n'a donc plus de <? ou <?= une fois en production. Pour ce qui est du code quand je développe sur ma machine je pense pouvoir me permettre malgré tout de l'écrire comme j'aime ... houuuu péché péché les flammes de l'enfer me guettent

Désolé d'avoir autant polémiqué, promis la prochaine fois j'évite les sujets à controverses

Je trouve justement très intéressant de soulever cette question, car si je puis me permettre, finalement c'est assez "anecdotique".

Nous sommes tous maintenant habitués aux normes w3c, accessibilité...
Mais dans le cadre de PHP, il est intéressant de voir les "conventions" utilisées par différents développeurs.

Les conclusions restent pourtant les mêmes :
- portabilité
- maintenance dans le temps
- partage du projet

Dans le même style :
vaut-il mieux écrire :
a+b=c;
ou
a + b = c;

ou encore pour les noms de variables :
maVariable, ma_variable...

Dans les deux derniers exemples que tu cites, il n'y a pas de souci de portabilité ni de performances serveur, juste un souci de relecture.

A ma connaissance, il n'y a pas de convention officielle, on peut éventuellement s'inspirer de celle de PEAR : http://pear.php.net/manual/fr/standards.ph...dards.indenting en n'oubliant pas :

* Utiliser des noms de variables parlants
* Utiliser des noms de variables anglophones

+1

Je trouvais ça intéressant d'en discuter en tous cas, c'est vrai que c'est un détail, mais c'est une question que je me posais tous les jours au boulot.