Non, smarty ne permet pas de caler du php dedans ... ! Je déteste smarty !

Oui, oui, séparation controller et vue, oui, mais dans certains cas c'est pas fait tout à fait comme ça (coucou ma personnalisation sur une base de piwigo), et j'ai juste haï les contraintes ubuesques et la syntaxe imbitable de smarty quand j'avais les mains dedans. Bon, après, je ne sais pas la version de smarty qu'utilise piwigo et de quand date le système (probablement d'a long time ago), mais c'était juste chiant et ressemblant à une bataille contre des moulins à vents quand je m'y suis frotté.

En ce moment, je suis sur un projet laravel, je découvre le framework ce faisant, et le système de template (blade) est quand même un (gros) cran au dessus ... et bien plus lisible je pense même pour un non-dev' qui devrai modifier le template.

TchouNon, smarty ne permet pas de caler du php dedans ... ! Je déteste smarty !

J'ai une maigre expérience, mais je le trouve assez "agréable" à utiliser.

Côté code PHP, tu écris :

$smarty->assign('membre', $membre);
$smarty->assign('membres, $liste_membres);

Et côté HTML (enfin donc code Smarty Template), tu écris :

<a href="edit.php?id={$membre->id}">{$membre->nom} {$membre->prenom}</a>

<table>
  {foreach var=membres item=un_membre}
    <tr class="{if $un_membre@index is even}even{else}odd{/if}">
      <td>{$un_membre->nom}</td>
      <td>{$un_membre->prenom}</td>
    </tr>
  {/foreach}
</table>

La syntaxe est proche du code PHP et rend la chose assez lisible et compréhensible.

Alors, oui, là ça reste lisible.

Quand ça commence à faire des if imbriqués, avec des strip, des rdelim, des conditions avec 3-4 and ou or, des ... bah là tu dis "stop" et tu adorerai pouvoir faire du good old php. Là encore, je ne parle que de mon expérience à faire un nouveau template sans toucher à l'appli piwigo. c'est probablement elle qui est mal goupillé et fout beaucoup trop d'intelligence dans son template, mais c'est juste à s'ouvrir les veines.

Ne me dis pas qu'un truc comme ça c'est lisible (dans les premiers résultats sur github). Surtout, vas plus loin que le début et vas lire le js imbriqué, c'est à s'arracher les cheveux. S'il faut apprendre un nouveau langage abscons (rdelim ? wtf ? strip ? merde, ça sert à quoi) ET devoir connaitre le php en même temps (mais que fais un !isset ?), à quoi ça sert d'avoir un langage de templating ?

Bon, encore une fois, je ne parle que de mon expérience biaisée liée à une appli bien spécifique et qui a 10 ans de développement petit à petit derrière elle. Bien sûr un smarty sur du dev' récent sera propre, mais ...

Bon, nouvel épisode de Galette. Le dèv principal veut basculer sur Slim.
Bonne idée ou pas ?
De toutes façons il faudra tout reécrire, autant basculer sur Symphony ? Sur du Ruby ? Du Python ? Du Node.js ?
Ou si on peut rester sur du PHP, que choisir pour avoir du propre URL-rewriting ?
Moi j'y connais que piche, donc je suis incapable de dire noir, blanc, gris, vert, rose, jaune.

Python ?

L'url rewriting, c'est le serveur (apache, nginx, lighthttpd, iis, ...), pas PHP ou un autre. À moins que tu ne parle de routing, qui effectivement n'est pas possible de base (mais avec un framework de plus en plus).

Après : tout dépend :
- quelle est l'appli ?
- sa scalabilité ?
- son public ?
- son besoin en vitesse (performances) ?
- son besoin en features ?
etc etc etc ...

Toutes les solutions sont spécialisées (ou pas) dans un domaine. Si tu veux un serveur qui balance à fond la caisse une data simple même totalement surchargé, c'est pas la même chose que l'usine à gaz qui est capable de tout faire mais qui charge tout son framework à chaque page. Y'a pas de solution simple à ta question, affirmer UNE solution universelle, c'est au choix un troll ou une religion.

Au delà des trolls de langages/framework, faut se méfier à mon avis des micro-framework. Ce genre de choix est souvent dicté par le manque d'envie d'apprendre un framework "full-stack".

On peut aussi souhaiter être "libre" de gérer sa configuration ou l'organisation de son code, néanmoins il faut s'imposer une grande rigueur à long terme pour maintenir du code métier un minimum évolué quand rien n'est imposé par l'outil.

La seule bonne raison que je puisse envisager, c'est de vouloir "cherry-picker" les composants individuels de configuration, persistance, templating, routing, injection de déps, etc..., plutôt que d'opter pour ceux pré-configurés dans un full-stack. C'est respectable, n'empêche que c'est du boulot technique supplémentaire, il faut pouvoir l'assumer.

Ne pas oublier aussi qu'en dehors d'injection de dépendances, point de salut. Utilisez donc Pimple ou, si vous êtes des jeunes dans votre tête, PHP-DI (je veux bien un retour sur ce dernier).

Les fonctionnalités de routing/scalabilité/perfs/whatever sont généralement accessibles quel que soit le framework, le critère principal pour moi devrait rester la maintenabilité et la pérennité.

La dernière fois que j'ai fait du PHP, c'était avec du CakePhp et c'était plutôt pas mal sauf la partie configuration Apache assez pénible à modifier entre ce qui marchait pour Windows ou pour Linux.

A froid, je serai intéressé par Laravel ou Slim, parce que tous les 2 mettent l'accent sur l'importance de l'interface entre la partie back office et front office. En Laravel tu fais une appli REST et donc ça incite à développer l'archi de son appli sous forme de service (métier) accessible via une URI, ce qui est une très bonne pratique. Slim met aussi en avant l'aspect routage avant toute chose, ce qui se rapproche un peu de ce genre d'architecture. Dans mes rêves les plus fous, je ferai du Backbone pour la partie front et du Laravel partie back.

Pour développer regarde aussi Vagrant qui permet d'avoir une VM sur son poste et mettre n'importe quelle dépendance sur sa VM plutôt que pourrir son poste. De cette manière, on est quasiment iso prod en local ce qui est plutôt cool car les problèmes chiants ce sont souvent les différences entre poste de dev et serveur de prod. Il y a quelques vidéos de grafikart qui permettent de voir à quoi ressemble vagrant, slim, laravel...

En passant, pour ma culture : je vois de plus en plus de code php où ils n'y a pas la balise de fin de php. C'est censé être une bonne pratique?

Oui, c'est une bonne pratique de pas intégrer la balise de fin en fin de fichier. De cette manière, pas de risque d'ajout de caractères additionnels qui peuvent être bloquants dans certains cas (par exemple si pour une procédure tu dois modifier les headers).

backbone et laravel semblent bien se marier. J'ai fait un peu de laravel récemment, effectivement je suis à un doigt de basculer le front-end en single-page js ! :)

J'utilise pas vagrant (j'utilise un serveur de test dédié pour moi tout seul, au plus près des specs du serveur de prod, et je monte mon répertoire de travail via sshfs sur ma machine), mais effectivement ça a l'air hyper simple à mettre en place. https://serversforhackers.com/editions/2014/02/25/vagrant-apache/ a une bonne explication je trouve.

pomEn passant, pour ma culture : je vois de plus en plus de code php où ils n'y a pas la balise de fin de php. C'est censé être une bonne pratique?

Oui !

Merci, je comprends mieux! (surtout grâce à l'explication de Fabe ;))

Vagrant c'est l'idée d'apporter la virtualisation au développeur. Tu es webmaster, tu travailles sur 10 projets pour des clients différents qui ont chacun des OS et des technos différentes et tu peux tout gérer en faisant des simples vagrant up. De surcroît, tu peux sauvegarder la personnalisation de ton socle dans le vagrantfile, comme ça un autre développeur pourra avoir exactement le même environnement.

Un jour faudra que je pense à en parler dans mon projet ;) car on teste dans Eclipse (Windows) qui lance un tomcat et c'est tellement éloigné de ce qui va se passer au final (sur Centos) qu'on a vraiment des conf et des perfs incohérentes. Mais il est important de préserver sa dette technologique, ça donne du boulot ;)