-
Notifications
You must be signed in to change notification settings - Fork 24
Home
This documentation is related to version 0.7.xx
IsCore takes great features of Django, such as automatic generation of forms and views from models, to the next level. First and foremost, REST interface is generated for each model. Second, the standard add/edit/list views are generated with standard layout and buttons. The list view is equipped with filtering and sorting by any column and action buttons that can be added/removed as needed. IsCore makes it extremely easy to registered a custom view for the model to enable versatility. The main purpose of the django-is-core is to simplify development of Information Systems (IS).
This requirements are installed automatically during installation of django-is-core
'django>=1.6',
'django-class-based-auth-views>=0.2',
'django-piston==0.5.8',
'germanium==0.1.5',
'django-block-snippets==0.0.11',
'python-dateutil>=2.2',
'pytz',
'django-apptemplates',
'Unidecode>=0.04.16',
'factory-boy>=2.3.1',
'django-project-info==0.2.4',
'mimeparse==0.1.3',
'sorl-thumbnail==11.12',
Installation of django-is-core can be done with the command:
pip install https://github.com/matllubos/django-is-core/tarball/master
Prior to using IsCore, one must add 'is_core' to INSTALLED_APPS:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'django_extensions',
'django.contrib.humanize',
# Your apps
....,
# IS
'is_core',
)
The second mandatory configuration is inside middlewares. You must add 'is_core.middleware.RequestKwargsMiddleware' and 'is_core.middleware.HttpExceptionsMiddleware' to MIDDLEWARE_CLASSES, for example:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'is_core.middleware.RequestKwargsMiddleware',
'is_core.middleware.HttpExceptionsMiddleware',
)
Django uses session authentication by default. Django-is-core uses REST where session authentication is not very suitable. There is two reasons: 1) REST should be stateless and 2) Some REST clients do not support cookies. Therefore we add token authentication to is-core. The token is randomly generated on the server side and send to the client (inside cookies for Web UI or inside REST response) and client can authenticate itself through cookie or header. When user updates data (POST/PUT/DELETE) CSRF token is required for cookie authentication but for header authentication is not necessary.
You can use tokens by adding 'is_core.auth_token' to INSTALLED_APPS, replacing 'django.contrib.auth.middleware.AuthenticationMiddleware' with 'is_core.auth_token.middleware.TokenAuthenticationMiddlewares' and set AUTH_USE_TOKENS to True (TODO will be removed in 1.0.0). Eg.:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'django_extensions',
'django.contrib.humanize',
# Your apps
...,
# IS
'is_core',
'is_core.auth_token',
)
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'is_core.auth_token.middleware.TokenAuthenticationMiddlewares',
'django.contrib.messages.middleware.MessageMiddleware',
'is_core.middleware.RequestKwargsMiddleware',
'is_core.middleware.HttpExceptionsMiddleware',
)
AUTH_USE_TOKENS = True
Name of the AUTH token inside cookies for Web UI.
Default:
AUTH_COOKIE_NAME = 'Authorization'
Age of cookie, in seconds (default: 2 weeks).
Default:
AUTH_COOKIE_AGE = 60 * 60 * 24 * 7 * 2
Http only flag for auth cookie:
Default:
AUTH_COOKIE_HTTPONLY = False
Only secure flag for auth cookie
Default:
AUTH_COOKIE_SECURE = False
Auth header name for REST
Default:
AUTH_HEADER_NAME = 'HTTP_AUTHORIZATION'
Default token expiration time (default: 1 hour)
Default:
AUTH_DEFAULT_TOKEN_AGE = 60 * 60
Max token expiration time (default: 2 weeks). For the cases when user chose permanent login.
Default:
AUTH_MAX_TOKEN_AGE = 60 * 60 * 24 * 7 * 2
Allows token authorization.
Default:
AUTH_USE_TOKENS = False
Custom form class for login
Default:
AUTH_FORM_CLASS = AUTH_USE_TOKENS and 'is_core.auth_token.forms.TokenAuthenticationForm' or 'django.contrib.auth.forms.AuthenticationForm'
Custom view class for login
Default:
AUTH_LOGIN_VIEW = AUTH_USE_TOKENS and 'is_core.auth_token.auth_views.TokenLoginView' or 'class_based_auth_views.views.LoginView'
Custom view class for logout
Default:
AUTH_LOGOUT_VIEW = AUTH_USE_TOKENS and 'is_core.auth_token.auth_views.TokenLogoutView' or 'is_core.generic_views.auth_views.LoginView'
URL of login resource for REST
Default:
LOGIN_API_URL = '/api/%s' % LOGIN_URL[1:]
Custom home core
Default:
HOME_IS_CORE = 'is_core.main.HomeUIISCore'
Custom home core view
Default:
HOME_VIEW = 'is_core.generic_views.HomeView'
django-is-core provides own is_core.models.fields.FileField and is_core.models.fields.ImageField. This fields has limited upload file size.
Default (Mb):
MAX_UPLOAD_SIZE = 20
Custom class of core menu generator
Default:
MENU_GENERATOR = 'is_core.menu.MenuGenerator'
Example usage of the framework can be found in the example directory of the git repository.
Let's take a look at the Issues application. There is one model class Issue inside models.py extending the standard django models.Model class:
class Issue(models.Model):
title = models.CharField(_('Subject'), max_length=100, null=False, blank=False)
def __unicode__(self):
return self.title
IsCore is able to generate the default views automatically for the given model class. Default views include Table, Edit and Add view. To do that, one needs to define the IsCore class inside cores.py file as follows:
class IssueIsCore(UIRestModelISCore):
model = Issue
The IssueIsCore must extend one of the IsCore classes. In this case, it extends the UIRestModelISCore class generating both the REST API and the views (UI). This is the minimal working example enabling you to read, update and create model objects through one of the mentioned methods. The principal is very similar to django-admin.
It is possible define rest fields inside Model
class RestMeta:
fields = ('email', 'first_name', 'last_name', 'is_active', 'role', 'photo', 'salutation','language_code', 'is_verified')
default_general_fields = ('role', 'email')
default_detailed_fields = ('email', 'first_name', 'last_name')
allowed rest fields (default: id, _obj_name, _rest_links). Specify only a subset of model fields visible at all circumstances. For instance, one might wish to return different set of fields for different user roles. In that case, list only the common fields for all roles in RestMeta class and enable more fields dynamically e.g. in get_rest_fields method in the corresponding IsCore class.
default fields is send for objects list (can be changed with X-Fields header). IsCore will perform a union with fields attribute of the RestMeta class.
default fields send in case of query for a single object (can be changed with X-Fields header). IsCore will perform a union with fields attribute of the RestMeta class.
You can get RestMeta from model as model._rest_meta
UIRestModelISCore is one of the most commonly used classes from IsCore. Extend it when you want to expose your model as both REST resource (by extending RestModelIsCore) and classical add/edit/list views (by extending UIModelIsCore). Refer to the documentation of these classes for further details.
A class providing REST resources supporting standard CRUD operations for a given model.
specify class of the model you wish to expose through the REST interface.
specify the class of the form when modifications to the standard generated form are needed
specify subset of model fields exposed through REST for both list of resources and individual resource (default: union of rest_default_general_fields, rest_default_detailed_fields, rest_extra_fields and fields in RestMeta class of the model)
specify subset of model fields exposed through REST request in the list of resources (default: union of default_general_fields from the model's RestMeta class and rest_default_general_fields from the IsCore).
specify a subset of model fields exposed through REST request for individual resource (default: union of default_detailed_fields from the model's RestMeta class and rest_default_detailed_fields from the IsCore).
tuple of HTTP methods allowed on the resource (default: GET, POST, PUT, DELETE)
Class providing basic Add, Edit and List views for a specified model. One can either use views from IsCore (certain parameters of the views can be modified directly in this class) or provide a custom class for the view (preferable in case of complicated views). Additional views can be registered as well.
specify class of the model you wish to expose through the REST and web interface.
SortedDict of views available for the model along with corresponding URL patterns. Default views are Add, Edit and List.
specify the class of the form when modifications to the standard generated form are needed
subset of model fields displayed in the list view (default: _obj_name)
tuple of fields in the generated form displayed in Add and Edit views of the model (default: None)
Equivalent of form_fields for complex forms requiring definition of fieldsets.
Tuple of model fields not editable in the generated form used in Add and Edit views. Use this (default: ())