Discussion :

[Madfrix]

Bonjour,

ma question est simple : pourquoi utiliser toujours cette syntaxe dans une vue :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<?php foreach($this->variables as $variable) : ?>
...
<?php endforeach; ?>

Un simple code comme suit ne suffirait pas ?

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<?php foreach($this->variables as $variable){  ?>
...
<?php } ?>

Merci

EDIT:

Dans un tuto, j'ai vu cela mais je ne comprends toujours pas pourquoi

Une boucle classique foreach: est utilisée pour parcourir la liste des albums, et nous utilisons la syntaxe alternative avec deux points et endforeach; car elle est plus simple à lire que d'essayer de faire correspondre des accolades.

[pandrogynik]

Le seul avantage que j'y vois (je ne l'utilise pas pour autant), c'est que dans un code un peu long ou chargé, on identifie plus facilement las fins de blocs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php endforeach; ?>

est moins anonyme que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php } ?>

Mais bon, comme toute syntaxe "alternative", ça reste une question de préférences propre à chaque individu.

[Madfrix]

Ok, merci

je vois cette syntaxe dans tous les tutos ou presque alors je pensais que c'était presque une syntaxe obligatoire sinon conseillée.

De même, j'ai vu que la balise fermante php (?>) n'est jamais utilisée et j'ai vu qu'il ne faut pas la mettre, donc je ne la mets pas mais je vois pas vraiment pourquoi...

[patbator]

Hello,

Pour le coup de la balise fermante php l'explication est assez subtile pour des gens qui n'auraient jamais utilisé l'output buffuring à la mano

En résumé, lorsque le parser lit un fichier php, il s'attend à ce que le code php soit mixé dans du texte qu'il doit ignorer (typiquement du html).

Normalement, pour améliorer le temps de réponse php commence à renvoyer le html au navigateur dès qu'il rencontre du texte hors des balises php (c'est l'output).

Ça peut devenir un problème car l'envoi du 1er caractère de la réponse enclenche aussi l'envoi des entêtes de réponse HTTP (type du fichier, date de modif, etc).

À la grande époque, on devait faire la chasse aux caractères en dehors des balises php pour ne pas déclencher l'envoi des entêtes, le truc marrant c'est que n'importe quel caractère suffit même un espace ou un retour à la ligne.

Donc pour être sur de son coup on en est venu à dire que pour les fichiers ne contenant que du php on doit commencer par la balise ouvrante php et ne pas mettre la balise fermante pour ne pas prendre le risque de mettre un caractère après.
Le moteur php travail par fichier et recherche la balise fermante ou la fin de fichier.

Désormais les codes actuels ont tendance à se baser sur l'activation de l'output buffuring qui met la sortie dans une mémoire tampon jusqu'à la fin du script ou jusqu'à une commande explicite d'envoi de la réponse.
Le soucis d'envoi prématuré de la réponse ne risque plus d'intervenir qu'avant le 1er appel à ob_start() mais reste toujours présent.

[pandrogynik]

Les caractères intempestifs après les balises fermantes peuvent avoir d'autres conséquences dans le cas où le flux de sortie demande un soin particulier au niveau du format. Exemple : les services web, qui renvoient du XML.

J'en ai bavé au début avec mes services web, mes tests client renvoyaient "looks like we got No XML" où quelque chose dans ce goût là. Ceci provenait de sauts de lignes intempestifs ajoutés en début de réponse par des inclusions de classes dont les fichiers présentaient des sauts de ligne après la balise fermante.

[patbator]

Ça peut aussi empêcher d'initialiser une session, faire une redirection, etc…

Mais ta remarque sur les formats est très juste, imagine le résultat avec une url qui génère une image