Automatically load based on directories

We need to review this, I'm not sure in reality it will be that useful. You often need to add some extra attributes / id / no minify etc. info to some of the resources and not others.

It would be useful in the situation where CSS themes are uploaded to a grails app and added dynamically. I've had to get around this by using

        grailsApplication.config.grails.resources.modules = {
            themesDir.eachDir {theme ->
                def name = FilenameUtils.getBaseName(theme.name)
                "${name}" {
                    resource url:[dir:"/css/themes/${name}",file:'/screen.css']
                }
            }
        }

Leanne - that's a very interesting usage. As this is already possible using the above workaround, I will downgrade the priority for now and tackle it post 1.1.

In fact in your case, automating this would likely not save you any code. You'd still need to call e.g. resourceDir for every theme dir - and then it would have to assume defaults. To customise individual resources in each theme you'd still need N "resource" calls.

This would be useful when working with OpenLayers (http://openlayers.org/) as by default it has a img/ dir that it expects to see from the main .js file (the images are used as controls on the map and may be used depending on the controls loaded).

OpenLayers does have a ImgDir option, but then you have to remember to set that wherever you're using it (I guess you could set it in an inline script in the main layout gsp?). OpenLayers also has a development mode where it expects to see a whole heap of .js files in a lib/ directory.

Another problematic JS library is jqplot (https://bitbucket.org/cleonello/jqplot/overview), which as a number of plugins and it would be nice to reference /jqplot/plugins/*.js instead of each one individually (at least in development mode).

I guess plugins are options for these as an alternative.

i posted a question regarding this on stack overflow a while back (http://stackoverflow.com/questions/10520693/resources-plugin-how-to-include-all-contents-in-a-directory).

In my case, I'm using the Extjs Javascript framework to render my thick client app. The app is split up into quite a number of files in many different directories. It would be a true pain in the neck to have to add each one of these javascript files to my resources config, hence my need to have the plugin do recursion. If this is already supported, that would be awesome, but I don't think it is.

Another item to add to this request: add functionality to dictate the ordering of files. Some of my scripts are dependent upon others; ordering is important.

I've got another case where this could come in handy.

I'm trying to pull in all of the static resources from a plugin. My plugin has some common extJS code in 2 directories - 1 directory for extJS models, 1 for extJS stores. The project that is using the plugin has the rest of the extJS files - app.js, controller/*, view/*. (see this link for more info on extJS file structure: http://docs.sencha.com/ext-js/4-1/#!/guide/application_architecture )

I would like to do this in the project that is using the plugin:

modules = {
    clientmodel {
        resource url:[dir:'app/model', file: '*']
        resource url:[dir:'app/store', file: '*']
    }
}

instead, I have to do it one file at a time:

modules = {
	application {
		resource url: 'app/model/User.js'
		resource url: 'app/store/User.js'
		resource url: 'app/model/Role.js'
		resource url: 'app/store/Role.js'
	}
}

I'm not sure why the other extJS use case is needed, since it sounds like they are using extJS 4 which already has dynamic loader capabilities on the client side. But if your client-side resources are in a plugin, extJS will not be able to dynamically load these files without help, no matter what you set your "grails.resources.uri.prefix" to.

Similar to the extJS use case, when I develop backbone.js projects I like to keep a lot of small files in the model and view folders. I'm going to work around with the stack overflow solution commented above, but would much prefer proper grails support.

If it makes a difference, the rails resources pipeline has */ implemented in their resource include.

In general it seems to work well with the whole "convention over configuration" ideal