I am interested in setting up my application so that I can serve location specific content.
Something like craigslist, where miami.craigslist.org only shows posts in miami.
Assuming that I have a model that has a City field, what would be the best way to achieve this?
Banjer suggested the Sites framework, but I feel like it might not be a 100% perfect fit for your situation. The sites framework works well for different sites sharing the same database. But in your case, its all the same site and you are basically just wanting to pass an argument to your views for the city.
You could probably do something even simpler by just pointing wildcard *.domain.com to your django site, and then using request.get_host() in the view to parse out the subdomain:
https://docs.djangoproject.com/en/1.4/ref/request-response/#django.http.HttpRequest.get_host
So if the domain were: "losangeles.domain.com", and you parsed out "losangeles", you could use that as your city "tag" in your query. And when you create new content, you can just tag it with a city.
Post.objects.filter(city_tag="losangeles")
I suppose it depends on how robust of a "location" structure you need in your site. It very well might be a City model with various meta data fields, including the tag field. Then you would associate it with the content as a foreign key. It kind of approaches the same general idea as the Sites framework, but in this case you aren't really creating different sites.
You should check out the "sites" framework. If you've ever used the built-in Django admin, then you've probably seen the sites section where example.com is the only site listed by default.
Real world example, from the link I provided:
Associating content with multiple sites
The Django-powered sites LJWorld.com and Lawrence.com are operated by
the same news organization – the Lawrence Journal-World newspaper in
Lawrence, Kansas. LJWorld.com focuses on news, while Lawrence.com
focuses on local entertainment. But sometimes editors want to publish
an article on both sites.
The brain-dead way of solving the problem would be to require site
producers to publish the same story twice: once for LJWorld.com and
again for Lawrence.com. But that’s inefficient for site producers, and
it’s redundant to store multiple copies of the same story in the
database.
The better solution is simple: Both sites use the same article
database, and an article is associated with one or more sites.
So instead of a City field, you'd add a field to your model for Site, e.g.:
sites = models.ManyToManyField(Site)
You basically have one database that all of your cities use. Convenient, but I'm wondering how it would scale down the road. I'm starting a similar project myself and will use the Django sites framework to get the project off the ground. I'm interested in hearing about a more scalable solution from a database person though.
Related
I'm new to Django and I come from Drupal family. There we have Organic Groups with which we can create groups of content and subsites; how do I do something like that with Django?
Say I'm making this site for my company using Django and every department in my company needs a private section on the site. For example, the design people have their own part of the website into which the back-end developers can not come in. And the back-end developers will have the same thing too.
I want to build the site in such a way that I just login into Django admin and add a new category or subsite or group (whatever the Django term is) with the same settings from other groups or with similar settings.
It depends on what you mean by "private section". You should probably try looking at it from a different angle:
Django splits a site's functionality by means of "apps". Each app does its specific thing, and gets a set of tables in the database. Apps can access each others' tables. For example, it's common for other apps to access the Auth app's user, group, and permissions tables. Is this what you mean by "sub sites"?
As for access control, users can be assigned to groups and they can have various administrative permissions assigned to them. Add, change, and delete permissions are automatically generated for each model (i.e. database table). You can also add your own permissions.
I don't think you'll be able to separate the designers from the back-end developers at the Django level. You'll need to do something else, such as maintain separate source repositories for each and merge them to create the usable site (each group would have read-only access to the other). It really depends on your teams' discipline, because these elements can get intertwined.
Django recommends that static files be served by something else, say directly from your web server, or from another machine with a simple HTTP server (no CGI/WSGI/whatever). This is because Django can only slow down static files compared to direct service. However, for testing, ther is a static page server you can enable.
Given all that, static files usually amount to CSS, images, media, and JavaScript. Of these, the back-end people might want to mess with the JS, but that's it, so this could be in the designers' repo.
The Django tree itself has the code for the site and the apps. It's almost all back end stuff. The exception is the HTML template files, located in the "templates" directory in each app. These are the files that are filled in with the context data supplied by the back-end view code. I have no idea if this is front or back end for you guys; it could be mostly back end if there's a lot of CSS discipline, but I think that's unlikely.
There are a lot of things that you can do in Django that make life easier for one side or the other. For example, template tags allow custom Python code to generate HTML to insert into the page. I use these to generate tab bars and panes, for example.
I really can't help much more without getting a better picture of what your needs are. The question is still vague. You're probably best off taking a day or two going through the tutorial, seeing what the Django perspective is, and then working out how (or if!) it fits into your needs.
I have seen various questions on multi-site and multi-host Django, including subdomains and specific schemas per subdomain. What I have not seen is a solution (or tips so I can code one) to this problem.
I am using Django + PostgreSQL on a site, let's say myapp.com
The main site myapp.com is used for registration of companies
A registered company gets its own subdomain, company.myapp.com, and logs in and works from there.
My idea of doing this is by making 2 initial schemas in PostgreSQL.
Schema "auth" for companies and users
Schema "empty_company_template" with the basic tables for a company, all empty but hooked up to the right sequences etc.
When a new company registers, I want this to happen:
Create a new schema for the company, derives from empty_company_template
Create a new DB user for the company, named company (the company name)
Set the search path for this new user to company, auth (no access to empty_company_template, no access to other users schema's)
To me this seems better than the existing solutions that all seem to depend on one single database user for the entire application (with access to all schemes). However, I struggle to get this to work. Is this indeed a viable approach? Can anyone point me in the right direction? It's Django, so perhaps it's been done and I just haven't found it?
I have a working solution that does everything except separate users.
It's a small piece of middleware (just process_request) that determines the subdomain, and executes a SET search_path query on the database. It's good enough for me for now.
Anyone interested in the code, just contact me. I'll publish it somewhere when it's final.
EDIT Dec 22, 2010:
I published the code on my blog at
http://blog.dyve.net/django-subdomains-and-postgresql-schemas
If you want to have separate DB users, you'll probably want separate Django instances, otherwise there will be no security gain. This model will require much more complicated process management. I don't think you'll find a ready-made solution for such an application, so you will most probably have to roll your own. Otherwise, if you're unwilling to invest much time, stick with the one user for the entire app approach.
I am thinking of a configuration where I have one master website at:
www.masterdomain.com
and N satelite domains where I can access the satelite domains as follows:
www.masterdomain.com/some_url/satetlite1.html
www.masterdomain.com/some_url/satetlite2.html
...
www.masterdomain.com/some_url/satetliteN.html
Is this possible?
The sites Framework may interest you.
Django comes with an optional “sites” framework. It’s a hook for associating objects and functionality to particular Web sites, and it’s a holding place for the domain names and “verbose” names of your Django-powered sites.
Use it if your single Django installation powers more than one site and you need to differentiate between those sites in some way.
Also there are a couple of good blog post about that matter, e.g. this one:
http://www.huyng.com/archives/franchising-running-multiple-sites-from-one-django-codebase-2/394/
I am new to django and python and am trying to figure out how to modify an existing app to run multiple shops through a single domain.
Django's sites middleware seems inappropriate in this particular case because it manages different domains, not sites run through the same domain, e.g. : domain.com/uk domain.com/us domain.com/es etc.
Each site will need translated content - and minor template changes. The solution needs to be flexible enough to allow for easy modification of templates.
The forms will also need to vary a bit, e.g minor variances in fields and validation for each country specific shop.
I am thinking along the lines of the following as a solution and would love some feedback from experienced django-ers:
In short: same codebase, but separate country specific urls files, separate templates and separate database
Create a middleware class that does IP localisation, determines the country based on the URL and creates a database connection, e.g. /au/ will point to the au specific database and so on.
in root urls.py have routes that point to a separate country specific routing file, e..g
(r'^au/',include('urls_au')),
(r'^es/',include('urls_es')),
use a single template directory but in that directory have a localised directory structure, e.g. /base.html and /uk/base.html and write a custom template loader that looks for local templates first. (or have a separate directory for each shop and set the template directory path in middleware)
use the django internationalisation to manage translation strings throughout
slight variances in forms and models (e.g. ZA has an ID field, France has 'door code' and 'floor' etc.) I am unsure how to handle these variations but I suspect the tables will contain all fields but allowing nulls and the model will have all fields but allowing nulls. The forms will to be modified slightly for each shop.
Anyway, I am keen to get feedback on the best way to go about achieving this multi site solution. It seems like it would work, but feels a bit "hackish" and I wonder if there's a more elegant way of getting this solution to work.
Thanks,
imanc
There's no reason you can't the sites framework with multiple Django installations served from different subdirectories under the same domain.
OK I have done some further digging and it seems that the Django sites framework is not suitable for the same domain but with different paths:
www.mydomain.com/uk
www.mydomain.com/au
etc.
The two other options are an apache/wsgi set up where a separate wsgi and settings.py is referenced for each subdirectory. This seems a bit cumbersome; I don't really want to have to be reconfiguring apache each time I deploy a new shop. Also it'd make maintaining the local dev, online dev, staging and live versions of the site more hassle.
I think given this situation the best solution is to look at a middleware class that keeps track of country code and somehow changes database settings and root urls.py. Then each app is going to have to be aware of its current base url for things like form actions and links and so on.
I'm looking at setting up a small company that hosts flash-based websites for artist portfolios. The customer control panel would be django-powered, and would provide the interface for uploading their images, managing galleries, selling prints, etc.
Seeing as the majority of traffic to the hosted sites would end up at their top level domain, this would result in only static media hits (the HTML page with the embedded flash movie), I could set up lighttpd or nginx to handle those requests, and pass the django stuff back to apache/mod_whatever.
Seems as if I could set this all up on one box, with the django sites framework keeping each site's admin separate.
I'm not much of a server admin. Are there any gotchas I'm not seeing?
Maybe. I don't think the built-in admin interface is really designed to corral admins into their own sites. The sites framework is more suited to publish the same content on multiple sites, not to constrain users to one site or another. You'd be better off writing your own admin interface that enforces those separations.
As far as serving content goes, it seems like you could serve up a common (static) Flash file that uses a dynamic XML file to fill in content. If you use Django to generate the XML, that would give you the dynamic content you need.
This django snippet might be what you need to keep them seperate:
http://www.djangosnippets.org/snippets/1054/
"A very simple multiple user blog model with an admin interface configured to only allow people to edit or delete entries that they have created themselves, unless they are a super user."
Depending on the amount of sites you're going to host it might be easier to write a single Django app once, with admin, and to create a separate Django project for each new site. This is simple, it works for sure AND as an added bonus you can add features to newer sites without running the risk of causing problems in older sites.
Then again, it might be handier to customize the admin such that you limit the amount of objects users can see to those on the given site itself. This is fairly easy to do, allthough you might want to use RequestSite instead of the usual Site from the sites framework as that requires separate settings for each site.
There exists this one method in the ModelAdmin which you can override to have manual control over the objects being edited.