Пользовательские плагины CSS и JS в Grails

Я создаю подключаемый модуль Grails (grails-myorg.zip), который будет содержать повторно используемый код/артефакты, которые должны использоваться каждым приложением Grails в нашей организации. Это включает в себя пользовательские файлы CSS/JS, которые помогают придать нашим приложениям единообразный внешний вид.

Мне интересно, какой лучший курс действий здесь:

  • Создайте плагин grails-myorg-themes.zip, который включает только многократно используемые файлы CSS и JS, а затем сделайте его плагином/зависимостью времени выполнения (используя BuildConfig.groovy) основного плагина grails-myorg.zip; или
  • Поместите файлы CSS/JS в основной подключаемый модуль grails-myorg.zip, но затем используйте подключаемый модуль ресурсов Grails для настройки файлов для всех нижестоящих зависимостей.

В конечном итоге единственным требованием является:

Всякий раз, когда разработчик включает основной подключаемый модуль grails-myorg.zip как часть подключаемых модулей своего приложения, пользовательские файлы CSS/JS будут доступны (через URL) во время выполнения для HTML-файлов приложения. Таким образом, у них есть опция для включения стилей CSS и других элементов JS, определенных в этих общих файлах, в свои приложения.

Какую стратегию следует использовать, почему и как будет выглядеть конфигурация?


person AdjustingForInflation    schedule 08.04.2014    source источник
comment
Ведьмачьи черты будут у grails-myorg.zip?   -  person    schedule 08.04.2014


Ответы (1)


Я не вижу необходимости иметь плагин grails-myorg-themes, если единственной целью grails-myorg является просто предоставление ресурсов для приложения Grails.

Второй вариант выглядит хорошим началом для изложенного сценария. Если ресурсы изменяются и/или обновляются, будет достаточно версии плагина.

Что:

  • Вам не понадобится плагин ресурсов в плагине, приложение должно использовать плагин ресурсов. Если на всех ресурсах плагин используется в grails-myorg плагине, то его следует исключить из пакета с помощью export = false в конфигурации сборки.
  • Создавайте специальные модули ресурсов для бизнеса, которые можно без труда использовать в приложении. Например:

Файл ресурсов плагина должен иметь что-то вроде приведенного ниже, выделяя dashboard (скажем, корпоративный модуль, который отражает бренд) как модуль, который может быть required в приложении на определенных страницах/шаблонах.

//MyOrgResources.groovy
modules = {
    dashboard {
        resource url: 'js/dashboard/dashboard.js'
        resource url: 'css/dashboard/dashboard.css'
    }
}

И так далее, и тому подобное для ресурсов, специфичных для общих доменов.

Почему:
Плагин говорит сам за себя, говоря, что «любой ресурс корпоративного уровня, связанный с доменом или модулем», может быть связан с этим плагином. В конце концов, это будет полезной идеей только в том случае, если плагин будет задокументирован и соответствующим образом распространен среди команд, чтобы никто не изобретал велосипед.

person dmahapatro    schedule 08.04.2014
comment
+1. Мое мнение, что разделение хорошо только в том случае, если вы хотите разделить их по функциям, а мастер-плагин не будет иметь ничего общего с пользовательским интерфейсом. - person ; 08.04.2014
comment
Спасибо @dmahapatro (+1) - но (1) как мне сделать dashboard модулем required для любого приложения Grails с помощью этого плагина? И (2) я не совсем понимаю плагин ресурсов: если модуль CSS/JS определен в плагине, почему мне нужно использовать плагин ресурсов из приложения, а не плагин? Еще раз спасибо! - person AdjustingForInflation; 08.04.2014
comment
1. Таким же образом любой модуль в приложении dependOn любой другой модуль. Вы можете сослаться на документы о dependsOn. 2. Вы можете сделать и то, и другое. Модуль dahsboard можно использовать не только в плагине, если это необходимо, но и в приложении, в котором используется плагин. Что касается использования плагина ресурсов, вы можете получить всестороннее представление, изучив документы в деталь. - person dmahapatro; 08.04.2014