Pregunta

I am building a Grails plugin (grails-myorg.zip) that will contain reusable code/artifacts that should be used by every Grails app in our organization. This includes custom CSS/JS files that help give our apps a consistent look-and-feel.

I'm wondering what the best course of action here is:

  • Create a grails-myorg-themes.zip plugin, which just includes the reusable CSS and JS files, and then make that a runtime plugin/dependency (using BuildConfig.groovy) of the main grails-myorg.zip plugin; or
  • Put the CSS/JS files in the main grails-myorg.zip plugin, but then use the Grails resources plugin to configure the files for all downstream dependencies.

Ultimately the only requirement is:

Anytime a developer includes the main grails-myorg.zip plugin as part of their app's plugins, then the custom CSS/JS files will be available (via URL) at runtime to the app's HTML files. This way, they have the option to include CSS styles and other JS stuff - defined inside these common files - in their apps.

Which strategy should I utilize, why and what would the configuration look like?

¿Fue útil?

Solución

I don't see a requirement of having grails-myorg-themes plugin if sole purpose of grails-myorg is just to be a provider for resources to a grails app.

Second option looks like a good start for the scenario that has been laid out. If resources change and/or updated, versioning the plugin up would suffice.

What:

  • You would not need resources plugin in the plugin, app should be using resources plugin. If at all resources plugin is used in grails-myorg plugin then it should be excluded in the package by using export = false in build config.
  • Create business specific resources modules which can be used in the app effortlessly. For example:

Plugin resources file should have something like below, highlighting dashboard (say, a enterprise wide module which reflects the brand) as a module which can be required in app in specific pages/templates.

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

So on and so forth for common domain specific resources.

Why:
The plugin is self explanatory in mentioning that "any enterprise level resource, related to a domain or a module" can be referred from this plugin. In the end, it will be a useful idea only if the plugin is documented and shared appropriately across teams, so that no one re-invents the wheel.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top