Объединение javascript HeadScript с widmogrod/zf2-assetic-module и js в нескольких модулях

Столкнулся с небольшим препятствием, и я не могу найти подтверждающую документацию. Мой вариант использования довольно прост. В модуле Application есть javascript, который должен быть в голове, а в одном из других моих модулей, Foo, также есть скрипт, который должен быть в голове. Я предположил, что этот модуль Assetic может решить эту проблему. Вот что я сделал вывод:

Конфигурация приложения

/**
 * Assetic
 */
'assetic_configuration' => array(

    'buildOnRequest'    => true,
    'cacheEnabled'      => false,
    'webPath'           => realpath('public/assets'),
    'basePath'          => 'assets',


     'default' => array(

        'assets' => array(
            '@base_css',
            '@head_js',
        ),

        'options' => array(
            'mixin' => true,
        ),
    ),

     'modules' => array(

        'application' => array(

            # module root path for yout css and js files
            'root_path' => __DIR__ . '/../assets',

            # collection of assets
            'collections' => array(

                'base_css' => array(
                    'assets' => array(
                        'css/*.css',
                    ),
                    'filters' => array(),
                    'options' => array(),
                ),

                'head_js' => array(
                    'assets' => array(
                        'js/*.js',
                    ),
                    'filters' => array(),
                ),

                'base_images' => array(
                    'assets'=> array(
                        'images/*.png',
                    ),
                    'options' => array(
                        'move_raw' => true,
                    )
                ),
            ),
        ),
    ),
),

а затем в моем модуле Foo...

Конфигурация модуля Foo

/**
 * Assetic
 */
'assetic_configuration' => array(

     'default' => array(
        'assets' => array(
            '@base_css',
            '@head_js',
        ),

        'options' => array(
            'mixin' => true,
        ),
    ),


    'modules' => array(

        'foo' => array(

            # module root path for yout css and js files
            'root_path' => __DIR__ . '/../assets',

            # collection of assets
            'collections' => array(

                'base_css' => array(
                    'assets' => array(
                        'css/*.css'
                    ),
                    'filters' => array(),
                    'options' => array(),
                ),

                'head_js' => array(
                    'assets' => array(
                        'js/*.js' // relative to 'root_path'
                    ),
                    'filters' => array(),
                    'options' => array(),
                ),

                'base_images' => array(
                    'assets'=> array(
                        'images/*.png'
                    ),
                    'options' => array(
                        'move_raw' => true,
                    )
                ),
            ),
        ),
    ),
),

К сожалению, с этой конфигурацией в head_js.js попадает только javascript модуля Foo. Я чувствую себя как тот мем с Милтоном в нем: «Мне сказали, что будет объединение активов!» :)

Любая помощь, которую вы могли бы предложить, приветствуется.

Спасибо!


person Saeven    schedule 20.08.2013    source источник
comment
Обратите внимание: если я выбрасываю модули-›foo-›head_js, то head_js в приложениях действительно проникают внутрь.   -  person Saeven    schedule 21.08.2013
comment
Таким образом, одна из вещей, которые происходят с файлами конфигурации модуля, заключается в том, что все они объединяются вместе, а некоторые ключи (особенно те, которые не связаны с одним из DiC) переопределяются. Что позволяет вам переопределить конфигурации по умолчанию. Возможно, именно это здесь и происходит, поскольку «application» и «foo» — это разные ключи, я не понимаю, почему они переопределяют друг друга. Попробуйте сделать дамп конфигурации с контроллера $this->getServiceLocator()->get('Config') и посмотрите, все ли ключи отображаются должным образом (объединены) для конфигурации Assetic.   -  person Adrian    schedule 21.08.2013
comment
Эй, спасибо, что попробовал, Эдриан. Похоже, проблема не в конфигурации. Я пытался избежать взлома источника, чтобы попытаться понять его.   -  person Saeven    schedule 21.08.2013
comment
Тогда проблема, вероятно, в том, как модуль Assetic обрабатывает ключи конфигурации. Ваш комментарий предполагает, что (при условии, что вы загружаете модуль Foo после приложения модуля) конфигурация для Foo каким-то образом переопределяет или имеет приоритет над конфигурацией приложения. Так что, если дело не в том, как происходит слияние конфигов, то, вероятно, дело в том, как Assetic читает массив конфигов. Удачи!   -  person Adrian    schedule 21.08.2013


Ответы (1)


Хорошо - я понял это. Надеюсь, это поможет кому-то еще однажды. Ключи конфигурации, которые я отметил выше, не были неточными — но — они не были созданы должным образом, когда рассматривается секретная недокументированная функция; пришлось взломать исходный код, чтобы узнать, что включение слова «голова» в комплект ресурсов фактически автоматически загружает его в голову. В конце концов, это приятная функция, но на самом деле это головная боль, когда вы не знаете об этом.

person Saeven    schedule 23.08.2013
comment
Благодарю вас! Я пытался загрузить скрипт в раздел заголовка, но нигде не мог найти, как его использовать, я тоже собирался взломать код, но я попытался переполнить стек, и я рад, что сделал это. - person markdrake; 26.11.2014