Salut friends,
I have been working with Django on a project for over a year now, and this project doesn't quite have forms (just a few). The way it is done is without Django Rest Framework, simple crispy forms, which are validated when the POST arrives at the corresponding view.
A month ago, I started to work on a different project, much bigger, that in the greatest part relies on forms. This project uses Django Rest Framework, serializers + viewsets, and renders forms through DRF serializers.
After attaining a certain understanding of all the validations that can be done with DRF serializers, I started to imagine it'd be a good idea to bring serializers and viewsets to my older project in order to enjoy the better structure offered by DRF.
Here is my question: Can (crispy) forms and serializers work well together? Is it better to render my forms with DRF if deciding to stick with DRF? I saw a couple of people who use both, but it is unclear to me at this point. Is there a more standard way to do so, which is used by a majority?
Thanks!
I use DRF with Crispy Forms, I started doing so from the start of using DRF because they recommended it in their documentation...
Requirements REST framework requires the following:
Python (2.7, 3.2, 3.3, 3.4, 3.5)
Django (1.8, 1.9, 1.10)
The following packages are optional:
coreapi (1.32.0+) - Schema generation support.
Markdown (2.1.0+) - Markdown support for the browsable API.
django-filter (0.9.2+) Filtering support.
django-crispy-forms - Improved HTML display for filtering.
django-guardian (1.1.1+) - Object level permissions support
Related
I understand that django is an MTV architecture. I also understand that M is models, T is templates (which are views in MVC) and V is views (which are controllers in MVC).
I want to understand if the django serializers and views are views or templates according to the MTV when using Django Rest Framework.
There's no perfect 1:1 mapping there.
A DRF serializer is vaguely like a template in that it describes how the data should be serialized "onto the wire" when a DRF view outputs it, but unlike templates, serializers can also be used for data ingestion.
DRF views (and viewsets, which group views) map to MVC controllers or Django views in that they describe how the API endpoint works.
A DRF app doesn't necessarily need to work with Django models at all, but if it does, that bit is unchanged from how Django works.
The DRF tutorial includes the following line about DRF serializers vs Django forms:
The first thing we need to get started on our Web API is to provide a
way of serializing and deserializing the snippet instances into
representations such as json. We can do this by declaring serializers
that work very similar to Django's forms.
But from what I can see, it says nothing else about the relationship between forms and serializers.
Since DRF doesn't need the Forms' ability to render a model in a template, is it fair to assume that Forms have no purpose in DRF, and that serializers can handle all of the validation traditionally completed with forms?
If so, when I'm building an API, can I forget about templates and forms entirely?
Django REST Framework is used for creating REST API's which send XML or JSON.
Django Forms is used for creating HTML forms based on a given model.
As the role of an API generally doesn't involve sending HTML, Django forms would not be used.
I'm learning Django on Ubuntu 13.04, Python 2.7, Django 1.5, Postgres 9.2,
Bootstrap 3.0. I'd like to achieve a combination of the tutorial example Polls app with django-authentication.
As my first effort I got the Polls app working from the Django 1.5 tutorial. I then installed django-registration 1.0 and these templates to make it work. I chose that package for authentication as opposed to django-allauth as a result of my question on authentication framework.
Now I want to integrate Polls and django-registration to record a set of results per user. After the poll results have been collected the admininstrator uses Django Admin interface to run a script to analyse the results (e.g. compute some statistics) and send an email to a subset of all users.
I briefly looked at two existing projects that looked like could get me there out of the box.
Light Bird's Questionnaire App was too complicated using a custom library of modular class based views. I'd like to keep it as simple as possible, using as much of out-of-the-box Django 1.5 functionality as possible for ease of maintenance and initial design.
Pinax web framework on top of Django, although a great idea, seems to be stuck in dark ages of 2011 with latest code supporting only Django 1.4 and Bootstrap 2.x. Starter projects don't look that useful and documentation isn't flash either.
Based on the above it looks like I'll have to do the integration of Polls and registration manually. At first pass I was thinking roughly the following:
The poll & choice could be simplified down to just a numeric answer to a question.
At database level we would need a separate table.
The primary key would be the userid.
Each column would store one answer per.
I'm guessing this would need a class PollsResults in model.py that would include defining the primary key as User, which should exist via django-registration.
Exactly how to do that and what follows gets a bit hazy to me at the moment.
I'm sure the above is a simple exercise for a Django developer. Could anyone give me some starting hints or even better an existing project that does something similar?
It looks like you're slightly underestimating the power of using a framework such as django. For example, you don't really need to worry too much about tables in the database or what will be their primary keys, because django's Object Relational Mapper (ORM) takes care of a lot of that for you.
If you want to connect two models (database tables) in django you can use a foreignkey like this:
class ThingOne(models.Model):
name = models.CharField(max_length=50)
class ThingTwo(models.Model):
thing_one = models.ForeignKey('ThingOne')
The quotes around 'ThingOne' in my ForeignKey are actually unnecessary because the ThingOne model has already been defined, but I like to use quotes anyway because it means your ForeignKeys will also work for models defined below (in your code) the model linking to them.
You therefore just need to add a relationship between your Polls and User models. If one user might have many poll results you should probably use a ManyToManyField instead of a ForeignKey but the principle is the same. That should be enough to get you started.
I have read under SDK release notes 1.7.3 that GAE supports Django 1.4. I know that Django models can't be used in GAE as we have Google's own models. But what about Django Form API, particularly displaying a form using a template? Can that be used in SDK 1.7.4?
Yes, of course you can use the form API and display it in the template. But what you can't do with plain Django on GAE is build a modelform automatically from a db.Model or ndb.Model. You have to use plain forms, defining the fields and setting the data back to the model entity manually.
While you can't use django model forms, GAE provides a forms library that provides similar functionality for db.Model based models.
https://developers.google.com/appengine/articles/djangoforms
I'm not sure if there's an equivalent for ndb.
I have been looking at the documentation on django nonrel but think i have confused my self.
I have a project using the setup instructions found at http://www.allbuttonspressed.com/projects/djangoappengine#installation and continued to setup a django application. I am making a simple news feed. Now it has come to create the models but there appears to be two ways of doing this, using models.Model or db.Model.
models.Model is the django way of doing it, and if I create a model using this it appears to use nosql, this also allows me use of the built in admin.
db.Models is the non-rel way of doing things. If I create the model using this is appears to use nosql again but this method does not let me make use of the django admin. I thought the point of django non-rel was to let me make use of the admin and a majority of the default functionality in django.
I would also like to ask what is the difference between django non-rel and pure django on app engine and how does this affect how the models are created?
This is incorrect:
db.Models is the non-rel way of doing things
Where did you get this idea? db.Models is the AppEngine way of doing things. django-nonrel allows you to use the Django way even though you're on AppEngine. As you say, the point of django-nonrel is to allow you to use the admin etc, for which you need to do things the Django way, ie models.Model.