Différence entre assetic: dump et assets: install
Dans Symfony2, quelle est la différence entre assetic:dump et assets:install? Dans quels scénarios utiliser chacune de ces commandes et dans quel ordre (si l'ordre est pertinent)?
En fait, j'ai écrit à ce sujet récemment dans un article sur OroCRM, qui est basé sur Symfony 2. Si vous voulez une partie du contexte/pourquoi des différentes commandes, vous pourriez trouver cela intéressant.
Il existe deux systèmes différents pour inclure des fichiers frontaux (javascript, css, images, etc.) dans une application Symfony. La commande assets:install Est arrivée en premier. Cette commande recherchera tous les Bundles Symfony dans une application pour
Resources/public
dossier. Si elle est trouvée, la commande assets:install Copiera ou liera des fichiers symboliques de Resources/public Vers web/public/bundle/[bundle-name]. C'est là que les liens créés avec la fonction twig assets rechercheront ces fichiers.
<script src="{{ asset('js/script.js') }}" type="text/javascript"></script>
Devient cela
<script src="/bundles/[bundle-name]/js/script.js" type="text/javascript"></script>
C'est tout ce que fait le système assets. Il vous permet de stocker vos fichiers frontaux avec le bundle.
Le système assetic est différent. Avec assetic, vous créez un lien vers des fichiers comme celui-ci.
{% javascripts '@AcmeFooBundle/Resources/public/js/foo.js' %}
<script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}
Il existe des balises similaires pour les feuilles de style et les images. Notez que assetic vous permet de créer des liens vers des fichiers dans n'importe quel paquet. (@AcmeFooBundle). Assetic vous permettra également de créer un lien vers plusieurs fichiers dans un dossier avec un caractère générique.
{% javascripts '@AcmeFooBundle/Resources/public/js/*' %}
<script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}
Une autre différence avec assetic réside dans les liens générés. Dans l'environnement dev, ils ressembleront à ceci.
<script type="text/javascript" src="/app_dev.php/js/foo.js"></script>
<script type="text/javascript" src="/app_dev.php/js/bar.js"></script>
Autrement dit, les demandes de ces fichiers seront exécutées via le contrôleur frontal PHP (app_dev.php) Via des routes spéciales dans le bundle assetic. Cela signifie que lorsque vous êtes en mode dev, vous n'avez jamais besoin de vider vos actifs. Ils sont inclus automatiquement. Il vous permet également d'appliquer des filtres aux fichiers. Par exemple, ce qui suit applique le filtre cssrewrite aux fichiers extraits.
{% stylesheets 'bundles/acme_foo/css/*' filter='cssrewrite' %}
<link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}
Si vous avez déjà voulu modifier par programmation la sortie de vos ressources frontales - assetic vous permet de le faire en écrivant des filtres personnalisés twig.
Cependant, cela nécessite beaucoup de performances. En production, au lieu de lier chaque fichier individuellement via un fichier de contrôleur frontal PHP, le HTML généré ressemblera à ceci
<script type="text/javascript" src="/js/as5s31l.js"></script>
D'où as5s31l.js Vient-il? C'est ce que fait la commande assetic:dump. Il combine tous les fichiers javascript/css individuels (après l'application des filtres) et crée un fichier Nice, statique et pouvant être mis en cache pour la production.
Qu'as tu besoin de faire
Sauf indication contraire du projet, vous devez toujours exécuter assets:install Et assetic:dump, Car vous ne saurez jamais lequel de vos bundles tiers utilise ces commandes. Il vous suffit d'exécuter assetic:dump Avant de déployer ou d'afficher l'application en mode prod. L'ordre n'est pas pertinent.
En ce qui concerne le système que votre bundle doit utiliser - si vous avez lu ce qui précède et que vous ne savez pas ce que assetic peut faire pour vous, utilisez assets. Ça ira.