Grails

Organizing domain classes in subfolders

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.3, 0.4
  • Fix Version/s: 0.5.5-RC1
  • Component/s: Commons
  • Labels:
    None

Description

It would be nice to be able to organize the domain classes in subfolders under grails-app/domain, but with the last version from the svn it produces a "Groovy Bug!" (org.codehaus.groovy.grails.exceptions.GrailsConfigurationException: Groovy Bug! Resource [ServletContext resource [/WEB-INF/grails-app/domain/ref/Post.groovy]] loaded, but not returned by GCL.).
Before my last svn up on the grails source code it was working.

Issue Links

Activity

Hide
Marc Palmer added a comment -

During a past discussion with Graeme, one way we could support this is to allow loading of classes in subdirectories, but users will not be permitted to include a package clause. This means their class names must still be unique in the whole class graph.
The rationale for this is that importing classes (which is required if they are in packages) is anatheme to dynamic programming in essence, and service injection by name will become ugly and problematic.

Show
Marc Palmer added a comment - During a past discussion with Graeme, one way we could support this is to allow loading of classes in subdirectories, but users will not be permitted to include a package clause. This means their class names must still be unique in the whole class graph. The rationale for this is that importing classes (which is required if they are in packages) is anatheme to dynamic programming in essence, and service injection by name will become ugly and problematic.
Hide
Alex Wei added a comment -

Coming from a Java background, defining a class, particularly a domain class, in the default package is really surprising, if not unthinkable. I bet I'll have zero chance convincing our architect to seriously consider Grails. I won't tell if he does not ask. But I doubt he'll soon find it out if he or my colleagues start going through any Grails tutorials, especially after I've been pushing the case for Grails all the time.

Should the mindshare integration with Java also include the philosophy of packaging? I wonder...

Show
Alex Wei added a comment - Coming from a Java background, defining a class, particularly a domain class, in the default package is really surprising, if not unthinkable. I bet I'll have zero chance convincing our architect to seriously consider Grails. I won't tell if he does not ask. But I doubt he'll soon find it out if he or my colleagues start going through any Grails tutorials, especially after I've been pushing the case for Grails all the time. Should the mindshare integration with Java also include the philosophy of packaging? I wonder...
Hide
Dmitriy Kopylenko added a comment -

A big + for packages. IMO this is a must.

Show
Dmitriy Kopylenko added a comment - A big + for packages. IMO this is a must.
Hide
Pablo Pazos Gutierrez added a comment -

I'm just thinking about it,
making one-level package support may be is less complex than making a full-n-level package support, and may provides good level of domain classes organization. With this in mind, we dont have classes in "default package" and have a fixed one-level pacakge support.

just thinking.

+10 for packages!

Show
Pablo Pazos Gutierrez added a comment - I'm just thinking about it, making one-level package support may be is less complex than making a full-n-level package support, and may provides good level of domain classes organization. With this in mind, we dont have classes in "default package" and have a fixed one-level pacakge support. just thinking. +10 for packages!
Hide
Travis Zimmerman added a comment -

Having projects with 100+ tables makes this imperative. I would not attempt a large project without full package support of all classes; domain, controller and services.

Show
Travis Zimmerman added a comment - Having projects with 100+ tables makes this imperative. I would not attempt a large project without full package support of all classes; domain, controller and services.

People

Vote (15)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: