On Sun, Oct 19, 2008 at 5:53 AM, Dana <[EMAIL PROTECTED]> wrote: > > Hello everyone, > > I am working on a CMS that includes a bunch of applications (like > Story, Event, etc...) with some being propriatary and some being third > party. When it comes to our naming conventions, we've had a bit of > discussion over namespace issues. Now I have been referencing James > Bennett's post on Projects (http://www.b-list.org/weblog/2007/nov/09/ > projects/) to make the argument that we should be putting our > application directory under the Python path and then importing our > apps like: > > from story.models import Story > > But the other side of the discussion is instead doing something like: > > from foobar.story.models import Story > > ... where foobar is our Python package name (the name of our CMS > basically) so that we can avoid possible namespace issues. > > I have read the Python docs (http://www.python.org/doc/2.5.2/tut/ > node8.html#SECTION008400000000000000000) about packages and it seems > as though the recommended approach would be to do the second example > (from foobar.story.models import Story) but from everything Im hearing > in the Django community is that the one I propose (from story.models > import Story) is the preferred method.
We need to make a distinction here about exactly what James (and the Django community) is suggesting. What James is advocating is that your application (in this case, story) should exist and operate independent of your project (foobar). This ensures that when your next project comes along that has a need for stories, you can drop the story application into that project without the untangle any foobar specific project-specific bindings. The obvious way to do this (and the most immediate consequence of this advice) is to say "don't include the project name in the namespace", and use "from story.models import Story" in your code. That is, even though Django puts applications under a project by default, that isn't conceptually how your project should be organized. Conceptually, each application should be free-standing, and your project should be picking useful applications from the cloud and integrating them in some meaningful way. However, it's important to note that this doesn't preclude the use of deeper namespaces - it just says that namespacing for an application shouldn't be tied to the project. One obvious way to satisfy this would be to create namespaces for the company, rather than the project. For example, if you work for WhizCorp, create a whizcorp.story application, and then create a whizcorp.foobar project that imports whizcorp.story. This isn't the only namespacing solution for this problem - I'm sure you could come up with other options that may work better given your local engineering environment and culture. The main point of James' suggestion is that the story application (wherever it sits in the namespace) should be constructed without any knowledge of the foobar CMS. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
