Voici le petit dernier des plugins Symfony de chez Lexik, lxErrorLoggerPlugin, son but est simple : vous alerter en cas d’erreurs PHP ou Exceptions sur vos projets Symfony.
Le besoin est simple, être alerté et éventuellement logger chaque erreurs, qu’elles soient PHP, Exception ou erreurs remontées par Symfony. En effet le logger de base de Symfony s’arrête aux erreurs remontées par ses soins mais ne remontent pas forcément aux erreurs PHP. Le système de notification du plugin est très flexible grâce à une série de « notifier » que l’on peut activer ou non de façon indépendante les uns des autres.
Présentation du plugin lxJavascriptPlugin
L’article d’hier sur les bonnes pratiques Javascript dans un projet Symfony faisait mention d’un plugin que nous utilisons en interne et qui est maintenant disponible sur Github: lxJavascriptPlugin. Ce court article va brièvement présenter son fonctionnement et son utilisation.
Astuces de développement javascript avec symfony
Dans cet article nous allons voir quelques astuces et bonnes pratiques, non pas directement de développement symfony mais de développement javascript au sein d’un projet symfony.
Si l’on reprend quelques bases de bonnes pratiques de développement javascript, on constate :
- que vos javascripts doivent être non-intrusifs, autrement dit là pour améliorer l’expérience utilisateur et en aucun cas être indispensable au fonctionnement d’une page ;
- que les javascript doivent être combinés en 1 seul fichier et minifié (ceci afin de limiter le nombre de requête HTTP et car le chargement de la page est arrêté à chaque balise script, notamment à cause d’un éventuel
document.write();; - que l’appel au javascript doit être en bas de page ;
Cette liste est bien entendu non exhaustive, vous trouverez une liste plus détaillée par ici.
Toutes ces bonnes pratiques de développement Javascript n’ont pas toujours été facilitées dans symfony, notamment à la grande époque des helpers link_to_remote() & co. qui en ont ravi certains et fait cauchemarder d’autres. Et aujourd’hui encore bon nombre de widgets de formulaire retournent directement du code javascript (dépendant de jQuery ou autre) et qui ne fonctionneront évidemment plus dès lors que vos javascripts se trouveront en bas de page.
Utilisation de l’event dispatcher depuis les classes du modèle.
Le but de cet article n’est pas d’expliquer le fonctionnement des événements symfony, la documentation officielle est très bien faite à ce sujet, et pas mal d’articles expliquant leur implementation existent déjà.
Le but est juste de savoir comment faire pour avoir accès à l’event dispatcher depuis les classes du modèle, de manière à pouvoir lever des événements « métiers » qui permettent des traitements qui se rapprochent des trigger sql. L’avantage est de rester au sein de l’application symfony et ne pas disperser la logique. C’est une problèmatique que nous avons rencontré à plusieurs reprises dans les projets et nous avons pu trouver cette implementation grace à n1k0 de chez Akei.
Utilisation de VHost pour l’accès au backend
L’idée est de ne plus accéder au backend de notre site web en utilisant backend.php dans l’url, mais de passer par un sous domaine.
- http://www.super-website.com → frontend
- http://admin.super-website.com → backend
Supposons que mon projet Symfony se trouve dans /home/public_html/.
Commençons par ajouter un vhost pour définir le sous domaine dans Apache. On précise au sous domaine que le fichier index pour ce sous domaine sera backend.php à l’aide de la directive DirectoryIndex.
<VirtualHost *:80>
ServerName admin.super-website.fr
DocumentRoot "/home/public_html/web"
DirectoryIndex backend.php
<Directory "/home/public_html/web">
AllowOverride All
Allow from All
</Directory>
Alias /sf /home/public_html/lib/vendor/symfony/data/web/sf
<Directory "/home/public_html/lib/vendor/symfony/data/web/sf">
AllowOverride All
Allow from All
</Directory>
</VirtualHost> |
Ensuite il faut modifier le .htaccess de Symfony afin qu’il redirige les requêtes http du sous domaine vers le fichier backend.php.
Options +FollowSymLinks +ExecCGI
<IfModule mod_rewrite.c>
RewriteEngine On
# uncomment the following line, if you are having trouble
# getting no_script_name to work
#RewriteBase /
# we skip all files with .something
#RewriteCond %{REQUEST_URI} \..+$
#RewriteCond %{REQUEST_URI} !\.html$
#RewriteRule .* - [L]
# we check if the .html version is here (caching)
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
# redirect to the backend web controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP_HOST} ^admin.*
RewriteRule ^(.*)$ backend.php [QSA,L]
# no, so we redirect to our front web controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule> |
Au niveau de la config Symfony, nous pouvons maintenant masquer le nom du script dans les urls du backend:
# apps/backend/config/settings.yml
prod:
.settings:
no_script_name: true
... |
Et pour finir ne pas oublier de vider le cache =), le backend est maintenant accessible sur http://admin.super-website.com.
Qui l’eu CRUD ? Ou comment créer un thème pour les CRUD Doctrine de Symfony.
Symfony propose des outils très puissants pour faciliter le développement d’applications et surtout la génération des modules grâce à l’Admin Generator et le CRUD. Chacunes de ces solutions à ses avantages et ses inconvénients.
L’admin generator permet en une commande d’avoir un module complet et fonctionnel avec de nombreuses fonctionnalités, le tout relativement configurable. En contre partie, l’ajout de fonctionnalités spécifiques et la mise en forme peuvent rapidement s’avérer fastidieuses. Être obligé d’aller fouiller dans le cache pour aller faire des copier/coller afin de pouvoir surcharger une action, c’est comme qui dirait, bien mais pas top…
Force-download avec Symfony
Aujourd’hui, nous allons aborder quelque chose de simple et répandu sur la plupart des sites Internet de nos jours : le téléchargement de fichiers.
Bien sûr, il ne s’agit pas de permettre aux utilisateurs de télécharger votre dernier rush de photos nocturnes sous forme d’archive zip, ou encore les rapports de la dernière assemblée générale de votre association en PDF; car ceci ne nécessite en rien l’intervention de symfony.
Par contre, dès qu’une action doit être entreprise pour vérifier l’authenticité de l’utilisateur, ou ne serait-ce qu’une table de log pour savoir qui a téléchargé quel fichier, on va avoir besoin de symfony (à moins d’avoir envie de réinventer la roue).
…
