Różnica między assetic: dump i asset: install

Jaka jest różnica między assetic:dumpi w Symfony2 assets:install? W jakich scenariuszach powinno być używane każde z tych poleceń i w jakiej kolejności (jeśli kolejność ma znaczenie)?

Właściwie pisałem o tym niedawno w artykule o OroCRM, który jest oparty na Symfony 2. Jeśli chcesz poznać kontekst / dlaczego różnych poleceń, może to Cię zainteresować.

Istnieją dwa różne systemy włączania plików frontendu (javascript, css, obrazy itp.) Do aplikacji Symfony. assets:installKomendy przyszedł pierwszy. To polecenie przeszuka wszystkie pakiety Symfony w aplikacji pod kątem pliku

Resources/public

teczka. Jeśli zostanie znalezione, assets:installpolecenie skopiuje pliki lub dowiązania symboliczne z Resources/publicdo web/public/bundle/[bundle-name]. W tym miejscu linki utworzone za pomocą assetsfunkcji twig będą szukać tych plików. To

<script src="{{ asset('js/script.js') }}" type="text/javascript"></script>

Staje się tym

<script src="/bundles/[bundle-name]/js/script.js" type="text/javascript"></script>

To wszystko assets, co robi system. Pozwala na przechowywanie plików frontendu w pakiecie.

asseticSystem jest inny. Za pomocą asseticłączysz do takich plików.

{% javascripts '@AcmeFooBundle/Resources/public/js/foo.js' %}
    <script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}

Istnieją podobne tagi dla arkuszy stylów i obrazów. Zauważ, że asseticumożliwia tworzenie linków do plików w dowolnym pakiecie. ( @AcmeFooBundle). Assetic umożliwia także tworzenie linków do wielu plików w folderze za pomocą symbolu wieloznacznego.

{% javascripts '@AcmeFooBundle/Resources/public/js/*' %}
    <script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}

Kolejna różnica asseticdotyczy generowanych linków. W devśrodowisku będą wyglądać mniej więcej tak.

<script type="text/javascript" src="/app_dev.php/js/foo.js"></script>
<script type="text/javascript" src="/app_dev.php/js/bar.js"></script>

Oznacza to, że żądania dotyczące tych plików będą przechodzić przez przedni kontroler PHP ( app_dev.php) za pośrednictwem specjalnych tras skonfigurowanych w asseticpakiecie. Oznacza to, że gdy jesteś w devtrybie, nigdy nie musisz porzucać swoich zasobów. Są dołączane automatycznie. Umożliwia także stosowanie filtrów do plików. Na przykład poniższa procedura stosuje cssrewritefiltr do pobieranych plików.

{% stylesheets 'bundles/acme_foo/css/*' filter='cssrewrite' %}
    <link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}

Jeśli kiedykolwiek chciałeś programistycznie zmienić dane wyjściowe swoich zasobów frontendu -  asseticmożesz to zrobić, pisząc niestandardowe filtry gałązek.

Jednak wymaga to dużej wydajności. W środowisku produkcyjnym, zamiast łączyć każdy plik osobno przez plik kontrolera frontowego PHP, wygenerowany kod HTML będzie wyglądał następująco

<script type="text/javascript" src="/js/as5s31l.js"></script>

Skąd się as5s31l.jsbierze? To właśnie assetic:dumprobi polecenie. To łączy wszystkie pojedyncze pliki javascript / css (po zastosowaniu filtrów) i tworzy piękny, statyczny, Cacheable plik do produkcji.

Co musisz zrobić

O ile projekt nie mówi inaczej, zawsze powinieneś uruchamiać assets:installi assetic:dump, ponieważ nigdy nie wiesz, który z pakietów stron trzecich używa tych poleceń. Musisz tylko uruchomić assetic:dumpprzed wdrożeniem lub wyświetleniem aplikacji w prodtrybie. Porządek nie ma znaczenia.

Jeśli chodzi o system, którego powinien używać Twój pakiet - jeśli przeczytałeś powyższe i nie masz pewności, co asseticmoże dla Ciebie zrobić, użyj assets. Wydobrzejesz.