Does anyone have experience (Django 1.x pref 1.3) with implementing a sort of singleton accessible from the admin page to expose some global variables for editing (site name, keywords, ...).
I cant find anything like this and it sounds quite unbelievable!
thanks
(django-preferences is broken with 1.x)
As lazerscience says, you probably want Django-dbsettings. I have a fork at Github that works with the latest Django versions.
after some playing I had dbsettings working... but with a few glitches:
- Aptana doesnt recognise the import preferences as a valid reference
- when I access my /settings/ page with the fields of the model I created and then save it I have a CSRF token missing or incorrect. error
NOTE: The official googlecode repository doesnt work (with 1.3), Daniel's version does instead (I guess he changed newforms -> forms etc). The way I created a new model for the settings veiw is:
from django.db import models
import dbsettings
class ImageLimits(dbsettings.Group):
maximum_width = dbsettings.PositiveIntegerValue()
maximum_height = dbsettings.PositiveIntegerValue()
options = ImageLimits()
You should avoid using singleton's as much as possible.
Are Singletons really that bad?
What is so bad about singletons?
For the rest, site name is editable in Django admin (see django.contrib.sites module).
Talking about keywords - it's bad to repeat them, thus, you better implement it in your item model (page, news article, etc).
Could you maybe give more examples of what do you need it for?
Related
I have been learning python for some months, and started tinkering with Django. Before posting this, I read up on the auto-generated 'admin.py'-code on github, as well as googled the matter. It appears my question is a little specific, and I was quite frankly very confused from that specific reading. Thus, I hope asking this adds value to this wonderful community. Question:
When connecting a model to the admin page, in admin.py, you first import admin:
from django.contrib import admin
After this, you import your model. Then, you supposedly connect your model through:
admin.site.register(MODEL)
What I do not understand is what 'site.register' is. The fact that the line starts off with 'admin.' makes perfect sense, as you are specifying from where the following import (ex. 'admin.function' or 'admin.class') comes from. Had it only been 'admin.somefunctionfromadmin' I would have totally understood this. Now, instead, I am confused as to what 'sites.register' is.
Is 'sites' a module, a file, and 'register' a function from within that module? If so, what does that make 'admin'? A package?
I have seen lines similar to these throughout Django, and feel a bit confused.
Thank you!
admin.site is the default instance of the AdminSite class. It is instantiated in django.contrib.admin.sites.
It is then imported in the django/contrib/admin/__init__.py. This makes it available as admin.site when you have done from django.contrib import admin.
When you call admin.site.register(Model), you are calling the register method of this admin site instance.
I am new to Django and Python and after reading a lot I decided not to use global functions as views (maybe because I am not used to global functions but mostly because I want a better reuse level and prefer to have smaller code blocks). The problem is that most of the Django apps I have been checking do not use a class based approach.
Is this because I am checking code in the wrong places (I started with the Django tutorial and then on github)?
I'm asking this because in the future I hope to be working with more Django programmers and don't want to adopt a non-standard approach at the beginning.
One fact is that class based view was added in Django 1.3, so if you're planning to support old Django version than you will have to stick with function view, for example if you want to create a generic app and launch it in GitHub or such for other people to use.
As for when to use class based view over function view i think this will depend on your use case, my advice is that you have to understand the advantage of each way, and IMHO it's pretty normal to have both implementation in a single project.
There was this nice article of Nick Coghlan on response to another great article CBV were a mistake that it worth to check.
Hope this was helpful :)
I have a Django application. Localising this into multiple languages is a simple and straightforward but one part of the site is an complex rich internet application. This part of the site allows the user to his workspace mode.
Everything remains the same but the terminology changes. e.g.
www.exmaple.com/myria/chemist
www.exmaple.com/myria/biologist
www.exmaple.com/myria/physicist
myria is my rich internet application. The words chemist, biologist and physicist merely denote the workspace. The whole Django application itselt uses the same codebase and nothing else changes.
I'm using django-rosetta to manage translating and django-localeurl to provide URL based locale switchin (on normal parts of the site).
I'm at my wits end on how to accomplish this. Maybe some kludging with the sites framework?
Short answer: you don't need it. In most cases it's better to have latin chars in URL instead of something %%-escaped.
Long answer: DjangoCMS provides locale-dependent URL for each page. You can kludge something like:
from django.utils.translations import ugettext as _
from django import http
...
def myria_view(request, localized_workspace):
my_workspaces = (
(_('foo'), foo_view),
(_('bar'), bar_view),
(_('buz'), buz_view),
)
for ws in my_workspaces:
if ws[0] == localized_workspace:
return ws[1](request)
raise http.Http404
but once again, don't do it. It's just so wrong
Update: Django does it out of the box https://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#translating-url-patterns
I have been playing for a couple of days with Django Admin to explore it, but I am still clueless of how it can be customized in the way we need.
Every time I look for any help for the customization in the admin panel, what I find is, a bunch of articles on various communities and forums, explaining how to customize the template, the lists items, the the column views etc. But that should not be called Django Customization.
If I need to make even a small change in the User functionality or any modification to the auth module. It takes a lots of efforts even in figuring out how that can be done.
Is Django that difficult to customize or its just lack of the help available over internet for this or its me who is moving in the wrong direction ?
You are not providing enough details on what you want to achieve, so it's difficult to say how complex the task is. You might also want to consider not modifying the admin site at all and building your own views where appropriate.
However, here are some good links to get you started:
Customizing the Django Admin
Doing more with the Django admin
Extending Django's User Admin
Personally, if you want a site to look like the admin, why not pull the templates and styles and use them, build your own views for what you need. Gobs of documentation and forum help is there for that. I like the idea of customizing the admin, but honestly, I have been doing it for awhile on a project and time and time again I think to myself, if this was built in the standard MVC (or MTV) manner with free templates online, copied admin ones, or some professionally made ones, and built with the plethora of addons and my code, it would be much easier!!! And, when you decide that request/response isn't cutting it, and you want to add lots of JavaScript, you'll be glad. I know. I have had to put all sorts of JavaScript on our Admin project. Mostly because it's impossible to make the admin do what we want, so we fix it with JavaScript once it is on screen. When you find yourself writing an Ajax based system, you'll wonder why you have the admin at all.
If I could start this project over, I might not even use Django, but I probably would. I most certainly won't used the Admin.
Now, if you are building an basic CRUD type site that doesn't have style-eyed users, then Django with grappelli, and some elbow grease will get the job done. Remember, Django is a collection of Python scripts. Just override everything you can, and you'll get there, if you aren't too ambitious.
Django Admin is easy to customize if your requirements match what is customizable in Django. If you need fancy features that are not out-of-the-box functionality you either need to find a plugin that does it, or implement it yourself by subclassing the appropriate classes. Which can be difficult, and requires good understanding of the internals of Django.
So in summary: it makes it easier to setup an admin, but if you need anything special that's not out of the box: you got a steep learning curve.
Depending on your requirements you can choose to use django or not. Anything that requires a lot of functional speccing is better of implemented manually.
It's very easy . Just copy default template to project and change HTML and some variable location
Just see in this vedio
https://youtu.be/NTZfjwf4F8A
I have recently started experimenting with Django for some web applications in my spare time. While designing the data model for one, I came across the dilemma of using inheritance to define a user of the website or using a technique known as monkey patching with the User class already supplied by the framework.
I tried to add a field by means of (after having defined all my models etc. without errors, according to python manage.py validate):
User.add_to_class('location', models.CharField(max_length=250,blank=True))
and executed the syncdb command. However, I keep getting this error
OperationalError: no such column:
auth_user.location
whether I am in the admin view of the site or the manage.py shell. There must be an extra step I'm missing, but there seems to be limited documentation on the whole monkey patching technique. So I'm asking you for assistance before I resort to inheritance. Any code, tips, or pointers to additional documentation are of course welcome.
Thanks in advance.
PS. I'm aware this technique is ugly, and probably ill-advised. ;)
There's an alternative to both approaches, which is to simply use a related profile model. This also happens to be a well-documented, highly recommended approach. Perhaps the reason that the add_to_class approach is not well-documented, as you noted, is because it's explicitly discouraged (for good reason).
When you add a field to any model, even if you do it the 'official' way, you need to migrate the database - Django doesn't do it for you. Drop the table and run ./manage.py syncdb again.
You might want to investigate one of the migrations frameworks, such as south, which will manage this sort of thing for you.
Here's a (slightly older) way of extending the User model.
Here's what the docs have to say.
And here's a recent conversation on django-users about the topic.
Djangos framework uses metaclasses to initialize the tables. That means you can't monkey-patch in new columns, unless you also re-initialize the class, which I'm not sure is even possible. (It may be).
See Difference between returning modified class and using type() for some more info.
I guess you might run into problems regarding where is your monkeypatch defined. I guess django syncdb creates databse tables only from the "pure" auth application, so your model will then be without "location", and then your site with the patch will look for the field.
Probably less painful way of adding additional info to user profiles is described in Django docs.