Grails

Add support for Controllers to be placed in sub-folders/packages.

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: Controllers
  • Labels:
    None

Description

Add support for placing controllers in sub-folders/packages within the controllers folder so you can keep related controllers together, create more structured urls and make path based url security easier?

For example:

\grails-app\controllers\SiteController.groovy -> http://localhost:8080/sample/site
\grails-app\controllers\admin\UserController.groovy -> http://localhost:8080/sample/admin/user
\grails-app\controllers\admin\RoleController.groovy -> http://localhost:8080/sample/admin/role

And views would obviously have to follow the package structure of their controller:

\grails-app\views\admin\user\show.gsp

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
Victor Volle added a comment -

I think, that wouldn't really help.
First, it is absolutely counter intuitive. Probably everyone would expect sub folders to map to packages,
especially that two Controllers with the same name in two folders would not clash.
Second, it does not give the scaleability (in team size) that could be achieved by namespaces.
Two teams working in parallel in two packages should interfere with each other in the least possible way.

So I would propose to not implement it in a way that the class names must still be unique (better to not implement it all).

But I do not yet understand why "importing classes [...] is anatheme to dynamic programming".
Having to add imports might be cumbersome, but a first step could be to use fully qualified classnames.

But as you probably know you could create the "file" in two steps:
1) generate the code without fully qualified classnames in a StringBuffer while collecting all necessary "import statements"
2) write everything into the final "file", inserting the import statements when (and where) necessary

Show
Victor Volle added a comment - I think, that wouldn't really help. First, it is absolutely counter intuitive. Probably everyone would expect sub folders to map to packages, especially that two Controllers with the same name in two folders would not clash. Second, it does not give the scaleability (in team size) that could be achieved by namespaces. Two teams working in parallel in two packages should interfere with each other in the least possible way. So I would propose to not implement it in a way that the class names must still be unique (better to not implement it all). But I do not yet understand why "importing classes [...] is anatheme to dynamic programming". Having to add imports might be cumbersome, but a first step could be to use fully qualified classnames. But as you probably know you could create the "file" in two steps: 1) generate the code without fully qualified classnames in a StringBuffer while collecting all necessary "import statements" 2) write everything into the final "file", inserting the import statements when (and where) necessary
Hide
Marc Palmer added a comment -

Rolling over to 0.5.5 reduce workload for 0.5 pre JavaOne

Show
Marc Palmer added a comment - Rolling over to 0.5.5 reduce workload for 0.5 pre JavaOne
Hide
Graeme Rocher added a comment -

classes can be placed in packages now, only limitations is controller Prefix still has to be unique. So you can't have two controllers with same class name regardless of package

Show
Graeme Rocher added a comment - classes can be placed in packages now, only limitations is controller Prefix still has to be unique. So you can't have two controllers with same class name regardless of package
Hide
Victor Volle added a comment -

Please reopen.
This is only half of the enhancement, and its not leading anywhere.
A package is a namespace and not only a name.
The reason that controllers, domain classes should be in packages is exactly that multiple teams would be able to work in parallel if each team has its own package, and must not consider name clashes.

Show
Victor Volle added a comment - Please reopen. This is only half of the enhancement, and its not leading anywhere. A package is a namespace and not only a name. The reason that controllers, domain classes should be in packages is exactly that multiple teams would be able to work in parallel if each team has its own package, and must not consider name clashes.
Hide
Joshua Hyde added a comment -

For anyone who comes across this issue, like myself, in search of a method to get controllers mapped to subpaths, I ended up using the configuration mentioned at SO[1] to be able to get controllers mapped to subpaths.

1. http://stackoverflow.com/questions/4232884/dynamic-grails-url-mapping-config

Show
Joshua Hyde added a comment - For anyone who comes across this issue, like myself, in search of a method to get controllers mapped to subpaths, I ended up using the configuration mentioned at SO[1] to be able to get controllers mapped to subpaths. 1. http://stackoverflow.com/questions/4232884/dynamic-grails-url-mapping-config

People

Vote (14)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: