Subclassing and overriding Django Class based views - python

I'm building a website using django-all auth for it's authentication and social authentication functions. The forms that come bundled with the app are hardly great to look at and hence I decided to create my own views.
The problem is: How do I create them while ensuring that the backend of Django all auth is still available to me? I've dug into the source code and found that it uses class based views for rendering and performing CRUD operations.
I want to know if I can subclass those views in my own app/views.py and just change their template_name field to my own templates. Any advice would be most helpful.
Thanks.

You can of course subclass the views, as long as you change your URLs to point to the overridden versions. However, there is no need to do this just to use your own templates; Django's template loader is specifically written with this use case in mind. Simply create your own directory inside your templates folder to match the one allauth is using, and create your own template files inside it; Django will find yours first and use them.

Related

Django Practice to organize views that have same permission

The login_required, user_passes_test and permission_required decorator only apply to specific functions, similar for the mixin. But is it a good practice to put #permission_required('polls.add_choice') to each and every view that require such permission?
I think it is quite common that multiple views have the same permission. For example, you have an employer and job seeker, only the employer can add company name/ address, post a job and check job application. It is also common that the website requires login for most of its pages.
So my question is what is the idioms/practice assigning the same permission to multiple views? The only recipe I can find is Beginning Django - Listing 10-8. Permission checks in urls. Pay for include () definitions. Another approach is to swap the view function inside a class (as static method) and do some trick the add permission to all methods.
Is there any better sulotion? Or any reason not to do that?
I think that in this case it is most ideal to use Django's groups system.
It's totally ok to use same permission for several views because in some cases there is more views than the 4 CRUD views and 2 views can be intended to same user/rule/groups.
It also depends on number of online users of your site.
It there are thousands of users online - try to cache that wrappers.
or rewrite all to api

Django: generate python code from command line

Is here a way to write a Django command to generate code automatically?
In my case: every time I create a new model I must create the following stuff too:
Create Administration classes in admin.py
Create service functions related to this model.
Create a factory using FactoryBoy.
Create test classes.
It would be nice if there was a command that generates this stuff automatically. Not everything, of course, but just the basic, the definition.
Is there something like this today in Django? Or is there a way I can write Django commands to generate code?
I have not personally used it yet but you could try to use the third-party package
Django baker Django Baker that offers that functionality
Django Baker wants to help you get your projects up and running
quickly. Given one or more app names, s/he will automatically generate
views, forms, urls, admin, and templates for all of the models in the
models.py file. All files are pep-8 compliant (with exception to the
maximum line length rule, which I don't agree with).
Once you add a single urlpattern to your project's URLconf, you'll
have a working list view, detail view, create view, update view, and
delete view for each model in your app.
Optionally you may specify which models in an app to bake if you'd
rather not generate files for all of them.
Try django commands and jinja2 templates.
With the execution of custom defined command, set of file templates can be updated with appropriate content and copied to respective folders as per need.

Using custom forms in Django instead of modifying the source files

Let me preface this by saying I'm VERY new to Django and am also having a hard time with some of the documentation. I know that this question has surely been asked and answered a thousand times, but I can't seem to phrase my query properly.
I'm making a project that uses django-registration-redux, and I wanted to customize the template and the forms to accept additional user information. First, I noticed that my changes to the template files weren't having any effect , then I realized that it was using the template files from my Python install location instead of my actual project. I fixed this by setting the templates folder setting, but I also need to modify the registration-redux forms, and can't figure out how to override the default forms with local forms in my application.
You need not change the template settings for your existing project, but you have to make sure you have included 'registration' in the list of your INSTALLED_APPS. In the documentation its mentioned that
You can extend and customize the included templates as needed
Though its not very clear here, django registration redux is built on top of the in built django registration module. What you need to do is build your own custom registration form which is already explained in this answer.
In your case the template that you need to modify/extend is registration/registration_form.html.
Other useful resources that can help you:
http://www.tangowithdjango.com/book17/chapters/login_redux.html
https://www.youtube.com/watch?v=qkFWkOw-ByU

Django Pinax , extending bundled applications

I want to use Pinax for a small project , but I am confused because I don't if can extend/change the behavior and functional of the provided applications .
Is there any documentation for extending the behavior of the bundled applications ?
example: in registration application ,I want to add custom fields but I am not able to find proper documentation on how to achieve it..( mainly for those which need db changes )
Thanks !
Yes, you can extend the behaviour of the built-in applications. If you are using the pinax basic setup with user accounts and profiles, you will have to add the extra fields you want in apps/profiles/models.py. For a list of field types, see here: https://docs.djangoproject.com/en/1.3/ref/models/fields/
This will create the necessary db fields for you when you run manage.py syncdb. If you have already sync'd the db, however, you will have to manually add the db columns. If you don't have any data you care about in that table, you can always just drop the table and it will recreate it. Django doesn't modify db tables once they are created, even if you change the model.
You will also have to modify the signup form to include these new fields and point your urls.py to the new signup form you created. Copy the form from the site-packages/pinax directory to your project. Don't modify them directly.
If you haven't already, you should check out the Django tutorial here: https://docs.djangoproject.com/en/1.3/intro/tutorial01/
This will give you a good idea of how Django apps are put together and how the different pieces interact, so you can do a better job customizing Pinax to your liking. Make sure you know what models.py, urls.py, views.py, and the templates are doing.

Django, how to generate an admin panel without models?

I'm building a rather large project, that basically consists of this:
Server 1:
Ice based services.
Glacier2 for session handling.
Firewall allowing access to Glacier2.
Server 2:
Web interface (read, public) for Ice services via Glacier2.
Admin interface for Ice services via Glacier 2.
The point I'm concerned with is the web interface. I want to use Django, because it's both written in python and has that incredibly useful automatic admin panel generator.
The web interface doesn't access any database. It connects to an Ice service on Server #1 via the Glacier2 router and uses the API exposed by those services to manipulate data.
And as you probably know, the admin generation in Django depends on the use of Django's ORM; which I'm not using since I have no database to access.
So I need to generate the admin panel, but, instead of having an standard data access like the ORM normally does, I need to intercept any "db-access" calls and transform them into Ice service calls, and then take the service's output (if any), transform it into whatever the ORM normally returns and return control to Django.
Anyone knows how I could do this? what would I need to subclass? Any specific ideas?
Thanks for your time.
I think there might be a simpler way than writing custom ORMS to get the admin integration you want. I used it in an app that allows managing Webfaction email accounts via their Control Panel API.
Take a look at models.py, admin.py and urls.py here: django-webfaction
To create an entry on the admin index page use a dummy model that has managed=False
Register that model with the admin.
You can then intercept the admin urls and direct them to your own views.
This makes sense if the add/edit/delete actions the admin provides make sense for your app. Otherwise you are better off overriding the admin index or changelist templates to include your own custom actions
The real power of the contrib.admin is django Forms. In essence, the admin tool is basically auto-generating a Form to match a Model with a little bit of urls.py routing thrown in. In the end it would probably just be easier to use django Forms apart from the admin tool.
you can "mock" some class so it look like a model but it does proxy to your APIs
f.e.
class QuerysetMock(object):
def all():
return call_to_your_api()
[...]
class MetaMock(object):
def fields():
return fields_mock_objects..
verbose_name = ''
[...]
class ModelMock(object):
_meta = MetaMock()
objects = QuerysetMock()
admin.site.register(ModelMock)
This may work.. but you need to do a lot django.model compatible stuff
The django ORM has a pluggable backent, which means that you can write a backend for things that aren't RDBMSes. It's probably a rather large task, but a good place to get started is with Malcolm Tredinnick's talk from DjangoCon 2008, Inside the ORM.
Otherwise, you could bypass the ORM altogether, and write the forms manually for the access you need.

Categories