add encoding comment to project all python file
add comment "# coding:utf8# to all python file
- command
add comment "# coding:utf8# to all python file
The Mixin approach for applying permissions to CBV views suffers from 3 issues: 1. you need to read the code to see what permissions are being applied to a View 2. multiple bits of disparate code required to specify, e.g., a simple permission check 3. permissions set on a base class are overridden by permission set on sub-class, unless special care is taken Here's a nice trick, using only built-in django machinery, apply a decorator intended to decorate a django view function to a CBV view. https://docs.djangoproject.com/en/1.11/topics/class-based-views/intro/#decorating-the-class This approach works for any function decorators with arguments - simply wrap it in a function that takes the same arguments: def my_cbv_decorator(*args **kwargs): return method_decorator(a_view_function_decorator(*args, **kwargs), name='dispatch') Use your new CBV decorator to decorate View sub-classes: @my_cbv_decorator('some_parameter') class MyCBView(django.views.generic.TemplateView): pass # dispatch method for this view is now wrapped by a_view_function_decorator Note: you can also pass decorator parameter directly to method_decorator, but wrapping it up like this makes the code read nicer.
This 'smart_spaceless' template tag is a replacement for Django's built-in 'spaceless'. If settings.DEBUG = True, spaces will not be removed to make debugging your template code easier. When DEBUG = False, spaces will be removed. Happy coding!
output: ``` {u'Ogrenci': [u'Tum okullar', u'Lisans', u'Onlisans', u'Yuksek Lisans / Doktora', u'Ingilizce Hazirlik'], u'Ogretim Elemani': [u'Tum okullar', u'Lisans', u'Onlisans', u'Yuksek Lisans / Doktora', u'Ingilizce Hazirlik']} ```
Authentication through Facebook's Graph API. See [http://developers.facebook.com/docs/authentication/](http://developers.facebook.com/docs/authentication/) [http://developers.facebook.com/docs/authentication/permissions](http://developers.facebook.com/docs/authentication/permissions) [http://developers.facebook.com/docs/api](http://developers.facebook.com/docs/api) [http://github.com/facebook/python-sdk/blob/master/examples/oauth/facebookoauth.py](http://github.com/facebook/python-sdk/blob/master/examples/oauth/facebookoauth.py) Define the facebook tokens in settings.py and replace <app_name> with the name of your app. You will probably want to modify the scope on the authorize link in the template, see the authentication permissions link. This updates the user model every time the user logs in but I think that it is okay so the data is always correct. I have tested this but not rigorously. If there is a hole and everyone gets admin rights to your site don't say I didn't warn you :). Comments are appreciated. 16 June 2010 Added missing imports. Cleaned up the template. Shouts out to @obeattie and @whalesalad
With this awesome manage.py, it will try to migrate first when called with runserver. Also, this manege.py has super power to be used in your entry point as such: entry_points = { 'console_scripts': [ # u haz a setup.py -> u haz importable module :) 'yourcommand = yourproject.manage:main', ], }, Example output: $ yourcommand runserver Operations to perform: Apply all migrations: auth, contenttypes, admin, sessions Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying sessions.0001_initial... OK Operations to perform: Apply all migrations: admin, auth, contenttypes, sessions Running migrations: No migrations to apply. Performing system checks... Username (leave blank to use 'jpic'): Email address: [email protected] Password: Password (again): Superuser created successfully. Welcome in 2017, where automation is king System check identified no issues (0 silenced). September 17, 2017 - 21:21:41 Django version 1.9.10, using settings 'crudlfap_example.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Extra note: it doesn't matter if migrate crashes for now, since django runserver doesn't support not being able to connect to database. So most of the time I hope to shouldn't need to disable this hack.
A subclass of `HttpResponse` which will transform a `QuerySet`, or sequence of sequences, into either an Excel spreadsheet or CSV file formatted for Excel, depending on the amount of data. All of this is done in-memory and on-the-fly, with no disk writes, thanks to the StringIO library. **Requires:** [xlwt](http://pypi.python.org/pypi/xlwt/) **Example:** def excelview(request): objs = SomeModel.objects.all() return ExcelResponse(objs)
Description ============= This tool is used for dump and restore database of Django. And it can also support some simple situations for Model changes, so it can also be used in importing data after the migration of Model. It includes: dump and restore. Dump ====== Command Line: python db_dump.py [-svdh] [--settings] dump [applist] If applist is ignored,then it means that all app will be dumped. applist can be one or more app name. Description of options: * -s Output will displayed in console, default is writing into file * -v Display execution infomation, default is does not display * -d Directory of output, default is datadir in current directory. If the path is not existed, it'll be created automatically. * -h Display help information. * --settings settings model, default is settings.py in current directory. It can only support Python format for now. It'll create a standard python source file, for example: dump = {'table': 'tablename', 'records': [[...]], 'fields': [...]} table' is table name in database, records is all records of the table, it's a list of list, that is each record is a list. fields` is the fields name of the table. Load(Restore) ¶ Command Line: python db_dump.py [-svdrh] [--settings] load [applist] You can refer to the above description for same option. Others is: * -r Does not empty the table as loading the data, default is empty the table first then load the data Using this tool, you can not only restore the database, but also can deal with the simple changes of database. It can select the suitable field from the backup data file according to the changed Model automatically, and it can also deal with the default value define in Model, such as default parameter and auto_now and auto_now_add parameter for Date-like field. And you can even edit the backup data file manually, and add a default key for specify the default value for some fields, the basic format is: 'default':{'fieldname':('type', 'value')} default is a dict, the key will be the field name of the table, the value will be a two element tuple, and the first element of this tuple is type field, the second element is its value. Below is a description of type field: type value description 'value' real value using the value field directly 'reference' referred field name the value of this filed will use the value of referred field. It'll be used when the field name is changed 'date' 'now'|'yyyy-mm-dd' It's a date date type, if the value field is 'now', then the value be current time. Otherwise, it'll be a string, it's format is 'yyyy-mm-dd' 'datetime' 'now'|'yyyy-mm-dd hh:mm:ss' The same as above 'time' 'now'|'hh:mm:ss' The same as above The strategy of selection of default value of a field is: first, create a default value dict according the Model, then update it according the default key of backup data file. So you can see if there is a same definition of a field in both Model and backup data file, it'll use the one in backup data file. According the process of default value, this tool will suport these changes, such as: change of field name, add or remove field name, etc. So you can use this tool to finish some simple update work of database. But I don't give it too much test, and my situation is in sqlite3. So download and test are welcome, and I hope you can give me some improve advices. project site ============= http://code.google.com/p/db-dump/
Simplifies using RequestContext in render_to_response. Simply call the wrapper with request as the first argument, and the rest of the arguments are as normal for render_to_response. ex: render_response(request, 'foo_list.html', {'foo': Foo.objects.all()})
Decorator, written for views simplification. Will render dict, returned by view, as context for template, using RequestContext. Additionally you can override template, returning two-tuple (context's dict and template name) instead of just dict. Usage: @render_to('my/template.html') def my_view(request, param): if param == 'something': return {'data': 'some_data'} else: return {'data': 'some_other_data'}, 'another/template.html'
I put this in a file called auth.py, then referenced it in the settings.py like so: AUTHENTICATION_BACKENDS = ('myproject.myapp.auth.ActiveDirectoryBackend',) This has been tested on my office network, with the following setup: Django 0.96 Python 2.4.4 python-ldap Fedora Core 5 (On the server hosting Django) AD Native Mode 2 Windows 2003 AD servers
I found model definitions with large number of fields with long help_text unreadable and feel that help_text doesn't really belong to field definition. With this snippet help_text attributes can live outside field definitions in inner HelpText class so field definitions become shorter and more readable. Usage: from django.db import models import readable_models class MyModel(models.Model): __metaclass__ = readable_models.ModelBase name = models.CharField('Name', max_length=30) address = models.CharField('Address', max_length=255) # ... long list of fields class HelpText: name = 'The name ...' address = 'Example: <very verbose example is here>'
With the advent of newforms-admin it's now possible to override admin interfaces without having to change any code in third-party modules. This example shows how to enable a rich-text editor for `django.contrib.flatpages` without touching Django's code at all. (Actual embedding of the editor via Javascript left as an exercise for the reader – plenty of examples of that elsewhere.)
This is an example on how to create a custom advanced search (like the google advanced search page) in the admin app instead of the basic search field. you need to override 2 template of the admin so in your templates/admin folder copy the html files from the original admin app as follow: change_list.html: add the name of the module of the templatetag at the top where there is the load command from: {% load adminmedia admin_list i18n %} to: {% load adminmedia admin_list custom_search_form i18n %} and on line 87 (circa) you need to load our custom template tag something like: {% block search %}{% advanced_search_form cl %}{% endblock %} search_form.html: put your form inside the <form> tags with {{asf}} should be enough (I have also removed cl.value from the input text field because would be to complex to reload form values too ) probably would be better to create 2 new clean template and extend them but I'll leave that as an exercise for the reader :) many thanks to [Peter Baumgartner to get me in the right direction after his post](http://lincolnloop.com/blog/2011/jan/11/custom-filters-django-admin/) Currently ordering in the admin panel doesn't work if you find a way to get it work please write a comment
If the primary key on a table is an integer, it can be desirable after a lot of adding and removing either during testing (as was my case) or otherwise, to tidy up the key space a little and see the primary keys run up as unbroken sequences from 1. An excellent snippet here: https://djangosnippets.org/snippets/2915/ showed us how change the primary key value from in a given table and in all tables that relate to it (have a foreign key pointing into it). We can exploit that to achieve this outcome with integrity. For any given table we just fetch the primary keys into a sorted list and then walk the list assigning key 1, 2, 3, 4 etc where needed (if it doesn't already have that key).Because our list is sorted we're always moving tuples down the ladder of available keys to next empty slot basically until we've compacted the whole list. And voila. Mission accomplished. Works in with database introspection, in part because the integrity of relations is a little obscured by the ORM which hides intermediary tables in ManyToMany relationships and such. At the database API level these concerns all disappear. Built and tested with Django 1.11 but the form only goes to 1.10 here. Not even sure it works on 1.10. Certainly the snippet I based it on didn't work in 1.11 and need some updating.