В чем разница между assetic:dump
и в Symfony2 assets:install
? В каких сценариях следует использовать каждую из этих команд и в каком порядке (если порядок важен)?
В чем разница между assetic:dump
и в Symfony2 assets:install
? В каких сценариях следует использовать каждую из этих команд и в каком порядке (если порядок важен)?
Ответы:
Я действительно писал об этом недавно в статье об OroCRM, которая основана на Symfony 2. Если вам нужен какой-то контекст / почему для разных команд, вам может быть интересно.
Есть две разные системы для включения файлов внешнего интерфейса (javascript, css, изображения и т. Д.) В приложение Symfony. Команда assets:install
пришла первой. Эта команда будет искать во всех пакетах Symfony в приложении
Resources/public
папка. Если найден, assets:install
команда скопирует файлы или создаст символическую ссылку из Resources/public
в web/public/bundle/[bundle-name]
. Здесь ссылки, созданные с помощью assets
функции twig, будут искать эти файлы. Этот
<script src="{{ asset('js/script.js') }}" type="text/javascript"></script>
Становится этим
<script src="/bundles/[bundle-name]/js/script.js" type="text/javascript"></script>
Это все, что assets
делает система. Это позволяет вам хранить ваши файлы интерфейса вместе с пакетом.
assetic
Система отличается. С помощью assetic
вы создаете ссылку на такие файлы.
{% javascripts '@AcmeFooBundle/Resources/public/js/foo.js' %}
<script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}
Есть похожие теги для таблиц стилей и изображений. Обратите внимание, что assetic
позволяет ссылаться на файлы в любом пакете. ( @AcmeFooBundle
). Assetic также позволит вам ссылаться на несколько файлов в папке с подстановочным знаком.
{% javascripts '@AcmeFooBundle/Resources/public/js/*' %}
<script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}
Еще одно отличие assetic
заключается в генерируемых ссылках. В dev
окружающей среде они будут выглядеть примерно так.
<script type="text/javascript" src="/app_dev.php/js/foo.js"></script>
<script type="text/javascript" src="/app_dev.php/js/bar.js"></script>
То есть запросы этих файлов будут проходить через фронт-контроллер PHP ( app_dev.php
) через специальные маршруты, настроенные в assetic
пакете. Это означает, что когда вы находитесь в dev
режиме, вам никогда не нужно сбрасывать свои активы. Они включаются автоматически. Он также позволяет применять фильтры к файлам. Например, следующее применяет cssrewrite
фильтр к загруженным файлам.
{% stylesheets 'bundles/acme_foo/css/*' filter='cssrewrite' %}
<link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}
Если вы когда-нибудь хотели программно изменить вывод своих ресурсов внешнего интерфейса, assetic
вы можете сделать это, написав собственные фильтры ветки.
Однако это требует высокой производительности. В производственной среде вместо связывания каждого файла отдельно через файл фронт-контроллера PHP сгенерированный HTML-код будет выглядеть следующим образом
<script type="text/javascript" src="/js/as5s31l.js"></script>
Откуда as5s31l.js
взялось? Вот что assetic:dump
делает команда. Он объединяет все отдельные файлы javascript / css (после применения фильтров) и создает красивый, статический, кэшируемый файл для производства.
Если в проекте специально не указано иное, вам всегда следует запускать assets:install
и assetic:dump
, поскольку вы никогда не узнаете, какие из ваших сторонних пакетов используют эти команды. Вам нужно только запустить assetic:dump
перед развертыванием или просмотром приложения в prod
режиме. Порядок не имеет значения.
Что касается системы, которую должен использовать ваш пакет - если вы прочитали выше и не знаете, что assetic
может для вас сделать, используйте assets
. Вам будет хорошо.
<script type="text/javascript" src="app_dev.php/js/as5s31l.js"></script>
, вы на самом деле имели в виду <script type="text/javascript" src="app.php/js/as5s31l.js"></script>