Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.0.2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Grails 2.0.0.M2

      Description

      This is just an idea for a way to improve the DSL. Right now, you list all files you want for each bundle.

      modules = {
          common {
              resource url:[dir:'css', file: 'file1.css']
              resource url:[dir:'css', file: 'file2.css']
          }
      }
      

      Would it be a good idea to support loading all files in a directory? Something like this?

      modules = {
          common {
              resource url:[dir:'css', file: '*']
          }
      }
      

      Let me know! Thanks, Bobby

        Activity

        Hide
        John Gordon added a comment -

        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.

        Show
        John Gordon added a comment - 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.
        Hide
        Keith Zimmerman added a comment - - edited

        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.

        Show
        Keith Zimmerman added a comment - - edited 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.
        Hide
        Travis Dixon added a comment -

        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

        Show
        Travis Dixon added a comment - 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
        Hide
        Zhuravskiy Vitaliy added a comment -

        I think i will be very useful feature with recursive flag.

        For example, i wanna use jquery-ui git repository as git submodule im my web-app\js project directory, i don't wanna use npm and Grunt for build jquery.ui.js.
        I am don't wanna manually type 36 line of resources. I just wanna write:

        'jquery-ui'

        Unknown macro: { resource url}

        "recursive: false" for exclude i18n directory.

        Show
        Zhuravskiy Vitaliy added a comment - I think i will be very useful feature with recursive flag. For example, i wanna use jquery-ui git repository as git submodule im my web-app\js project directory, i don't wanna use npm and Grunt for build jquery.ui.js. I am don't wanna manually type 36 line of resources. I just wanna write: 'jquery-ui' Unknown macro: { resource url} "recursive: false" for exclude i18n directory.
        Hide
        Anselm McClain added a comment -

        We were thinking of migrating off of JAWR (https://jawr.java.net/) to be more in line with "core" Grails plugin/best practices, but this limitation caught us up. We're also building rich javascript apps with many discrete files, and we want a single layer in the stack to combine/minify/compress.

        Looks like JAWR just had a major new release after a long period of inactivity - will be checking up on that. They support wildcard patterns, and we've used them with great success for a while.

        Show
        Anselm McClain added a comment - We were thinking of migrating off of JAWR ( https://jawr.java.net/ ) to be more in line with "core" Grails plugin/best practices, but this limitation caught us up. We're also building rich javascript apps with many discrete files, and we want a single layer in the stack to combine/minify/compress. Looks like JAWR just had a major new release after a long period of inactivity - will be checking up on that. They support wildcard patterns, and we've used them with great success for a while.

          People

          • Assignee:
            Marc Palmer
            Reporter:
            Bobby Warner
          • Votes:
            14 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated: