My preference is to keep all reusable templates in a partials folder, and place the pagination template in there.

{% if is_paginated %}
<nav>
    <ul class="pagination">
    {% for page_num in paginator.page_range %}
        {% if page_num == page_obj.number %}
          <li class="active"><a href="#">{{ page_num }}</a></li>
        {% else %}
        <li><a href="{% url urlname page_num %}?{{ request.GET.urlencode }}">{{ page_num }}</a></li>
        {% endif %}
    {% endfor %}
    </ul>
</nav>
{% endif %}

The pagination template is switched by the ListView populated context var is_paginated, also makes use of urlname variable to construct the page links.

Then in each list view template to include the pagination:

{% include 'partials/pagination.html' with urlname='quick-admin:listing-job-list' %}

https://github.com/variable/django-rest-framework-queryset 

from django.db import connections
class Receiver(PolymorphicModel):
    ...

class Database(Receiver):
    name = models.CharField(max_length=255)
    def get_data_source(self):
        return connections[name]

Then the feed model:

class Feed(models.Model):
    receiver = models.ForeignKey('Receiver')

    def get_data_source(self):
        return self.receiver.get_real_instance().get_data_source()

Then run this feed in trivial code:

import threading

function transform_listing(feed):
    cursor = feed.get_data_source().cursor()
    ....

feed = Feed.objects.create(receiver=Database.objects.create(name='legacy'))

for i in range(100):
    th = threading.Thread(transform_listing, [feed])
    th.start()

And you will quickly notice the threads complaining

Too many connections

What it’s happening is Django will create a new connection per thread when you access the ORM, and connections are left open even the threads are terminated, in this case the culprit is

def get_data_source(self):
        return self.receiver.get_real_instance().get_data_source()

So in this case, simply refactor the code to close the connection before return:

from django.db import connection
...

    def get_data_source(self):
        result = self.receiver.get_real_instance().get_data_source()
        connection.close()
        return result

A colleague of mine mentioned this site http://ccbv.co.uk/ which provides references and information about django class based views.

If you have Order and OrderItem models, your order FK is in OrderItem model, from OrderItem model point of view, it’s Many OrderItem to One Order, in other words ManyToOne. What this implies is you need to have Order records before OrderItem records.

Now, why we need one to many:

What if you have 2 different apps, say Settlement and Payment, which a payment can have multiple settlements, but settlements can only belong to one payment. Logically Payment app is built on top of Settlement app, in other words Settlement app doesn’t need to know about Payment app. But to make the constraint to work, you need to put the Payment foreignkey into the Settlement model (surely this makes sense in DB schema, but not in programming domain), which now Settlement app is required to know about the Payment app.

Not only the dependency is reversed, now you need to have payment record created before settlement record, WTF? Oh certainly you have the payment FK set to nullable, but then you will have an extra step to set the relationship.

Luckily there is a 3rd party package that kind of solve this problem through ManyToMany relationship by adding unique constraint on the right hand column, but unluckily if you ever want to roll back to the normal ManyToManyField, the migration doesn’t remove the additional constraints that introduced by this package. See django ticket.

For relevant information:

http://stackoverflow.com/questions/25635408/django-one-to-many-field-without-reversing-dependency

http://blog.amir.rachum.com/blog/2013/06/15/a-case-for-a-onetomany-relationship-in-django/

The goal is to achieve something like


http://localhost:8000/api/(resource)/
http://localhost:8000/api/v1/(resource)/


plus allowing clients to specify the version in request header (X-Version), here is how we did it.

Structure in side the API app:


├── __init__.py
├── middlewares.py
├── urls.py
├── v1
│ ├── __init__.py
│ ├── account
│ │ ├── __init__.py
│ │ ├── serializers.py
│ │ └── views.py
│ └── urls.py
└── v2
├── __init__.py
├── account
│ ├── __init__.py
│ ├── serializers.py
│ └── views.py
└── urls.py


project urls.py:

url(r'^api/', include('project.api.urls', namespace='api')),

api app level urls.py:

from django.conf.urls import *

urlpatterns = patterns('',
    url(r'', include('project.api.v2.urls', namespace='default')),
    url(r'^v1/', include('project.api.v1.urls', namespace='v1')),
)

version level urls.py

from django.conf.urls import *
from .account import views as account_views
from rest_framework.routers import DefaultRouter

router = DefaultRouter()
router.register('account', account_views.AccountView)
router.register('myaccount', account_views.MyAccountView)
urlpatterns = router.urls

create a middleware to switch to the correct code by changing the path_info, please note there is a caveat that namespace (‘api’) defined in project level urls is not flexible and needs to be known in middleware:

from django.core.urlresolvers import resolve
from django.core.urlresolvers import reverse


class VersionSwitch(object):

def process_request(self, request):
    r = resolve(request.path_info)
    version = request.META.get('HTTP_X_VERSION', False)
    if r.namespace.startswith('api:') and version:
        old_version = r.namespace.split(':')[-1]
        request.path_info = reverse('{}:{}'.format(r.namespace.replace(old_version, version), r.url_name), args=r.args, kwargs=r.kwargs)

Sample url:

curl -H "X-Version: v1" http://your.domain:8000/api/myaccount/

My original answer on stackoverflow.

import datetime
from haystack import indexes   
from cms.models.managers import PageManager
from cms.models.pagemodel import Page
from cms.models.pluginmodel import CMSPlugin


class PageIndex(indexes.SearchIndex, indexes.Indexable):
    text = indexes.CharField(document=True, use_template=False)
    pub_date = indexes.DateTimeField(model_attr='publication_date', null=True)
    login_required = indexes.BooleanField(model_attr='login_required')
    url = indexes.CharField(model_attr='get_absolute_url')
    title = indexes.CharField(model_attr='get_title')

    def prepare(self, obj):    
        self.prepared_data = super(PageIndex, self).prepare(obj)
        plugins = CMSPlugin.objects.filter(placeholder__in=obj.placeholders.all())
        text = ''              
        for plugin in plugins: 
            instance, _ = plugin.get_plugin_instance()
            if hasattr(instance, 'search_fields'):
                text += ''.join(getattr(instance, field) for field in instance.search_fields)
        text += obj.get_meta_description() or u''
        text += obj.get_title() or u''
        text += obj.get_meta_keywords() if hasattr(obj, 'get_meta_keywords') and obj.get_meta_keywords() else u''
        self.prepared_data['text'] = text
        return self.prepared_data       

    def get_model(self):
        return Page

    def index_queryset(self, using=None):
        return Page.objects.published().filter(publisher_is_draft=False).distinct()

when you have a unicode function like this:

def __unicode__(self):
  return "{0}".format(self.field_one)

It is actually returning a ASCII string(which means, it will try to convert field_one to ASCII), if the field_one contains characters outside of ASCII, you will get the problem as above.

Now consider this unicode function:

def __unicode__(self):
      return self.field_one

This works fine, because you are returning unicode string directly, no conversion needed.

Lets revisit the first unicode function, to make it work, you just need to add u to make it a unicode string

def __unicode__(self):
      return u"{0}".format(self.field_one)

//www.youtube.com/watch?v=c3C3hYbo37c

Want to add WYSIWYG editor to your TextFields? This app will sort you right out, basically this app will provide a HTMLField for you to use instead of just plain TextField and it will automatically render a rich text editor for you.

It does require some basic configuration, here is a sample config in settings.py

TINYMCE_DEFAULT_CONFIG = {
    "relative_urls": "false",
    "theme": "advanced",
    "theme_advanced_buttons1": "formatselect,bold,italic,underline,link,unlink,bullist,undo,code,image",
    "theme_advanced_buttons2": "",
    "theme_advanced_buttons3": "",
    "plugins": "paste",
    "height": "550px",
    "width": "750px",
}

File Browser

https://github.com/wardi/django-filebrowser-no-grappelli

TinyMCE has integration with File Browser app, but the original File Browser app requires Grappelli to be installed, what if you don’t want to have Grappelli for your admin backend but still want to have File Browser within TinyMCE? There is a fork of that comes to rescue.