|
We're unlikely to support this for multiple reasons. First of all if you want those kinds of url patterns then you use the URL mappings feature http://grails.org/URL+mapping
Second having name spaces at the URL level has wider implications for other parts of the system. Such as scaffolding. For example if you have a domain class foo.bar.Hello what table does it now map to? Is it foo_bar_hello by default? Back to URL mapping now. How does one reference a controller in a package when doing url mapping? It starts to get messy and ugly. I'm strongly of the belief that the current solution is as far as we should take it. As for multiple teams working, i've participated in many multi-team projects and never heard of one that involves no communication between teams Hi
I understand that you want to keep Grails as simple as possible. So if you do not support this, it will just narrow down the number of projects where I would consider using Grails, but perhaps this is even neccesary (to keep Grails simple). But ... 1) URL: I do not really understand the issue here. Yes it has implications, but what are the problems. 2) Domain class => table name: Why not map foo.bar.Hello to foo_bar_Hello as the default case (as long as I can override), you do not have to use mutliple packages, Maybe all domain classes in a package share some common configurable prefix? Maybe only the last package name shall be used as part of the table name – whatever. 3) URL (again): I have not looked too thoroughly into the URL mapping stuff, so I refrain here 4) Multiple teams: Victor I see exactly why this is a problem for the implementation. There are numerous reasons why the "name" string used internally for a class does not allow dots or similar, and that these are used in many ways to implement conventions.
I do not think it is a big problem for grails to insist on unique class names in you grails class graph. 1. URL: Imagine that you have an app where user's front-end and admin's back-end differ so that they're better server by different set of controllers and views. Currently what we do? We create FooController and AdminFooController, create views under adminFoo dir and add a URL mapping "/admin/foo/$action?/$id?" { controller = "adminFoo" }. Now "rinse and repeat" for bar, baz, etc... Ugly as my life.
If we had packages we could create FooController and admin.FooController, create views under admin/foo and no URL mappings at all. Just cleaner. 2. Domain class => table name: It feels quite organic to me to map foo.bar.Hello to foo_bar.hello by default where foo_bar is a DB schema name. 3. Rails has it. ))) Moving non-critical issues that aren't going to make it into 1.1 to 1.2
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Open
Minor
GRAILS-221, because:This improvement as described in
GRAILS-221is 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.