Django's auth messages look pretty handy for notifying a CMS user of some configuration problem. The thing is that the messages are deleted on every page load if you include the "django.core.context_processors.auth" context processor, and you have to include that processor if you want to use the admin interface.
I tried hacking around it by adding that processor to TEMPLATE_CONTEXT_PROCESSORS just after matching the admin url / before calling admin.site.root, but it appears that it's already imported the list of processors by that time.
So is there any way to do this without changing any of the Django core files themselves, and without omitting the django Auth app from your config entirely until the last possible moment?
If the Django message system was critical for my site I would add the messaging into my views with, for example:
integration with Growl
some javascript modal dialog like jQuery Alert Dialogs
If you really need to hack it so they only show in admin pages then the easiest solution would be to copy the auth function in django.contrib.core.context_processors.py and put it into a context_processors.py in your own application directory. Use it in the CONTEXT_PROCESSORS stack instead of the django.core version and modify it so it looks at the REQUEST url and only calls user.get_and_delete_messages() if it is the admin url.
Related
Is there a way to deploy Django Admin and your main application separately, though both of them sharing the same Models / Business logic services.
I come from Grails background where you can create a plugin which can hold your Entities and common business logic and that plugin can be utilized by other application deployed and scaled separately though using the same Database. You don't have to repackage your plugin again for every change rather its just sibling folder to your other projects.
Can I achieve something similar with Django?
Assuming a typical setup, in order to be useful Django Admin needs access to project's apps and their models.
So a setup that you've described would require at least:
simple URLconf with just Django Admin
models and their Admin bindings for all apps that need Admin
settings with database credentials
Even if your models and Admin bindings are not dependent on other parts of the codebase,
extracting the above components to a separate project and then keeping everything
in sync sounds pretty hard.
Summarizing: I would say it's hard but possible if it's something that you really need,
but Django Admin hasn't been designed with such use case in mind.
Django admin is actually separate from the main application by placing it on its own url. Even if they know the admin url, users cannot log in to the site's admin unless they have already been assigned Staff status via the admin. You can set the admin prefix to anything you want, so if you want to "hide" the admin login page, just make it something long and random (good for security too), and basically no one but those you tell will even know where the admin site can be found.
Im really confused about what is all i need to consider for creating a django aplication with almost similar functionality to it's own admin.
The index page should deploy the list of models the user has access to modify or create...almost the same as when you put admin.site.register(MyModel) but with permission restriction. Im not sure how should i ckeck permissions, and show 1 ,2 or many "ModelAdmis" on my main page.
btw admin users are redirected to the admin index page, non-admins go to my page
Before you consider creating a django admin from scratch, you should read the answers to this question Django Admin app or roll my own?
I couldn't find any resource on how to create a django admin from scratch, but here's what you should do if this is your first time overriding a framework's functionality (in my humble opinion):
Understand and make sure you are comfortable with the django admin app
start from the docs https://docs.djangoproject.com/en/1.7/#the-admin
Head over to the django admin app source code so you can start reading the internals of the functionality you want to implement/override in your new admin app.
source code can be found here https://github.com/django/django/tree/master/django/contrib/admin
(this may involve reading other apps source code too)
After those two steps you should have an idea on how the admin app is implemented and it's dependencies, then you can start creating your custom admin app.
an example on how this may go can be found in this qestion:
How to override Django admin's views?
If you are building something new, try to separate the UI from the backend. You can build your UI using react, angular or whatever and interact with django using the API. To build the API you can use the Django Rest Framework.
Don't use the Django Admin as a public interface. Use that only for the admins!
If you start to use the Django Admin as interface for your public site, you'll fight with the package to tailor and secure the views to avoid destructive actions. What happen if you forget a readonly field? What if the user deleted something ON_CASCADE?
Building the UI you are totally free and you can customise easily everything without fighting the django admin package (it's awesome package but is not provided for public use)
I'm currently using out-of-the-box django.contrib.auth to handle authentication in my Django app. This means that the user starts at a log in page and is redirected to the app on successful login. I would like to make my app single-page, including this login process, where a redirect doesn't happen, but maybe a "hot" template switch-out or some fancy client-side div magic (that still remains secure). My Google searching turned up pretty short, the closest solution dealing with putting a log in form on every page.
Any direction or ideas here would be much appreciated. I would obviously prefer to work within the existing confines of django.contrib.auth if possible, but I'm open to all solutions.
I'm not sure I understand your question completely. I think you want to have a single page. If so, put logic in your template that checks to see if the user is authenticated. If not, display a login form that POSTS to the appropriate django.contrib.auth view. You can supply an argument to this view to have it redirect back to your page. When you come back, the user will be authenticated, so you won't display the login form.
Have a look at Django-Easy-Pjax https://pypi.python.org/pypi/django-easy-pjax - it works like a charm and is well documented. Everything you like is being made with AJAX requests: links, forms using GET and forms using POST.
Essentially you only need to add a data-pjax="#id_of_the_container_where_the_result_goes" attribute in your a and form tags.
And the great thing about it: It updates the title and location bar of your browser.
One caveat: If you want to upload files in some form, this is not supported by Easy-Pjax, so you might want to use some workaround jQuery library for that.
a newbie django question
I want to use 3rd party app, but I need to make some mods to it (in this case, the app is django-registration, and I need to change things such as allowing registration without confirmation email)
Initially, I simply installed the app in the general site-packages folder, and changed the code there. Now that I put my code on bitbucket I need a way to be able to keep my mods in the repository in a usable way, and uploading the full python code doesn't sound like a good idea.
I guess the best way would be to keep the 3rd party app in site-packages, and create an app in my project to keep my changes. In my case, I'd create my-django-registration in my project, and then import this when I need it in my code, rather than django-registration.
I also read about virtualenv, but I think that's mostly used for being able to use multiple environments in the same machine (in fact, somewhere it advises against changing the modules installed in the virtualenv), and doesn't help me with keeping my changes in a repository.
Any comments welcome!
Thanks
In general, you should reuse and override the behavior in 3rd party apps and not modify their sources.
What you'll most often encounter is that apps ship models that may not necessarily cover your needs, but do most of the work; you'll have forms that are almost perfect, but need that little something; you'll have views that would be perfect if you can just change one thing; you'll have URLs that are sane, but you need something more from them.
In most cases, that would just require that you create a custom app and rewire everything. Ship your own URLs that map to views that you've extended and overrode methods for custom behavior; supply it with a model form who's Meta is using the new model that you've extended from the original; so forth...
That's just the tip of the iceberg of what you can do, there's more ways when your creative. I can give you an example of how I've used the RegistrationProfile model, but shipped my own URL patterns and a custom class-based view that handled the registration process.
Now, where virtualenv comes into play is that you'll most likely be using pip to specify and supply your required dependencies in the requirements file format. That's when you want to say: "I've extended the django-registration app, but it won't work cleanly with just any version. It has to be of release X", or , "a checkout from the repository of commit Y".
This blog post that adresses this issue is extremely helpful. For convenience I copy-paste it here:
You don’t touch external app code
You are not supposed to edit the code from an external app. Unless you fork it first on github.
So, how to override without forking:
Overriding a template
If you want to override templates/userena/activate_fail.html, then all you have to do is create your own templates/userena directory and make your own activate_fail.html in it.
Overriding a url
Probably the first thing you should check in an external app is its urls.py. Views that are properly coded should support plenty of arguments. For example, userena has a signup view with such a signature (at the time of writing):
def signup(request, signup_form=SignupForm,
template_name='userena/signup_form.html', success_url=None,
extra_context=None):
This means that you can replace the form used by the signup view. To do so, open your urls.py, add what we are going to need at the top:
from userena import views as userena_views
from yourforms import YourSignupForm
Then, find the include the external app’s urls, something like:
url(r'^userena/', include('userena.urls')),
Before that, add your url override:
url(r'^userena/signup/$', userena_views.signup, {'signup_form': YourSignupForm}, name='userena_signup'),
url(r'^userena/', include('userena.urls')),
Now, your custom url definition will be the first to be hit when a visitor hits /userena/signup/. Which means that /userena/signup/ will use YourSignupForm instead of userena’s signup form.
This trick works with any view argument. The ones you should see the most often are:
template_name: lets you change the template name
extra_context: lets you add a dict that will be added to the
context
Almost every view should have these arguments.
Overriding a view
Overriding a view requires to override the url of the view you want to replace. If you want your own signup view to be used, then just override the url:
import yourviews
# ...
url(r'^userena/signup/$', yourviews.yoursignup, name='userena_signup'),
url(r'^userena/', include('userena.urls')),
Decorating a view
Decorating a view is like overriding a view, but reuses the external app’s view. Basically, it’s the same than overriding a view (see above), but your view will look like this
from userena import views as userena_views
def yoursignup(request):
# do stuff before userena signup view is called
# call the original view
response = userena_views.signup(request)
# do stuff after userena signup view is done
# return the response
return response
Forking an app
If you are not familiar with pip and virtualenv first, please read the post about using pip and virtualenv first.
For example:
You installed django-userena as such: pip install django-userena
First you should uninstall it: pip uninstall django-userena
Then go on the app’s github page
Click on the fork button
This will make you a repository with a copy of django-userena
Install it as such: pip install -e
git+git#github.com:your-username/django-userena.git#egg=django-userena
Then you can edit the code in yourenv/src/django-userena
Push your commits
Credits to the post writer!
I think the neatest way to accomplish what you look for would be to fork django-registration, and in your app use the fork instead of the original project.
That being said, you can have a non-email registration in django-registration without changing the code of the app. I've done it by creating a custom registration backend that sets the users as activated upon creation. Here you can see other ways to do the same.
I have been doing CRUD operation in Django but I am having problem with what to do after successful operation.
Is there any way that i can redirect the user to Home page with small message on top of page like
"Record Successfully added or something else" like Google does with Dismiss hyperlink :)
EDIT:
Actually that a is full documentation and not a simple example.
I could not understand in which template I have to include {{messages}} in. In update form, edit form or home page form?
I don't understand where I need to define messages. I use only generic views so I am confused.
Use the django.contrib.messages framework to get the same messaging style as used in Django admin.
Enable the middleware module by adding 'django.contrib.sessions.middleware.SessionMiddleware' to MIDDLEWARE_CLASSES in settings.py.
In your view, use something like messages.add_message(request, messages.INFO, 'Stuff happened') to record information where it makes sense.
In your template, you'll have a list messages which you can iterate over where it makes sense in your design - the example in the documentation shows a full example which exposes the tags as CSS classes for ease of styling.