The pyck.controllers Package

class pyck.controllers.CRUDController(request)

Enables automatic CRUD interface generation from database models. The pyck.controllers.CRUDController allows you to quickly enable CRUD interface for any database model you like. To use CRUD controller at minimum these steps must be followed.

  1. Create a sub-class of the CRUDController and set model (for which you want to have CRUD) and database session:

    from pyck.controllers import CRUDController
from myapp.models import MyModel, db

class MyCRUDController(CRUDController):
    model = MyModel
    db_session = db

  2. In your application’s routes settings, specify the url where the CRUD interface should be displayed. You can use the pyck.controllers.add_crud_handler() method for it. For example in your __init__.py (if you’re enabling CRUD for a model without your main project) or in your routes.py (if you’re enabling CRUD for a model within an app in your project) put code like:

    from pyck.controllers import add_crud_handler
from controllers.views import WikiCRDUController

# Place this with the config.add_route calls
add_crud_handler(config, 'mymodel_crud', '/mymodel', WikiCRUDController)

and that’s all you need to do to get a fully operation CRUD interface. Take a look at the newapp sample app in demos for a working CRUD example in the Wiki app.

Configuration Options

These parameters are to be set as class properties in a sub-class of CRUDController

Parameters:
  • model – (Required) The SQLAlchemy model class for which the CRUD interface is desired
  • db_session – (Required) The SQLAlchemy database session that should be used for operations
  • friendly_name – A human-friendly name of the model. If given this is used in the templates instead of the model name
  • base_template – An alternate base template to use for the CRUD handler instead of the default base template of the application
  • list_sort_by – Sorting spec for displaying records in records list page
  • add_edit_exclude – A list of fields that should not be displayed in add or edit operations
  • add_edit_field_args – A dictionary of field arguments with field name as key and args and key-value pairs dict.
  • list_recs_per_page – Number of records to display in a listing page. Default 10.
  • list_max_pages – Maximum number of pages to display in page links. Default 10.
  • list_only – List of fields that are to be displayed on listing page, all other fields are ignored.
  • list_exclude – List of fields to be excluded in listing page
  • detail_exclude – A list of fields that should not be displayed in CRUD details page
  • list_field_args – arguments providing extra directions/instructions for displaying/formatting list fields
  • list_actions –

    list of actions that are to be displayed in listing page, example:

    list_actions = [
        {'link_text': 'Add {friendly_name}', 'link_url': 'add', 'css_class': 'btn btn-primary'},
       ]
  • field_translations –

    Allow translating a field’s display value by calling a user defined function. So for example if a user wants to display ‘Yes’ when a field’s value is true, it can be done with something like:

    def translate_is_active(input_value):
    return 'Yes' if input_value else 'No'

field_translations = {
    'is_active': {
          'header': 'Account Active',
          'translator': translate_is_active
    }
}
  • list_per_record_actions –

    list of actions that are to be displayed for each row. These can contain a special keyword PK for referring to the primary key value(s) for the current record. Example:

    list_per_record_actions = [
        {'link_text': 'Details', 'link_url': 'details/{PK}'},
        {'link_text': 'Edit', 'link_url': 'edit/{PK}'},
        {'link_text': 'Delete', 'link_url': 'delete/{PK}'},
       ]
  • list_filter_condition –

    A SQLAlchemy filter condition to be applied for to the listing page

    Example:

    list_filter_condition = "self.model.user_id == self.request.session.get('logged_in_user', '')"
  • detail_actions –

    list of actions to be displayed on the details page, similar to list_per_record_actions. Example:

    detail_actions = [
        {'link_text': 'Edit', 'link_url': '../edit/{PK}'},
        {'link_text': 'Delete', 'link_url': '../delete/{PK}'},
       ]
  • enable_csv – Boolean indicating whether to allow CSV download of list data or not
  • template_extra_params – A dictionary containing any other parameters required to be passed to the CRUD templates

TODO

  • More documentation of various options and methods
  • A CRUDController tutorial
  • Tests for the controller
  • Add support for composite primary keys
  • Once CRDUController is complete, may be put table display login in a ModelTable component??
add()

The add record view

delete()

The record delete view

TODO:

  • Later may need to add support for composite primary keys here.
details()

The record details view

edit()

The edit and update record view

list()

The listing view - Lists all the records with pagination

list_csv()

The CSV view - Allow download of the data as CSV

pyck.controllers.add_crud_handler(config, route_name_prefix='', url_pattern_prefix='', handler_class=None)

A utility function to quickly add all crud related routes and set them to the crud handler class with one function call, for example:

from pyck.controllers import add_crud_handler
from controllers.views import WikiCRUDController
.
.
.
add_crud_handler(config, APP_NAME + '.', '/crud', WikiCRUDController)
Parameters:
  • config – The application config object
  • route_name_prefix – Optional string prefix to add to all route names. Useful if you’re adding multiple CRUD controllers and want to avoid route name conflicts.
  • url_pattern_prefix – Optional string prefix to add to all crud related url patterns
  • handler_class – The handler class that is used to handle CRUD requests. Must be sub-class of pyck.controllers.CRUDController