Configurazione

urls.py

in urls.py devono essere avviati i vari autodiscover:

autocomplete_light.autodiscover()
admin.autodiscover()  # Not needed for dj > 1.7
admin_tools.dashboard.autodiscover()

in aggiunta devono essere aggiunti i pattern per la localizzazione. jmb kick dovrebbe fare questo in automatico.

Settings

jmb.core only looks for 3 variables, no one is required:

WARNING_RULES

determine visibility of Warnings based on module and mesage text

JMB_MONKEY_PATCH_INCLUDE

patches that will be applied

JMB_MONKEY_PATCH_EXCLUDE

patches that won’t be applied

AppConfig

class jmb.core.apps.JmbCoreConfig(app_name, app_module)

An AppConfig that take care to monkey patch django and apply control over DeprecationWarning

ready()

Override this method in subclasses to run code when Django starts.

tune_warnings()

Add filter warnings rules so as to ignore warnings from modules or matching pattern defined in WARNING_RULES

WARNINGS_RULES must be a list of tuples whose first element is a module name (e.g.: ‘jmb’, ‘jmb.core’, ‘django.contrib.auth’, ‘cms’) and the second element is a regexp matching the text of the message. These two values will be passed to warnings.filterwarning as module and message parameters.

WARNING_RULES

WARNING_RULES It’s based on 2 criteria:

• the module where the warning is issued

• the regexp of the text of the error

It uses warning.filterwarnings and is fired from within AppConfig in the JmbCoreConfig.__init__ so as to come after django’s configure_logging but before any module import

WARNING_RULES is a list of tuples, each tuple is composed of a module_name and a regexp.

The goal of this settings is to silence warning coming from packages that you don’t want/may change so that you don’t miss important warning that you shoud take care of. The main necessity comes from the fact that in the transition from on django rel to the other some packages may raise warning that flood the console. If I concentrate on porting one package I don’t want other packages to hide these messages in the mess of other ones.

An example of the use can be:

WARNING_RULES = [
    ('cms', None),
    ('djangocms_googlemap', None),
    ('', '.*(PagePermission|PageUserAdmin|ViewRestriction).*'),
    ]

the last tupe is needed becouse in some situation. filterwarning doesn’t understand where the messages was originated (I guess when a metaclass generates the classes)

Monkey Patch

Jumbo relies on some patches to the official django version that can be applied using the function jmb.core.monkey.patch(). Before django 1.7 we used to monkey patch in settings and in urls.py. In Dj1.7 AppConfig is out preferred place.

There’s no needed settings to make it work apart from putting jmb.core soon enought in the list of INSTALLED_APPS.

If you want to change which patches are applied you can use

JMB_MONKEY_PATCH_INCLUDE

a list of all patch names to be applied

JMB_MONKEY_PATCH_EXCLUDE

a list of all patch names to be excluded

Available patches that you may be willing to disable are:

namespaces

needed to make package namespace be visible

timepicker

better time, date, datetime picker for the admin

jquery_cms

prevents cms to replace stock jQuery with it’s own

form-errors

allows to print in console errors of a form

get_queryset

needed for portability between old and new versions.

jmb.core.monkey.patch(include=None, exclude=None)

Apply all patches Jumbo relyes on. Currently management commands, jquery, and timepicker

Parameters

• include – a list of strings naming the patches that will be applied (optional).

• exclude – a list of strings naming the patches that will not be applied. ‘jquery’ patch will only be applied if cms is in INSTALLED_APPS

management commands

Django find_management_module fails at finding modules when namespaces are used.

This version of find_management_module tries a real import when django fails to find the module. The difference is that django only uses:

imp.find_module(...)

that doesn’t implement full module search algorithm. We’re going to place this code in settings/__init__.py, the older way to place it in :file:`urls.py doesn’t work as is not found when calling from command line as urls.py is not called:

from jmb.core import monkey
monkey.patch()

At the moment there’s an open ticket

Django and jQuery

jmb.core.monkey.conf.patch_cms_page_not_to_overwrite_jquery()

MonkeyPatch django-cms not to overwrite jquery.

While django make attention to use djangojQuery and not to overwite standard $(), so different versions can coexist, PageAdmin and PluginEditor overwrite it with django.jQuery. Utilizzata in urls.py cosi:

from jmb.core import monkey

if settings.CMS_ENABLED:
    urlpatterns += patterns('',
        url(r'^', include('cms.urls')),
    )
    monkey.patch_cms_page_not_to_overwrite_jquery()

Errors in forms

When running the development server, print in the console which errors have been raised when saveing an object. This in necessary when not all fields are used in a form and Django just says “Fix errors below”

This will work if you have a variable called RUNNING_DEVSERVER that can be initialized as follows:

import sys
try:
   RUNNING_DEVSERVER = (sys.argv[1] == 'runserver')
except KeyError:
   RUNNING_DEVSERVER = False

Portability

get_queryset

Rel 1.6 changed method name Manager.get_query_set to Manager.get_queryset

timepicker

Datetime and time widgets in Django are pretty poor ones.

Html widgets used by admin are defined in django.contrib.admin.options in a dict named FORMFIELD_FOR_DBFIELD_DEFAULTS.

We overwrite it in jmb.core.admin.options and define a widget that is derived from jQuery.ui’s default one.