Project Organization.
I have an idea for an application where users submit json files that represent different data that needs to be parsed and put in a DB. I believe there may be many many different types of this input data over time so I had this idea that I would break down the different models by applications. This would allow me to keep different types of data separated and displayed differently. My question is this: Is this a good idea? if I break things up into different applications can I also create a federated search across apps? Thanks J -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/564b224b-c8c6-44d0-8cd6-7390d03bb125n%40googlegroups.com.
Re: Project Organization
On Mon, 2009-08-10 at 20:51 -0700, MattR wrote: > Are there any best practices documents to organizing large Django > projects? > > Should the view code be in a file called views.py? It seems like this > file could get rather large and hard to manage, is there some > suggested way to break it up? View functions are just Python functions that are called with particular parameters (request + any arguments from the URL pattern). So you can put them literally anywhere that is on your Python path. They don't even have to reside in applications, although it's not a bad idea to do so. You definitely don't have to call the module views.py and it's not uncommon to break it up into, say, a views/ directory containing a bunch of files with related views in each file. > > Should the files with views even be called views.py, or should the > filename indicate the functionality of the view? I tend to go for separate filenames for separate functionality. I'll often have views that change data in one file, views that are for read-only things in another file and forms in other files, again, maybe grouped by functional groups. Also remember to look at how you split things into applications. A Django "project" is really just a settings file and a root URL Conf file. The settings file contains a list of applications that are used and finding a nice separation of your functionality into applications is a really good idea and pays off in spades down the road. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project Organization
Hallöchen! MattR writes: > [...] > > Should the view code be in a file called views.py? It seems like > this file could get rather large and hard to manage, is there some > suggested way to break it up? I have a subdir "views", with roughly one module per model, each typically containing "show" and "edit". "edit" covers editing and creating of an object. Additionally, the views subdir contains modules with common view code in order to avoid code dublication. This works very well. > Should the files with views even be called views.py, or should the > filename indicate the functionality of the view? I call them after the respective model. Since Django supports the explicit way, you are rather free in your naming conventions. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Project Organization
Are there any best practices documents to organizing large Django projects? Should the view code be in a file called views.py? It seems like this file could get rather large and hard to manage, is there some suggested way to break it up? Should the files with views even be called views.py, or should the filename indicate the functionality of the view? If so, I find it hard to manage a bunch of views.py files in ide's that have tabs of open files where all I see is the file name. Is there some way around this? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
Hi Guillermo! But what would happen in this case if two sites use very different templates for the same app? My templates used to have the same skeleton, the diference could be the base_site.tmpl, I can replace the base_site.tmpl on the project/templates/appname, I can use stylesheets to define design specific things to each project. Best regards! Michel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
I place my templates inside the "app_name/templates/app_name" directory. It seems template search path look for the template on this directory first. So, to decouple the app, templates should be inside it I think. But what would happen in this case if two sites use very different templates for the same app? I use the "project/templates/app_name" directory to avoid the above problem. I actually completely decouple my apps from my projects: /www/ /app1/ /app2/ /app3/ /project1/ /project2/ project 1 can use app1 and app2, and project 2 can use app1 and app3. Of course, this implies adding /www/ to the Python path in the manage.py file to avoid errors. G --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
Hi, Yeah. And conversely, it's weird that in other places django smooshes together what ought to be separate namespaces. For example, a template can refer to the templatetags of any app without qualification. Is there even a way to add qualification to disambiguate? If I have two apps with a templatetag called "index," what happens? I place my templates inside the "app_name/templates/app_name" directory. It seems template search path look for the template on this directory first. So, to decouple the app, templates should be inside it I think. Best regards, Michel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
"Doug Van Horn" <[EMAIL PROTECTED]> writes: You would put parent_folder and parent_folder/spam_website into your python path. So when you need a model from the foo application, you do: from foo.models import Eggs and if you need something from the settings module in the project, you do: from spam_website import settings This would also seem to encourage /not/ putting your applications under a project folder. I've not taken this approach in practice, though. It's just what I've read in the past... Makes sense. The author of this page sent me a private mail referencing it: http://www.guindilla.eu/blog/2006/11/02/django-deployement-personal-server/ I have yet to fully grok everything said there; I'm still reading. -- Dave Abrahams Boost Consulting www.boost-consulting.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
Stefan Foulis <[EMAIL PROTECTED]> writes: On Jan 16, 2007, at 17:52, David Abrahams wrote: For me, Django doesn't seem to be delivering on its promise to allow me to build a collection of apps and organize them in different combinations into multiple Django projects, and the documentation I can find doesn't really give any clues about best practices for project organization. One problem is that the name of the Django project folder (and thus root module) always seems to creep into the code in the app-specific directories. Any insight you can offer would be appreciated. in most cases (all for me so far) you can omit the project name. I had started doing that in several places but then had problems when I tried to set up my project with lighttpd according to https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoFcgiLighttpd The result was that I started qualifying more names than I had been before. I actually ran into some problems while deploying with mod_python when mentioning the project name in urls. conf and in some import statements. it's all about the python-path :) Of course. I always use e.g app_name.models.bla instead of project_name.app_name.models.bla everywhere now At does seem a bit weird, that in many tutorials and the Documentation the project name is always creeps in. Yeah. And conversely, it's weird that in other places django smooshes together what ought to be separate namespaces. For example, a template can refer to the templatetags of any app without qualification. Is there even a way to add qualification to disambiguate? If I have two apps with a templatetag called "index," what happens? I guess it's bad practice when trying to decouple an app from specific projects. I agree that there should be a chapter on best decoupling practaces in the docs. decoupling url.confs: http://www.djangoproject.com/documentation/0_91/ tutorial3/#decoupling-the-urlconfs Yes, that's useful, and I have to admit that I haven't applied it to my project yet. -- Dave Abrahams Boost Consulting www.boost-consulting.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
David Abrahams wrote: ...One problem is that the name of the Django project folder (and thus root module) always seems to creep into the code in the app-specific directories. IANADE (django-expert), but from what I've gleaned you can put the path of each individual application into the python path. Given: + parent_folder |---+ spam_website |---+ foo | manage.py | settings.py | urls.py You would put parent_folder and parent_folder/spam_website into your python path. So when you need a model from the foo application, you do: from foo.models import Eggs and if you need something from the settings module in the project, you do: from spam_website import settings This would also seem to encourage /not/ putting your applications under a project folder. I've not taken this approach in practice, though. It's just what I've read in the past... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Project organization and decoupling
On Jan 16, 2007, at 17:52, David Abrahams wrote: For me, Django doesn't seem to be delivering on its promise to allow me to build a collection of apps and organize them in different combinations into multiple Django projects, and the documentation I can find doesn't really give any clues about best practices for project organization. One problem is that the name of the Django project folder (and thus root module) always seems to creep into the code in the app-specific directories. Any insight you can offer would be appreciated. in most cases (all for me so far) you can omit the project name. I actually ran into some problems while deploying with mod_python when mentioning the project name in urls. conf and in some import statements. it's all about the python-path :) I always use e.g app_name.models.bla instead of project_name.app_name.models.bla everywhere now At does seem a bit weird, that in many tutorials and the Documentation the project name is always creeps in. I guess it's bad practice when trying to decouple an app from specific projects. I agree that there should be a chapter on best decoupling practaces in the docs. decoupling url.confs: http://www.djangoproject.com/documentation/0_91/ tutorial3/#decoupling-the-urlconfs Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Project organization and decoupling
For me, Django doesn't seem to be delivering on its promise to allow me to build a collection of apps and organize them in different combinations into multiple Django projects, and the documentation I can find doesn't really give any clues about best practices for project organization. One problem is that the name of the Django project folder (and thus root module) always seems to creep into the code in the app-specific directories. Any insight you can offer would be appreciated. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Project Organization
Hi - I'm relatively new to Django, and have a question about site & project organization. I have several sites that I'd like to develop using Django. Some of these sites are "top-level" (site1.domain.com, site2.domain.com) and some that fall under an existing hostname (site1.domain.com/subsite). Most of the sites will be sharing the database. Some of the tables within the database will be shared among the sites, some tables will be site-specific. My first question is how to organize django projects and apps. I'm thinking of setting up each top-level site as a separate project, duplicating db connection info in the various settings.py files, and putting the site directories on the python path so one site can have access to another site's models. Does that make sense, or is there a better way? Second question - are there any resources on running multiple sites out of one Django installation? I see the sites table and site_id setting, but haven't seen much about how best to use them. thanks in advance, Miles --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
