1. DateTime




Il est quasiment impossible dans un projet PHP un peu conséquent de ne pas avoir un jour à manipuler des dates.
La difficulté d'apprentissage peut être croissante. Au début, on souhaite uniquement afficher la date du jour au format jj/mm/AAAA ; puis, on cherche à estimer le nombre de jours entre deux dates ; enfin, on cherche à parser des dates.

Et on se rend vite compte que la fonction PHP date() ne suffit pas réellement à faire ce que l'on souhaite.



En général, la classe native \DateTime suffit à résoudre les problèmes les plus communs, je vous invite à consulter cette page-ci où je donne quelques exemples d'utilisation de celle-ci.

1.1. Limites de la classe DateTime

Le problème de la classe native \DateTime est que certains méthodes basiques ont l'air de manquer.

Par exemple, des choses pratiques comme getYear, setDay ou encore des alias du type isoFormat (équivalent au format('Y-m-d')).



Deux solutions s'offrent donc à nous :
* la première est de surcharger la classe DateTime avec de nouvelles méthodes.
* la seconde serait d'utiliser un vendor comme Chronos/Carbon/Moment qui peut répondre à des besoins plus poussés.

1.1.1 Les vendor DateTime

Beaucoup de composants PHP populaires se retrouvent sur la page Github Awesome PHP(https://github.com/ziadoz/awesome-php).
Rien ne permet d'être convaincu que ces vendors sont meilleurs que d'autres, mais leur popularité fait qu'en cas de problème, plus de monde pourra aider.

Voici la liste des vendors orientés manipulation de Date à la mi-2021 :
* CalendR - A calendar management library.
* Carbon - A simple DateTime API extension.
* Chronos - A DateTime API extension supporting both mutable and immutable date/time.
* Moment.php - Moment.js inspired PHP DateTime handler with i18n support.
* Yasumi - An library to help you calculate the dates and names of holidays.

Chronos utilise un trait nommé MagicPropertyTrait qui permet d'avoir des méthodes comme getYear / getMonth / getDay. Il utilise également le trait ModifierTrait pour ajouter des méthodes comme hour/year/month/addYear/addYears...
La méthode toDateString existe également.

Moment.php fournit également des méthodes getYear / getMonth / getDay et également des méthodes comme addDays, subtractDays. On peut également faire un ->format(Moment::NO_TIME).

Ces deux vendors sont au coude à coude concernant la popularité, à la différence que Chronos est maintenu par l'équipe derrière CakePHP, un framework assez connu, on imagine donc que les développeurs ont un peu de bouteille.

Moment est compatible dès PHP5 alors que Chronos nécessite au minimum PHP 7.2.

🧙‍♂️️Chronos l'emporte selon moi.

1.1.2 La classe surchargeant DateTime

💡️Ne pas réinventer la roue.


Il est possible de créer une classe surchargeant la classe \DateTime et de l'utiliser à travers son projet.

Il y a deux avantages certains à faire sa propre classe :
* On ne dépend pas d'un vendor et donc de ces mises à jour ;
* Le projet n'embarque pas du code inutile, on utilise assez rarement toutes les méthodes d'un vendor ;
* Le code correspond parfaitement au besoin, et fait le nécessaire ;

Il y a par contre au moins trois inconvénients :
* On perd du temps à développer et maintenir du code technique (vs code fonctionnel/métier/business) ;
* Si le projet n'est pas open source, on ne profite pas des revues de code de la communauté ;
* Il faut que les développeurs de l'équipe apprennent à utiliser la "couche maison", c'est simple quand il s'agit dun getDay, mais cela peut être plus compliqué avec une méthode qui serait nommée "processBuffstream()" : à moins d'être omniscient, il faut forcément aller voir la mécanique interne ou faire des copiers/collers de ce qui existe déjà, ou encore (dans un monde idéal) : lire la documentation faite par le développeur.

2. Twig Vs Smarty 2

Comparer SmartTPL, Smarty 2 et Twig, c'est comme comparer CVS, SVN et GIT.
On passe pour ainsi dire de l'âge de pierre à l'âge de fer. Nous ne sommes surement pas encore à l'âge d'or.

La grande plus-value du Twig par rapport à Smarty 2 est surement l'héritage entre les templates, évitant non seulement du copier coller entre les différentes pages mais surtout une souplesse bien agréable. On peut éventuellement imaginer que les feuilles de style sont importées dans un fichier dédié et éventuellement overrideraient ce fichier dans une page spéciale du site (ex: une page spéciale Halloween où la page aurait des tons oranges/noirs).

2.1. Twig vs Smarty 3

Le fossé entre Twig et Smarty 3 est moins large qu'entre Twig et Smarty 2. On peut faire globalement la même chose mais la syntaxe de Twig reste plus agréable (même si elle peut rentrer en conflit avec des frameworks JS qui utilisent les doubles moustaches).

Smarty 3 a introduit la fonctionnalité d'héritage, rattrapant son retard. Mais il ne font guère mieux que l'original en copiant jusqu'à la syntaxe :

    {block name=title}My Page Title{/block}

Prestashop est actuellement le projet le plus ambitieux utilisant Smarty, à voir dans les années qui viennent s'ils décident ou non de migrer chez la concurrence, ce qui n'est pas à exclure s'ils cherchent un jour à utiliser plus que quelques composants de Symfony 3.4.