Skip to content

Commit 6c27736

Browse files
adamchainzadamchainz
authored
Remove README content (#96)
This was a copy of the content from the documentation, and had drifted out of sync over time because edits happened on one but not the other. I read through the differences and copied what seems to be the only unique change to the README over to the docs in #95.
1 parent cbf5056 commit 6c27736

File tree

2 files changed

+2
-278
lines changed

2 files changed

+2
-278
lines changed

‎README.md

Lines changed: 2 additions & 278 deletions
Original file line numberDiff line numberDiff line change
@@ -1,283 +1,7 @@
1-
# [Django Vanilla Views][docs]
1+
# Django Vanilla Views
22

33
**Beautifully simple class-based views.**
44

5-
**Documentation**: [django-vanilla-views.org][docs].
6-
7-
**Status**: Django Vanilla Views is stable and feature complete. There is unlikely to be much commit activity on the project, but this does not indicate lack of interest or support.
8-
9-
[![Build Status](https://travis-ci.org/tomchristie/django-vanilla-views.svg?branch=master)](https://travis-ci.org/tomchristie/django-vanilla-views) [![Coverage Status](https://coveralls.io/repos/tomchristie/django-vanilla-views/badge.svg?branch=master)](https://coveralls.io/r/tomchristie/django-vanilla-views?branch=master) [![PyPI version](https://badge.fury.io/py/django-vanilla-views.svg)](http://badge.fury.io/py/django-vanilla-views)
10-
11-
View --+------------------------- RedirectView
12-
|
13-
+-- GenericView -------+-- TemplateView
14-
| |
15-
| +-- FormView
16-
|
17-
+-- GenericModelView --+-- ListView
18-
|
19-
+-- DetailView
20-
|
21-
+-- CreateView
22-
|
23-
+-- UpdateView
24-
|
25-
+-- DeleteView
26-
27-
Django's generic class-based view implementation is unnecessarily complicated.
28-
29-
Django vanilla views gives you all the same functionality, in a vastly simplified, easier-to-use package, including:
30-
31-
* No mixin classes.
32-
* No calls to `super()`.
33-
* A sane class hierarchy.
34-
* A stripped down API.
35-
* Simpler method implementations, with less magical behavior.
36-
37-
Remember, even though the API has been greatly simplified, everything you're able to do with Django's existing implementation is also supported in `django-vanilla-views`. Although note that the package does not yet include the date based generic views.
38-
39-
If you believe you've found some behavior in Django's generic class-based views that can't also be trivially achieved in `django-vanilla-views`, then please [open a ticket][tickets], and we'll treat it as a bug. To review the full set of API differences between the two implementations, please see the migration guide for the [base views][base-views-migration], and the [model views][model-views-migration].
40-
41-
For further background, the original release announcement for `django-vanilla-views` is [available here][release-announcement].
42-
43-
## Helping you to code smarter
44-
45-
Django Vanilla Views isn't just easier to use. I'd contest that because it presents fewer points of API to override, you'll also end up writing better, more maintainable code as a result. You'll be working from a smaller set of repeated patterns throughout your projects, and with a much more obvious flow control in your views.
46-
47-
As an example, a custom view implemented against Django's `CreateView` class might typically look something like this:
48-
49-
from django.views.generic import CreateView
50-
51-
class AccountCreateView(CreateView):
52-
model = Account
53-
54-
def get_success_url(self):
55-
return self.object.account_activated_url()
56-
57-
def get_form_class(self):
58-
if self.request.user.is_staff:
59-
return AdminAccountForm
60-
return AccountForm
61-
62-
def get_form_kwargs(self):
63-
kwargs = super(AccountCreateView, self).get_form_kwargs()
64-
kwargs['owner'] = self.request.user
65-
return kwargs
66-
67-
def form_valid(self, form):
68-
send_activation_email(self.request.user)
69-
return super(AccountCreateView, self).form_valid(form)
70-
71-
Writing the same code with `django-vanilla-views`, you'd instead arrive at a simpler, more concise, and more direct style:
72-
73-
from vanilla import CreateView
74-
from django.http import HttpResponseRedirect
75-
76-
class AccountCreateView(CreateView):
77-
model = Account
78-
79-
def get_form(self, data=None, files=None, **kwargs):
80-
user = self.request.user
81-
if user.is_staff:
82-
return AdminAccountForm(data, files, owner=user, **kwargs)
83-
return AccountForm(data, files, owner=user, **kwargs)
84-
85-
def form_valid(self, form):
86-
send_activation_email(self.request.user)
87-
account = form.save()
88-
return HttpResponseRedirect(account.account_activated_url())
89-
90-
## Requirements
91-
92-
* **Django**: 1.8, 1.9, 1.10, 1.11, 2.0, 2.1
93-
* **Python**: 2.7, 3.4, 3.5, 3.6
94-
95-
## Installation
96-
97-
Install using pip.
98-
99-
pip install django-vanilla-views
100-
101-
## Usage
102-
103-
Import and use the views.
104-
105-
from vanilla import ListView, DetailView
106-
107-
For example:
108-
109-
from django.core.urlresolvers import reverse_lazy
110-
from example.notes.models import Note
111-
from vanilla import CreateView, DeleteView, ListView, UpdateView
112-
113-
class ListNotes(ListView):
114-
model = Note
115-
116-
117-
class CreateNote(CreateView):
118-
model = Note
119-
success_url = reverse_lazy('list_notes')
120-
121-
122-
class EditNote(UpdateView):
123-
model = Note
124-
success_url = reverse_lazy('list_notes')
125-
126-
127-
class DeleteNote(DeleteView):
128-
model = Note
129-
success_url = reverse_lazy('list_notes')
130-
131-
132-
## Compare and contrast
133-
134-
To help give you an idea of the relative complexity of `django-vanilla-views` against Django's existing implementations, let's compare the two.
135-
136-
#### Inheritance hierarchy, Vanilla style.
137-
138-
The inheritance hierarchy of the views in `django-vanilla-views` is trivial, making it easy to figure out the control flow in the view.
139-
140-
CreateView --> GenericModelView --> View
141-
142-
**Total number of source files**: 1 ([model_views.py][model_views.py])
143-
144-
#### Inheritance hierarchy, Django style.
145-
146-
Here's the corresponding inheritance hierarchy in Django's implementation of `CreateView`.
147-
148-
+--> SingleObjectTemplateResponseMixin --> TemplateResponseMixin
149-
|
150-
CreateView --+ +--> ProcessFormView --> View
151-
| |
152-
+--> BaseCreateView --+
153-
| +--> FormMixin ----------+
154-
+--> ModelFormMixin --+ +--> ContextMixin
155-
+--> SingleObjectMixin --+
156-
157-
**Total number of source files**: 3 ([edit.py][edit.py], [detail.py][detail.py], [base.py][base.py])
158-
159-
---
160-
161-
#### Calling hierarchy, Vanilla style.
162-
163-
Let's take a look at the calling hierarchy when making an HTTP `GET` request to `CreateView`.
164-
165-
CreateView.get()
166-
|
167-
+--> GenericModelView.get_form()
168-
| |
169-
| +--> GenericModelView.get_form_class()
170-
|
171-
+--> GenericModelView.get_context_data()
172-
| |
173-
| +--> GenericModelView.get_context_object_name()
174-
|
175-
+--> GenericModelView.render_to_response()
176-
|
177-
+--> GenericModelView.get_template_names()
178-
179-
**Total number of code statements covered**: ~40
180-
181-
#### Calling hierarchy, Django style.
182-
183-
Here's the equivalent calling hierarchy in Django's `CreateView` implementation.
184-
185-
CreateView.get()
186-
|
187-
+--> ProcessFormView.get()
188-
|
189-
+--> ModelFormMixin.get_form_class()
190-
| |
191-
| +--> SingleObjectMixin.get_queryset()
192-
|
193-
+--> FormMixin.get_form()
194-
| |
195-
| +--> ModelFormMixin.get_form_kwargs()
196-
| | |
197-
| | +--> FormMixin.get_form_kwargs()
198-
| |
199-
| +--> FormMixin.get_initial()
200-
|
201-
+--> ModelFormMixin.get_context_data()
202-
| |
203-
| +--> SingleObjectMixin.get_context_object_name()
204-
| |
205-
| +--> SingleObjectMixin.get_context_data()
206-
| |
207-
| +--> SingleObjectMixin.get_context_object_name()
208-
| |
209-
| +--> ContextMixin.get_context_data()
210-
|
211-
+--> TemplateResponseMixin.render_to_response()
212-
|
213-
+--> SingleObjectTemplateResponseMixin.get_template_names()
214-
|
215-
+--> TemplateResponseMixin.get_template_names()
216-
217-
**Total number of code statements covered**: ~70
218-
219-
## Example project
220-
221-
This repository includes an example project in the [example][example] directory.
222-
223-
You can run the example locally by following these steps:
224-
225-
git clone git://github.com/tomchristie/django-vanilla-views.git
226-
cd django-vanilla-views/example
227-
228-
# Create a clean virtualenv environment and install Django
229-
virtualenv env
230-
source env/bin/activate
231-
pip install django
232-
233-
# Ensure local copy of 'vanilla' is in our path
234-
export PYTHONPATH=..:.
235-
236-
# Run the project
237-
python ./manage.py migrate
238-
python ./manage.py runserver
239-
240-
Open a browser and navigate to `http://127.0.0.1:8000`.
241-
242-
Once you've added a few notes you should see something like the following:
243-
244-
![image](example.png)
245-
246-
---
247-
248-
## License
249-
250-
Copyright © 2013-2016 Tom Christie.
251-
252-
All rights reserved.
253-
254-
Redistribution and use in source and binary forms, with or without
255-
modification, are permitted provided that the following conditions are met:
256-
257-
Redistributions of source code must retain the above copyright notice, this
258-
list of conditions and the following disclaimer.
259-
Redistributions in binary form must reproduce the above copyright notice, this
260-
list of conditions and the following disclaimer in the documentation and/or
261-
other materials provided with the distribution.
262-
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
263-
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
264-
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
265-
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
266-
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
267-
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
268-
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
269-
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
270-
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
271-
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
5+
Please see the documentation at [django-vanilla-views.org][docs].
2726

2737
[docs]: http://django-vanilla-views.org
274-
[twitter]: http://twitter.com/_tomchristie
275-
[tickets]: https://github.com/tomchristie/django-vanilla-views/issues
276-
[base-views-migration]: http://django-vanilla-views.org/migration/base-views
277-
[model-views-migration]: http://django-vanilla-views.org/migration/model-views
278-
[release-announcement]: http://dabapps.com/blog/fixing-djangos-generic-class-based-views/
279-
[model_views.py]: https://github.com/tomchristie/django-vanilla-views/tree/master/vanilla/model_views.py
280-
[base.py]: https://github.com/django/django/tree/master/django/views/generic/base.py
281-
[detail.py]: https://github.com/django/django/tree/master/django/views/generic/detail.py
282-
[edit.py]: https://github.com/django/django/tree/master/django/views/generic/edit.py
283-
[example]: https://github.com/tomchristie/django-vanilla-views/tree/master/example

‎example.png

-26.2 KB
Binary file not shown.

0 commit comments

Comments
 (0)