On Fri, Jul 1, 2011 at 3:32 AM, Micky Hulse <rgmi...@gmail.com> wrote:
Hello Andre! Thanks so much for your help, I really appreciate the pro > advice!!! :) > I'm not sure it's pro, but I'm glad to help :) > On Thu, Jun 30, 2011 at 6:01 AM, Andre Terra <andrete...@gmail.com> > wrote: > > __init__.py > > app1/ > > app2/ > > appN/ > > __init__.py > > models.py > > views.py > > urls.py > > forms.py > > templates/ > > utils.py > > project/ > > __init__.py > > forms.py > > settings.py > > urls.py > > utils.py > > views.py > > templates/ > > static/ > > (etc.) > > > Oooh, I really like the above setup! > > That's similar to how I setup my very first Django project/app (sorry, > poorly packaged... er, not packaged at all!): > > https://github.com/mhulse/code.hulse.me/tree/master/webapps > > project/ > __init__.py > manage.py > settings.py > urls.py > views.py > apps/ > app1/ > app2/ > templates/ > app1/ > app2/ > The standard really seems to be having a 'templates' folder for each app, but I think I did the same in my first 'hello world' project. > That layout seemed to work well for that particular project. > > At work, we use a more out-of-the-box setup: > > project/ > __init__.py > manage.py > settings.py > urls.py > views.py > app1/ > __init__.py > views.py > models.py > admin.py > helpers.py > managers.py > validators.py > widgets/ > urls.py > forms.py > fields.py > utils.py > templates/ > app1/ > app2/ > app3/ > templates/ > app1/ > app2/ > app2/ > > I really like your suggested setup though! Putting the apps at the > same level as the project seem to make a lot of sense. > > Using the project as a container for utils.py is a great idea also. :) > > > Which basically means my project is just another app. Nothing is > > preventing you from creating utils.py files in your apps, or even > > settings.py that get loaded from an import in your project's settings. > > Yes! That sounds like an optimal setup! :) > > When you talk about an app's settings.py file, do you just put > something like this: > > from app import settings > ... at the top of the project's settings.py file? > I usually put that at the *bottom* of the settings.py file, and give each app's settings file a different name which usually follows an app_settings.py format. So basically something like this should work: try: from myapp.settings import * except ImportError: pass Which brings us to my next point. I recently decided (out of the blue, haven't seen anyone else do it) to use the same solution to differentiate between production and development settings. As it's often the case, you will probably have your project in a git repo somewhere, so pulling/pushing on development and production environments can break things every time. To prevent me from having to set things like the DEBUG variable and different db configs, I figured why not create a production.py file which has the settings for the server? It was just a matter of adding that to .gitignore, and now *that* file doesn't get added to the git repo, and I can safely pull without having to manually alter anything. Don't forget the try/except block or your dev server will choke! Now, it feels incredibly fast to pull to my dev laptop, make changes, push to the repo, ssh into the server, pull from the repo, kill python and reload the production page. > I had never considered doing that before... I will have to experiment. > Thanks for tip! > > > I find this arrangement to be the best for my development workflow > > after many other attempts. This also helps newcomers avoid the often > > made mistake of referencing their apps in relation to the project like > > from project.app1 import views > > which would prevent the code from being reused in other projects. > > Hehe, I can relate. Been there, done that. :) > > > About your Place model, my recommendation/guess would be to abstract > > it one more time so that you could have a global BasePlace class which > > gets subclassed in an app-specific Place model. > > That's an interesting idea! > > I actually have several (abstract) models similar to "Place" that I > could use in my various apps/projects... I have found myself > duplicating the code for these various apps... It would be great to > put them at a higher level and import/sub-class as they are needed. > > > > Or at least that's what I thought last nignt before going to sleep. As > > I write this, I realize that a BasePlace would have no place (pun not > > intended) in your project, so maybe what you need is a package for > > your multiple apps which in turn gets imported into your project. > > That's a great idea/tip! > > You inspired me to create my first pip-installable package: > > https://github.com/mhulse/django-goodies > > Not much there at the moment, but I plan on adding more code at a later > date. > Sounds like you might be on your way to writing a truly reusable app, nice! I need to do that one of these days. I've never packaged anything for pip, but I promise to give it a try next month. > > The instructions found below were very helpful: > > http://guide.python-distribute.org/creation.html > > On my testing server, I was able to pip install django-goodies without > a hitch (I have yet to actually import and utilize the Place model in > a project/app though... It's getting late.) :( > > > I'm pretty much guessing at this point, but in doing so, I have > > hopefully given you food for thought while also bumping the thread so > > that other developers will weigh in. > > Definitely! Thanks so much!!!! I really appreciate it! :) > > Have a great day. > > Cheers, > Micky > Again, congrats and best of luck! Cheers, André -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
