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 |
An AppConfig that take care to monkey patch django and apply control over DeprecationWarning
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 It’s based on 2 criteria:
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)
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. |
Apply all patches Jumbo relyes on. Currently management commands, jquery, and timepicker
Parameters: |
|
---|
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
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()
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
Rel 1.6 changed method name Manager.get_query_set to Manager.get_queryset
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.