django: is it possible to use the views that the admin panel uses? - django

Just learning django here, going through their website's tutorial.
When they take you through their admin panel, it's like, wow, all I have to do is define a model and django will give me a cool web page like this?
But that doesn't seem to be the case--it seems as if all that cool automatic functionality is only inside the admin panel. It seems that, if you want to have a cool add/change form, for instance, a form that looks and acts like the one in the admin panel, you're going to have to do all the layout and cool features by hand.
Am I wrong about this? Is there some way to make something that looks and works exactly like the admin's "change record" panel, but at your own url?

You are right, but I guess your expectations might be wrong.
Django's automatic admin site is one of the things that makes it very powerful. For example if you're building a large site, normally you'd also have to spend a lot of time to create a admin site, I mean A LOT! So Django provides a useful admin site automatically and it does a good job, which is great.
On the other hand your actual site is always going to be different so Django doesn't provide you the similar "automatic" ways as you expect. But it provides you the same building blocks, like ModelForms, ClassBasesView etc.. And of course, you have to put them together. But it's so much easier and faster to build sites with those blocks then doing it by yourself.
That being said, if you really like how admin site is looking and behaving then you can copy and use them on your main site, which will still require you to do some work.
(Couldn't comment, lacking reps)

Related

Multiple reset passwords in django

I have a project which have a personal app, where the login takes place, and a question app which also includes a profile page. I have managed to reset pasword from the login page, but when I try to do the same in the question app (using different templates, because I do not want the same on these pages), it just goes directly to the login reset template.
I thought it would be enough to just add a new registration folder in the questions app, but it still goes searching in the personal app I think.
Is it possible to just fix this using the django auth views or do I have to create my own views for the questions app?
You will need to create separate views, as well as separate templates.
First, make sure that you understand the User model, and how authentication works in Django. The core docs have plenty of information on that.
Second, look at what you are trying to do and create a view specifically for the template you are creating. Make sure that view processes the data the way that you want to, and that it redirects where you want the user to be redirected to after making the update.
One question to ask yourself though, before you go through this trouble is "Do I really need to have two places to do this?"
Having more than one location to handle password resets is not likely to end up being what you actually want in the long run. I would personally keep all of the account manipulation views in one place so that you don't mess something up if you decide to change something in one place and forget in another.
Two principles that are important when developing any kind of site are KISS and DRY. KISS is just the traditional keep it simple.
DRY means don't repeat yourself.
Unless there is a NEED to have the code be in two different places, it is a bad idea. ESPECIALLY with account related things.

Single model for storing django application-wide options

I have a set of top-level configuration data fields that I want to be able to set within django admin for each deployment of my django app. I only want one set of these.
Example fields: site_logo, contact_person, address, facebook_url, twitter_url
The problem is that Django Admin is geared towards tables (lists) of models, so its not a good fit for this type of singular configuration model. I really only want one of these models to exist for the whole site, and to be able to click into it from admin and edit the various fields.
It seems i've come across a 3rd party app in the past to accomplish this but can't find it anywhere. Part of the problem is I'm finding it difficult to find the right words to google. Any ideas?
It looks like django-values will do what you're looking for.
Other possible contenders:
http://github.com/sciyoshi/django-dbsettings (doesn't look maintained)
http://github.com/jqb/django-settings
Have a look at django-livesettings it sounds like it might fit.
Not that i have used it, but i have heard good things about django-constance.
And there are even some more options listed in the Configuration-Grid on Django Packages.

Should I modify/extend the admin interface, or write my own CRUD views/templates?

I'm trying to write a simple CRM app in Django; partly as a learning exercise and partly for in-house use.
My schema is slightly complex, as rather that have a single Contact model (with a home phone, work phone, home email, etc.), I have stripped down Cntact model plus a Phone model, an Email model, etc., with a ForeignKey pointing back to a Contact. The point is to let Contacts have an arbitrary number of phone numbers, email addresses, etc. Simple, right?
I have some working views and templates for displaying the data - no issues there. And with only a very small amount of poking at admin.py I have a um...eight different TabularInlines set up, and the admin interface works to create and edit the data...but it's ugly and clunky to the point of unusability, and of course there's no conception of permissions or anything. I'm also not really a fan of having a completely different interface for displaying and searching through the data than for editing and adding contacts...I'd like as much as possible to be done inline, so that I can search for a name, look at the record, click "add note", have it popup a form, fill in the details, click submit, and be done, all with AJAXy goodness so there's no page reloads.
Question: Should I plug away at modifying the admin interface to try and make it usable for a user-facing app? And if so, can anyone point me to a good guide or example where someone has really changed the admin interface to make it work for user-facing CRUD operations?
Or should I just go ahead and write my own CRUD views? And if so, can anyone point me to a good guide or example where someone has written custom CRUD views that work with lots of ForeignKeys and inlines? Ideally I want a form that displays a single Contact, all his Email records, plus a blank form to add a new Email record, plus a button to add more blank forms, plus his Phone records, plus a blank form, and so on for all 8 of my associated models.
(Or am I thinking about this all wrong? Any advice appreciated.)
For our intranet, we use ModelAdmin subclasses (not mounted on the admin site via admin.site.register) for most of our C(R)UD views. By using custom templates for the views, it doesn't look like Django admin at all. What is very convenient though, is that it already handles all the validation/saving for us.
In general, I found admin-"hacking" quite useful to quickly write up C(R)UD views and usually with relatively small changes to your ModelAdmin subclass, you can make it work for your use case.
So I'd vote for use ModelAdmin, but not the one you use in admin, hook a different template and come up with some fancy CSS.
I successfully created a software on top of admin.
The admin hooks (these days) allow very fine-grained customizations, i.e. in general you only need to touch what you want to change.
The changes can go from a trivial cosmetic adjustment to a complete swap-out:
If you provide templates/admin/base.html your admin site can look any way you like. And of course, a navigation bar at the top could include links to some of your own views. Watch out not to hardcode URLs in your links, always reverse.
You can overload ModelAdmin's "change_view", "changelist_view" etc. and swap them for your own views. For example I replaced a default changelist and its simple filtering with a search interface that allows dynamic queries to be built, result columns to be customized by the user, and loading/saving of these searches. That didn't affect any of the other views of that ModelAdmin.
Overloading a ModelAdmin's "get_urls()" let's you rewrap existing admin urls to go to your own views. I did the latter for one model where I wanted the simple Add screen to be replaced by a totally customized Wizard (only leaning on ModelForm).
Don't forget the simplest approach, esp. regarding your "AJAXy goodness": Just define "css" and "js" in your ModelAdmin's Meta. Want to move an inline from the bottom to sit between third and fourth field, and that's not possible via parameters? A one-liner in jquery.
Check out "django-grappelli" for an example of how to improve admin look and feel.
What did you mean by "and of course there's no conception of permissions or anything"?

Django and Generic Views

I've written an entire app pretty successfully in Django but I have this nagging question that I think I know the answer to but I just want to make sure.
One of the things I really liked about Django was the data model and the ability to not have to do "obvious" stuff. For example, we use the admin interface extensively in our app. The fact that I don't need to write an edit screen for every model and keep it up to date every time the model changes is really nice.
What I'm puzzled by is that I wanted to have one part of the app render "read-only" versions of the models. Essentially I want exactly what I have in the Admin interface but without editable widgets. Now I notice, from the Django code, that that admin interface actually goes through and substitutes the widgets to use the editable ones so I know that non-editable is certainly there.
But as far I can tell, there is no way to just say "render this object" and have Django do the "obvious" thing and render it just like it does for the admin interface but with non-editable fields. I find this hard to believe since it seems like a) this is easier than the admin stuff and b) I know the widgets are already there. But I've looked all over and even the Django examples seem to always create a template and spell out exactly what the page should look like.
Writing a template is probably a good idea in general but early on in development when things are changing it would be better to have something that just does something basic given the information available in the model.
Am I missing something? Sorry if this is a stupid question.
Could be that most non-toy sites want a custom layout/html anyway?
Or, are you looking for Databrowse?
I used something like this: http://www.djangosnippets.org/snippets/937/
There are other similar things around if you google for 'django read-only admin' or similar.
Never underestimate how flexible the Django Admin is...

How can you tell if a site has been made with Django?

A company I'm looking at claims to have made the website for an airline and a furniture store using Django, but when I look at the sites, there is no indication what the underlying web technology is. How can you tell?
This is quite an old question, but I don't see any canonical answers. As the other answers have noted though, there's no sure-fire way to know, and if someone wanted to hide the fact that they're using Django, they can. That said, you can always do a little detective-work and determine with some confidence whether it uses Django or not. If that's your goal, here are some strong indicators you can look out for:
Admin Panel
First and foremost, check if the site has a /admin/ page. If it does, and it gives that familiar Django admin login page, you're 99% sure (unless someone went through a lot of trouble to make it look like Django).
Forms
There are a number of things you can look out for in forms:
Form fields with id attributes starting with id_
Check for a hidden field with the name csrfmiddlewaretoken
If the site has a formset, check for -TOTAL-FORMS and -DELETE hidden inputs.
Cookies
If the site uses the contrib.auth package for authentication, you will probably see a cookie called sessionid being set when you log in.
Forms will also probably set a cookie called csrftoken.
Trailing Slashes
Trailing slashes after URLs, and/or redirecting you to the page with a trailing slash if you try to go to one without it. This is Django's default behavior, and to my knowledge not extremely common in other frameworks. Note, though, that it can be easily deactivated in Django.
Error Pages
Failing all this, or still not being convinced, you can try to force error pages, and try to learn something from that. Go to an unmapped URL with a 404 page, and see if DEBUG still happens to be true (in which case you should probably notify the owner that they're not being very secure about their site).
You can try a few things, such as attempting to find error pages, and checking the default location of the administration panel that Django creates, but overall there's no way to determine what technologies a given site is using.
See also: https://stackoverflow.com/questions/563316/is-there-a-generic-way-to-see-what-is-a-website-running-on/563335#563335
Look for the csrf input box. This is present on any forms. But this can be turned off though not very recommended. Also if it's an old version of django this may not exist. But if it's there it's a strong indicator.
This is present on any page that have a post form. And it looks like this:
<input type='hidden' name='csrfmiddlewaretoken' value='3b3975ab79cec7ac3a2b9adaccff7572' />
Navigate to a page with a formset, and check if there are *-TOTAL_FORMS or *-DELETE hidden inputs.
That doesn't prove that they are using Django, but might be a clue that they are (with the mentioned model formsets).
Try to navigate to some 404 error page, or something of that sort. Chances are slim, but try to find a default django error page.
You can also try to login to www.website.com/admin and see if you get the default django admin page.
Other than that, if that didn't work, then you just can't.
There are no reliable indicators to my knowledge but you could check the /admin/ URL to see if you get the standard admin app or sometimes the feed-URLs use a common prefix compared to a common suffix (although this might not be an indicator at all but just a preference of the developers).
Trying to trigger a debug page (either via a 404 or using some broken input that might case an internal error) might also be a good way (although this acts more as a test of competency of the original developers and admin than anything else :-) )
Could you ask the airline and / or the furniture store? I'm guessing that you want to know if this company has good experience in django, I think it is reasonable to ask for references if you are considering working with them.
The other companies may be quite happy to discuss what technologies were used - some are and some aren't, but it's worth asking.