Suggiestion on how split a views.py file
Karim
James Schneider
There's no requirement that you use views.py, or any of the file names that are created using 'django-admin.py', and you can create as many others as you like. You can run an entire Django project from a single file if you were so inclined. All of the file name references are just for convention and ease of entry into learning Django.
You can break them out using separate files in the same directory, maybe having a separate base.py (or use a name that makes sense), and then using relative import statements like 'from .base import <class or function>'.
Alternatively, you can have python package folders that contain your code, and those don't even need to be in the same folder, just somewhere along your python path.
There's no right answer, it really comes down to what makes the most logical sense to you and how your code is broken up inside of your views.py file and how easily you can separate and organize the different portions of code (monolithic class definitions vs. heavy sub-classing, etc.).
Do some googling for python project layout. These might be good resources for ideas:
http://blog.apps.chicagotribune.com/2010/03/08/advanced-django-project-layout/
https://github.com/pydanny/cookiecutter-django/blob/master/README.rst
-James
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACeuRGUbeDHZ8B_4xhqdCu59vBLMGB4G1EFT60MQoh79sRRynA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Karim
There's no requirement that you use views.py, or any of the file names that are created using 'django-admin.py',
James Schneider
>
> Thanks James for the answer, my problem is to update the various import in my app to refer to the new file with the code I moved into. At the moment, the only thing that can help is to have all the view tested to show an error in the import during the Test Harness.
>
> Obviously I have not all my code cover by a test.
>
Not being covered by tests is irrelevant for this operation, although having a good test base will help ensure correctness once you're done. Your code won't even start if you have incorrect import statements.
Are you using an IDE? (PyCharm is awesome) Usually they are pretty good about indicating class and function references in a file that may require an import (if needed). Worst case, you can keep firing up the development server while you are shifting things around, and it will be more than happy to scream at you if there is a missing import, although that will only show you one instance at a time.
If you move a class/function, just make adding the appropriate imports to the original file part of the migration process. You would also need to update import statements in other files that reference the relocated class. A good IDE can probably help with that as well, using refactoring or search/replace.
Try moving one minor class or function and see what happens. It shouldn't be too hard, and solving import issues is usually simplistic. The only major issue you may run into is an import loop. Be careful with classes you move that would require imports back from their original file. On that note, avoiding loops may be a driving factor in how you structure your files.
Again, the development server will scream immediately if it finds a loop.
Stay away from statements like 'from package import *' though, wild card imports are frowned upon, explicitly importing the classes you need is preferred. Using relative imports where possible is also encouraged (ie 'from .utils import my_function' rather than 'from package.utils import my_function'). Makes the code more portable in the event you change the package name where the code is stored.
Make sure you're using a VCS like git or subversion to protect yourself in the event things go south...
-James