I've been working on. A web project for few months now.And it's a simple website with usual django models views urls and templates,with simple Ajax using jquery for the templates.
Now thinking of having a possibility of making an application soon. I am thinking of using Tastypie to make a RESTful api for my website. So the idea is to
Use Tastypie to make a RESTful api.
Using backbone.js to make my website a single page application
Using plist and json for my android and ios applications.
My concern starts here, with this new course of action, would. I have to make most of my website again? And if that is the case should I stop working on what I've already made and then start from scratch following the above guidelines? Again, in context to tastypie and backbone.js, what would happen to my already written views and template logic?
I've been reasearching over this topic alot and cannot find a definitive answer. So thought of asking all of you who are already experienced or have gone through the same transition.
I have almost no exposure to RESTful APIs. But I am getting inclined towards a RESTful approach as it would make app development easier.
PS. I would really appreciate if I don't get negative votes for it, but advice instead.
You could try it out side by side in the same site/project. Keep the existing django views. Add new tastypie ones under a different URL, for instance "/api/".
Likewise, a single page app? That is just one new template next to the existing ones. Keep it at "/single/" for the moment. And keep the existing pages.
The actual functionality will probably stay the same. Extract useful code as separate functions out of your existing views and call them from both tastypie and your original views. This will probably even make your existing code clearer and cleaner :-)
I'd say it's much of a philosophical question.
If the site is on a deadline or in production I would probably put it in git and give it two head branches:
production branch
refactor branch
The benefit then is that you can keep the old site up and add new features and merge this in your refactor branch.
Then again it much depends on the complexity and how the site acts today.
Doing the two branch system will give you the option to stop the refactor without losing your old version.
Related
I would like to build a REST Service which exchanges JSON messages with instances of a mobile app for registering patron traffic in physical locations of (public and academic) libraries.
I plan on using Django Rest Framework, and using Django and DRF for the first time, have some questions (rather, recommendation requests). I have read the tutorials and followed some of them, and it looks very promising indeed.
As I am quite confident with Object oriented coding in Python, I will be using class based views. Any reason not to?
The intended usage of the system will include many different libraries with their own ids, users and properties. The data model behind is thus fairly complex, and implemented with MySQL. I feel I will have better control on the data exchange, updates inserts and selects, with custom SQL queries, and would like the DRF to handle mostly authentication and the routing of messages to and from the instances of the mobile app. Is this a misconception on my part, and would it be better to let DRF handle all database-involved aspects?
Given that I follow the custom SQL approach:
As (authenticated) user IDs are interwoven with the rest of the activities (e.g. we would like to know which of the authenticated users stands behind a certain registration of activity), it would seem "simple" to use a single database for both the business model itself and the DRF-controlled aspects. Is it recommended ? Are there any aspects that need to be considered here?
I have not found similar projects to be learning from. Anybody knows a similar project?
I know it is not very concrete, but hope to elevate my understanding a bit while endeavoring on the task.
Michael
I have tried to keep this as unopinionated as possible. Mostly reffering from Django's and DRF's documentation to make sure.
Class based views have some implicit code flows, need method overrides at some places. But since you are quite comfortable with Class based views, it is far more superior in the following ways: cleaner code, much more DRY compliant than function based, easier to extend, keeps your code base more maintainable as it grows.
Django's ORM is pretty powerful and if used correctly it can provide a vareity of capabilities.
Unless your authentication system is very complex and needs to scale independently, having everything in the same DB makes sense. The chatter reduces and you will be able to utilise powerful Django and DRF's features.
I've been learning Django for some time now, and I found this image helpful:
I'm now delving into Angular JS, and I'm trying to figure out how each of the components (Directives, Controllers and Services ?) interacts and if there is a similar 'cycle'. This blog looks like it comes close to answering my question.
But how is the picture different if we have a Django-Rest-Framework end point providing the books in the above example?
Do we want URL resolution from Django, or Angular? Or more answerabley, which takes precedent?
What is the general order that things happen in when we go to say localhost:8000/books ?
Does urls.py catch this?
urls(r'^books',angular_redirect)
If so what does that function (angular_redirect) need to render to get angular to respond?
Does angular routing catch this?
$routeProvider.when('/books', {templateUrl: 'partials/book_partial.html', controller: 'MyBookCtrl'});
So does this mean my controller then registers a service hooked up to say localhost:8000:/book_list.json and does that need to be registered in the urls.py?
How does Angular know where to get the DRF JSON, if we're wholly relying on angular for routing. I've seen this package that lets you use the django models in the angular JS, but I'm not certain if that makes the picture more or less complicated.
Apologies if this is overly broad, I'm very new and trying to get my head round some of the general concepts of these technologies. Any advice on narrowing this question so it's answerable would be appreciated.
Your question has a simple answer: Angular handles the front end and Django (and DRF) handles the back end, and that includes URLs. Users on a fully Angular-powered site should never directly hit a URL that is served by Django, except possibly for the initial page that serves the page structure and JS itself.
Apart from that, the only interaction between the two is when Angular specifically requests JSON from Django, via an Ajax call. That may well be in relation to a navigation event by the user, but just as equally could be triggered on a timed basis or via some kind of websocket functionality.
I've just been approached by my boss about the possibility of white labeling our Django-based site for a new, large customer. Basically, it sounds like it would mainly be changing the graphics/logos on the site. But, I'm sure that at some point they will want to start tweaking the business logic as well. I'm still unclear whether the desire is for it to be a subdomain (e.g. customer.mydomain.com) or a completely new custom domain. Ultimately, it will need to share the database with the rest of the system (for multiple reasons). Is this a good use of the Sites Framework in Django? Or is there a better way of doing this?
More info: Django 1.3.1; PostgreSQL 9.1; Hosted on Heroku
Use a combination of middleware (to set the active site) and context processors (to act on that). You could try to hook into contrib's site framework, but I've always outgrown it rather quickly.
Im still fairly new to Django, so please explain things with that in
mind.
I'm trying to create three websites using 2 subdomains and 1 domain:
for the blog, blog.mysite.com
for the forums, forums.mysite.com
for the custom web app, mysite.com
When building the custom web app, I used contrib.auth to make use of
the built-in django provided user models and functionality.
For the forums, I am planning on using SNAPboard (http://
code.google.com/p/snapboard/) with minimal, if any, modifications. On
initial inspection, it looks like it also uses contrib.auth users.
For the blog, I will probably be rolling my own lightweight blogging
app (since that seems to be the Django way and, also, b/c as Bennet
mentions, there is no killer Django Blog app)
Currently, I am considering two features that require some integration
between the three sites. First, I want to have the users of the custom
web app to use the same account to also log into the forums. Second, I
also (but I haven't figured out how I'm going to do this yet) would
like my blog posts to automatically become a topic for discussion in
the forums (this is just an idea I had, I might end up dropping it).
Ok, so to my questions:
1) Again, I'm new to Django, but this integration leads me to believe
the three websites need to be all under one project. Is this correct?
2) How would I accomplish the url structure for the websites that I
described above (blog.mysite.com, etc)? In the project's urls.py, I
don't know how to filter off of subdomains. If it was mysite.com/
forums/, that would be easy, but I don't know how to to catch
forums.mysite.com and forward it to the appropriate Django app.
3) Would I have to make use of the django.contrib.sites framework? I
don't understand that framework fully, but it seems like it's used
when two different websites are using the same django app in the
background. Whereas my three websites are all using different django
apps, but I want them to share a little bit of data.
Thanks for your help.
1) Yes, it's only true way for that
2) Use middleware
3) No, you don't need it.
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.