I maintain a Django webapp for a client of mine. We built it out in Django and for computer users, it's great. We now want to cater to mobile device users.
On top of a template switch, we also need things to work differently. The application will have views that work in a subtly different way but also the URL structure needs to be simplified.
I realise what I'm about to ask for violates the DRY ethos but is there a good way to split the urls.py so that half of it is for ourdomain.com and the other half is for m.ourdomain.com? If I can do that, I can add a mobile_views.py and write the new views.
Django's Sites is enabled in the project but I'm happy to use a hard-coded request.domain.startswith('m.')-style hack. Seems like that might perform better - but I've no idea how one gets the request from the URLs file.
Use middleware to detect the access to the other site and set request.urlconf to the other urlconf that you want to use.
Related
Meteor concatenates, minifies and compiles all html, css and javascript and sends them all to the client. But as I noticed, it's not useful for some cases.
For example, for most users we have app which works on myapp.com and another big part of app - admin dashboard works on myapp.com/admin. The size of admin part is compatible to the size of a main app part, but it's used only by hundreds of users or so. As a result most of the users load 2x size on client, half of which is useless and can't be used.
Does Meteor have solutions of this problem or maybe someone can suggest any hacks to solve it?
if you made your whole /admin/ section a separate package you could deploy two builds, with and without, and then route any clicks on "/admin/" URLs to "admin.APP.com/admin". both apps would of course need to talk to the same database.
Some people are using nginx proxy to decide what to serve, but this is not so much based on URLs as on some property of the userAgent, eg for mobile devices. this is nicer than having separate subdomains. the user doesn't see "admin.APP.com", the different backends are masked from them. But, you may not care so much about that. Having admin.* be explicit is a good thing.
I'm trying to add new url patterns to the projects urls.py(not an apps urls) on the fly. I couldn't find anything about this on stackoverflow!
Edit:
I'm writing a simple scaffolding app. For a given model, I create forms, views, templates, and urls.py for an app on the fly. The last thing is to add(attach) urls.py of the app to the urls.py of the project automatically.
Django routing does not allow such dynamics, as the routing table is built once in the application startup and never refreshed. Even if it where refreshable then you should communicate the routing table changes across different server processes using database, sockets, Redis pubsub or such mechanism and you would be bending Django framework for something it was not designed to do.
Instead, as the suggestion is, you need one generic regex hook to match the all URLs you want to be "dynamic". Then, inside the view code of this generic URL you can do your own routing based on the full input URL and the available data (E.g. from database). You can even build your own Django URL resolver inside the view if you wish to do so, though this might not be a problem-free approach.
Generally, the better approach to solve the situation like this is called traversal. Django does not natively support traversal, but other Python web frameworks like Pyramid support traversal.
I have been researching the various (and there are many) ways to have multiple sites under a single Django framework.
I still don't see a solution that fits well for my use case. The use case being:
A single database, as the majority of data (95%+) will be shared between two
apps
Two distinct user types, that each login via different domains,
and in fact interact with the same raw data, differently
What I want to achieve is this:
When a visitor comes to example.com, the settings for SITE_ID = 1 are in effect.
When a visitor comes to training.example.com, the settings for SITE_ID = 2 are in effect.
I want to do this because:
I want to use explicitly different UserProfile objects for the different users
I want to mix and match views and apps at my will between the different domains
Django docs on the Sites framework don't seem to help me, even though with this and some other articles around, I can see a few possibilities.
My current thinking is to actually solve it using the wsgi server (uWSGI in my case), where I'd take Django's default wsgi.py, duplicate it, and each wsgi conf wiill have its own Django settings.py.
Then the server will in fact be serving two distinct wsgi apps, even though they use much of the same code.
So, in this scenario, my Django project will have:
example.com.settings.py (SITE_ID = 1)
training.example.com.settings.py (SITE_ID = 2)
example.com.wsgi.py (uses example.com.settings.py)
training.example.com.wsgi.py (uses training.example.com.settings.py)
My scenario here should work but it will be twice the memory of solving this within the same Django instance.
Any better implementation for what I need to achieve?
For what I know settings.py is unique for every django project, and the SITE_ID is defined at this level. IMHO the best approach is to use many django projects with database routers. In each project you can define the SITE_ID for use with the django sites framework.
https://docs.djangoproject.com/en/dev/topics/db/multi-db/#database-routers
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 am almost done developing a Django project (with a few pluggable apps).
I want to offer this project as a SaaS (something like basecamp).
i.e: project1.mysaas.com , project2.mysaas.com etc
I seek your expertise in showing me the path.
Ways I have thought of are:
1 use Sites to define site specific settings.py
2 a middleware to detect request then set settings accordingly
3 create Django project (taking in pluggable apps) for each site
Thanks.
btw, i am a total newbie.
Your requirements aren't at all clear but I'll assume you aren't doing anything tricky and also assume your "project1", "project2" are customer names which won't need any special branding.
First, about your ideas:
You probably won't need to use the sites framework unless each site is branded differently. The site framework works well doing what it was designed to do, which is present different views of a common set of data.
This would work but probably is not the best approach IMO.
This is unmanageable.
Now, this is a really hard topic because there are so many issues. A decent place to start reading is the High Scalability Blog and especially relevant for you would be the post on 37signals Architecture.
Finally, here's what I am doing in a small SaaS app (that doesn't need extreme scalability):
Use the sites framework (because user pages will be branded by the partner/reseller and each partner has a unique login page)
Use mod_wsgi to minimize resource usage from all the Django instances.
Instead of middleware I put a common code at the top of every view that identifies the company of the user. I need this for logic in the views which is why I don't think it's useful in middleware.