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.
Related
It's been a while since I last used Django for a project and there have been some really great advances in the core project and the ecosystem around it.
One of those is the mature API development libraries like django-rest-framework.
So far I'm loving it. But it seems that all the guides I've found are disabling the Django Admin when using Django Rest Framework.
The reasons I've seen given were essentially "We don't need it for anything" or "We aren't using sessions, which Admin uses, so it won't work, so we're not using it."
"Don't need it" is a valid reason.
But other than that, are there reasons that it's bad practice to keep the Django Admin enabled when the project is primarily used as an API?
For my purposes, I find it convenient to manage user permissions and as a simple way to code admin only functions for dealing with the underlying data.
note: I've considered whether this question is designed to elicit opinions, which is not appropriate on SO. I believe that the answers I'm asking for will be technical or security based reasons with fact or experience based reasoning.
Totally agree.
On my current project, users are getting and setting ALL data via django-rest-framework.
Like you, I find the admin site convenient to manage user permissions, permissions groups, writing emails, sms, mobile applications push and more.
More, all these models are being translated, and translation is set in THE ADMIN SITE !!!
So, if we need a new object with translation, we do not need a new app release (example in pic of a question).
objects translations are readable and clear.
Data is organized nicely with minimal effort.
Admin get cool skins (jet / grappelli etc etc)
Language activation works like a charm in the APIViews.
Following this post (I was looking for a library allowing me to declare Django models on a ldap backend), I have decided to use ldapdb. After having played a while with this library, I figured out that it doesn't reach the level of control I need, and I am therefore looking for other solutions. What I am thinking of now is implementing a Django db backend based on python-ldap.
EDIT
I need this because I am currently implementing a user/group management system on a ldap directory (it requires to be able to manipulate not only users, but different classes of ldap objects as well). So basically, I would like to be able to use (nearly) full Django orm, but with a ldap backend.
Because I love Django (and would be rather motivated in learning the dirty low-level details of db.backends), and because there's already a lot of things implemented in this project, I would like to stick to Django (unless somebody has a very good reason why I shouldn't, and a very good alternative !).
Do some of you have a simpler solution to this problem ?
Do some of you know about an implementation of such a thing (ldap db backend) ?
Do some of you know some good reads to get started on "implementing a Django db backend"?
Are some of you interested in helping with this project ?
You make a lot of bold statements such as "lots of things broken because of the way it is implemented" and "the subclassing is very very far from being complete", would you care to elaborate on them? As the author of django-ldapdb I would welcome your suggestions as to what you would like changed/fixed, that's what the django-ldapdb mailing list is for!
FYI, I took the approach of subclassing the Model class because you will usually want to have just a couple of models using the LDAP backend, not all the models in your application, and django 1.1 did not support multiple databases. Also, LDAP is very different from existing SQL backends:
is not a relational database
it is not "flat", it is a tree-like
the true "primary key" for an entry is the Distinguished Name (DN), which is not an actual field, but a value computed from other fields
fields can be multi-valued
For all these reasons, I have serious doubts as to what can be achieved by writing a true LDAP backend. I think you will always have some LDAP-specific quirks, and subclassing Model allows just that.
Your best bet is probably to write an authentication backend for the application. Here is some documentation about it:
http://docs.djangoproject.com/en/dev/topics/auth/?from=olddocs#writing-an-authentication-backend
And here is an article that explains how to extend the User model to enable you to use this authentication backend seamlessly:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/
Seems like there's no really good solution. And doing everything without Django's ORM is no good solution either.
I'll make new attempt at solving that problem soon, with a django-orm-based solution.
I've been successfully using Django's admin panel for internal users for a while but I recently hit a brick wall while trying to customize it and I'm curious if I'm spending too much time on it. So, my question is:
Is Django's admin panel intended to just be temporary scaffolding, that is, to be used only during the initial development of the application and to be replaced by custom code similar to Rails' scaffolding?
Obviously by using the admin panel I get a lot of functionality for free and as new features are added I get those for free too. What do other people do?
I wouldn't say the admin is meant to be temporary scaffolding but it might not be the best choice for many cases. I've worked with a very large and well known media company that used the admin as the basis for the entire workflow interface for its producers and editors. Unfortunately, your decision making process about when or when not to use the admin will benefit largely from your overall knowledge about the internals of Django; you'll probably get stuck a few times before you gain the experience to know when not to get stuck. :p
The "customizability" of the admin can be somewhat subjective. I've seen teams bend it to their will but it also requires a pretty good working knowledge of the lower level-details of Models, Forms (and naturally things like ModelForms and FormSets), and templates. I think a lot of the conventional wisdom and best practices hasn't yet surfaced into organized documentation. Be prepared to do a lot of digging around in the source code. The good news is that you'll probably come away with a much deeper understanding of how to take advantage of some of the first-class entities in the framework. The bad news is your boss probably won't be happy that it took you most of a day to change single input on a form.
Recent enhancements have made it easier to place your own views under the admin URL space so you might consider an approach of writing your own views to suit your needs and sprinkling in links in appropriate places within the standard admin pages. I generally advise people who are newer to Django or who are just getting into admin customization to strongly consider just rolling your own administrative views. After all, Django already makes it ridiculously easy to create CRUD style apps and you won't have to feel like you're fighting against a rigid system whenever you want to change presentation or behaviors.
Django Admin is for things where there's no value in doing anything more than the default add/change/delete processing it offers.
Databases are full of lookup and administrative tables. The zip-code to state mapping, for example, that no end-user should see. The log of background batch job executions.
Your app will probably have some tables which are these sort of more-or-less "administrative" -- someone maintains them, but not the large community of users.
Your app will probably have some tables which are for end-users to add/change/delete. You might want to provide extensive customized pages for this activity.
Django grew up in the news business. Writers and editors prepare data (using the admin interface). Customers read the data through customized web pages.
We have administrative staff that use the admin pages. We have customized pages for our customers. We use both.
We provide default admin pages on almost everything to our internal admins. We provide default admin on selected tables to customer-side admins. And we provide carefully crafted application-specific pages for our customers.
I asked a similar question about 6 months ago when I was first starting out in Django.
Is it worth it using the built-in Django admin for a decent sized project?
For that particular application I opted not to use Django admin, and that was a very smart decision in hindsight. Since then, I've generally not used it, but sometimes there are situations when it's great. For me, it really depends on the users. If we are building a custom data-driven app for a client and are working off a feature set provided by them, I would never want to use the Django admin. In those cases, almost certainly they will have changes that could be a real pain to try to get working in the admin. And if it's an evolving project, these changes will become more and more of a hack and you'd probably end up having to start ripping out pieces into non-Django admin parts of the site, at which point there are now two interfaces for doing stuff.
However, if the clients are more of the mindset of accepting the way the app works, then the Django admin would be fine, assuming there's generally a 1:1 correspondence between your tables and the data they're dealing with.
As Brian Luft said, it's really easy to create interfaces for CRUD apps, so if you sense you'll need any customization in the future, it might be easiest just to write your own from the start. You can always keep the django admin around for your own needs as a super-user. That's usually what I do, so I can easily have table-level access to change fields that might not be shown in the normal user admin.
No, I wouldn't compare it to Rails' scaffolding. It's not clear from your question what kind of issues you are running into-- can you provide an example?
There's a lot of customization you can do to the admin by adding custom ModelAdmin classes: hide fields, show additional fields, allow for editing of related-items on the same page or limit/ filter the options that appear in a foreign key field. You can also make things easier for users to find by adding sorting, filters to the front page, search fields. Newer versions of Django also let you create your own custom commands that can be applied to multiple objects at once.
But if the problem isn't with the basic change list and edit form, you can completely customize those by creating model-specific templates and overriding the default admin templates.
No, you can for sure use it for administrating your site, but as Django says; only for trusted users. So if you create a cms, its great. Because (hopefully) the back end users will be trusted users!
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.
I haven't been using Django too long, but I'm about to start a pretty hefty-sized project. I'm always nervous using fairly new frameworks (new to me) on large projects because I've been burned before. However, I'm pretty confident in Django...this will finally be the project that makes me leap from my home-grown PHP framework to a popular Python framework. (yay!)
Anyway, my question is whether or not the built-in Django admin is robust enough to use for a fully-fledged customer-facing interface (the clients will be using it themselves, not me). I see that it's pretty customizable, but I'm wondering if extensible enough to handle various non-standard cases. I don't have any concrete examples yet since I haven't started yet.
Has anyone used the Django admin for some pretty customized interfaces that non-programmer users use? Was it worth it? Would you rather have just created a home-grown admin interface specifically for the site?
Just to clarify, the users would be completely non-techy.
If I understand it correctly, you want to use the django admin for all users, to let them update the site.
If this is true, I think you may be using it in a different way from what was its main purpose, as you can get from the Django book (emphasis is mine):
For a certain class of Web sites, an
admin interface is an essential part
of the infrastructure. This is a
Web-based interface, limited to
trusted site administrators, that
enables the adding, editing and
deletion of site content.
If your users need to update content (like, let's say, adding a new article) then it may be OK.
But if you want to use it for any site interaction, then I think the user experience will not be as good.
I think a very nice example of how the admin can be used, and when it should not be used is in ReviewBoard: there, most of user actions are handled directly by the site, and only the configuration and management are then handled using the admin.
In the end, it is a matter of usability. If you think that it is OK for your application to have a different section to manage addition to the site, then Django's admin site may be a real time saver. In all other cases, maybe it is better to invest some time more.
My company has built a CMS on top of Django that handles numerous tasks (flat pages, blogs, members-only sections, importing and parsing data from external sites like youtube and flickr, mailing lists, albums songs and lyrics for artists, etc.) and so far we're still using the built-in admin. We have several very non-technical clients using it regularly.
You can go pretty far in customizing it with the admin.py files when you really get into it. The only things we've added are tinyMCE and Filebrowser to make those aspects easier for the end users.
I will say that we are working on a gallery module that is going to need a custom admin, though. Otherwise I've been pretty happy and impressed with how flexible and powerful Django's admin can be. And it's as user-friendly as you can think to make it.
It depends. The admin will let you customize quite a bit, with different groups of users having access to different tables, and if you give them access to different admin interfaces, you can even give them different sets of columns available on the tables. However, the admin isn't really set up to let you restrict users' row level access based on their authorization level. Once you've let them into a table, they can make changes to any object available to them.
You can customize widgets however you like by subclassing widget types (though the built-in filter_horizontal and raw_id_admin are indispensable and make this task simple for certain data types!)
So I guess it depends on what you mean by customers. If you mean the people who hired you to write the website (I think I'd call them clients rather than customers), then there's a good chance the admin will suit you just fine. If you mean the end users of a website, I would stick with hand-crafted django forms.
In general I view the Django admin as an interface to performing the tedious tasks of insert delete and editing. So, I'm not afraid of customizing it to a large extent (even if this means subclassing internal Django objects and passing them back to the admin interface at runtime), but be aware it will require you to read Django source (which fortunately isn't very hard to do).
So for me, the discriminator of using it or not is "insert, delete, update" of concepts that map very well to the database tables, not amount of user technical knowledge, amount I trust the users, or project size.