1. fanstatic
  2. fanstatic
  3. fanstatic
  4. Issues
Issue #50 resolved

GroupResource still needed?

created an issue

We added GroupResource some time ago to hurry.resource, but it's use case is obscure to me. Perhaps we should delete it to simplify the code. Check with Souheil what the use case is for him.

Comments (3)

  1. Jan-Jaap Driessen

    I didn't use GroupResource in the early hurry.resource days but have developed a liking to its elegance:

    I use GroupResource for combinations of JS and CSS files, since it is not clear whether the CSS depends on the JS or the other way around. I tend to define a CSS resource (a.css) with its CSS dependencies (b.css), a JS resource (a.js) with its JS dependencies (b.js) and define a GroupResource ab for the a.css and a.js resources. I then only need to need one resource (instead of two) in my view and this is all quite elegant.

    Here goes some ascii art:

    \ \__ a.css -> b.css
     \___ a.js -> b.js

    I vote to keep the GroupResource.

  2. faassen reporter

    If we're going to keep GroupResource, we need a clearer picture of what's a Resource. There are two things a resource does:

    • have dependencies
    • be renderable itself

    A GroupResource is not renderable itself, but it does have dependencies. A Bundle is renderable but doesn't have dependencies. A Resource is both. A Resource has a library, but a GroupResource doesn't - that's important when bundling. I think group resources are already resolved when bundling starts to happen.

    But GroupResource can, right now, be involved when library_nr and dependency_nr are calculated. Perhaps they shouldn't be involved at all?

    Can a GroupResource ever be dependend on itself? Perhaps we can restrict it so that this cannot happen.

  3. Log in to comment