Hi Brian,
2 valid points that i hadn't even considered. I'm also leaning towards using 1 project for 1 site. I'm interested however why you don't use several apps then in a site? 1 app might be the authentication, another a blog and so on. Wouldn't it be more useful if you try to seperate the logic of one site into several apps? Then you might even be able to reuse some of it. I've checked the documentation on Sites http://docs.djangoproject.com/en/dev/ref/contrib/sites/ One thing i don't understand is that they make use of the SITE_ID in the settings as in this code: ================== from django.conf import settings def article_detail(request, article_id): try: a = Article.objects.get(id=article_id, sites__id__exact=settings.SITE_ID) except Article.DoesNotExist: raise Http404 ================== However, if you have 1 project, the SITE_ID will always be the same. That doesn't make sense unless you have 1 project per site. I would really like to know how this is supposed to work with 1 project. On the standard layout of projects, you have the template and media directories at the first level: -- project ---- application ---- media (or static) ---- templates If you want your apps to be portable, then it would make more sense to put a media/static directory and templates directory inside the application otherwise the app is to tied in with the project. It think there should be a preferred project/application layout specifying use cases so people know in advance how to layout there projects & apps before they start. For instance, if you won't be reusing your application, then there is no need to put the templates and media in the application directory. This would really help people. Maybe something like this: * 1 site, 1 or more non portable apps, -- project ---- application 1 ---- application 2 ---- media (or static) ---- templates ------ application 1 ------ application 2 * 1 or more related sites -- project ---- site 1 ---- site 2 ---- media (or static) ---- templates ------ site 1 ------ site 2 And so on. You can't specify all cases but a few common ones would make it far more clear on how the Django concept should be used. Greetings, Benedict > We've got 4 domain names which all comprise a single website. We went with > the second option where each domain is its own django project > with a single app in it. We liked this option for two reasons. > > 1) We wanted apache virtual hosts to be handling the decision about which > entry point to use instead of directing all traffic to a single > django project and letting the python (which we believe to be less > performance optimized than the apache method). This was a performance > decision. > > 2) We also wanted the ability to flexibly grow the infrastructure backing > different domains. Basically it is easier for us to handle > traffic to different areas of our site since we can always break out more > servers to handle different virtual hosts. If it was all one > django project I don't think you could allocate infrastructure this > granularly. > > my 2 cents, but I'd love to hear what others think about these things > > Brian > > On Thu, Sep 23, 2010 at 5:00 AM, Benedict Verheyen > <[email protected] <mailto:[email protected]>> wrote: > > Hi, > > > it's not exactly clear to me how the sites, projects and apps need to be > structured. > > For instance, if you have 2 sites both with a domain name, how would you > structure > this in Django? > The Django project could be called "mysites" or whatever name. > In the admin site, you would then have 2 sites. So far so good. > But how would you represent the sites? > Do you make an application per site as each site could do something > specific. > Then you end up with this structure. > Is this how it is meant to be? > -- mysites (project) > ------ site 1 (app) > ------ site 2 (app) > > The only downside might be if both sites have loads of users, they are > all displayed in the same list > in the admin interface. > Also, if you couple this with django-registration, it might not be that > simple to let a user register > for site 1 as well as site 2. I have no practical experience with > django-registration but it seems > like something i would use in the future. > > Or is it better to split the sites over 2 projects, so you have a project > per site? > -- site 1 (project) > ------ site 1 (app) > -- site 2 (project) > ------ site 2 (app) > > > Thanks for any insights, > Regards, > Benedict > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected] > <mailto:django-users%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > > > > -- > Brian Bouterse > ITng Services > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > 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. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. 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.
