Data Batches

This document briefly outlines what comprises a batch in terms of the Tailbone user interface etc.

Batch Views

Adding support for a new batch type is mostly a matter of providing some custom views for the batch and its rows. In fact you must define four different view classes, inheriting from each of the following:

  • tailbone.views.batch.BatchGrid

  • tailbone.views.batch.BatchCrud

  • tailbone.views.batch.BatchRowGrid

  • tailbone.views.batch.BatchRowCrud

It would sure be nice to only require two view classes instead of four, hopefully that can happen “soon”. In the meantime that’s what it takes. Note that as with batch data models, there are some more specialized parent classes which you may want to inherit from instead of the core classes mentioned above:

  • tailbone.views.batch.FileBatchGrid

  • tailbone.views.batch.FileBatchCrud

  • tailbone.views.batch.ProductBatchRowGrid

Here are the vendor catalog views as examples:

  • tailbone.views.vendors.catalogs.VendorCatalogGrid

  • tailbone.views.vendors.catalogs.VendorCatalogCrud

  • tailbone.views.vendors.catalogs.VendorCatalogRowGrid

  • tailbone.views.vendors.catalogs.VendorCatalogRowCrud

Pyramid Config

In addition to defining the batch views, the Pyramid Configurator object must be told of the views and their routes. This also could probably stand to be simpler somehow, but for now the easiest thing is to apply default configuration with:

  • tailbone.views.batch.defaults()

See the source behind the vendor catalog for an example:

  • tailbone.views.vendors.catalogs.includeme()

Note of course that your view config must be included by the core/upstream config process of your application’s startup to take effect. At this point your views should be accessible by navigating to the URLs directly, e.g. for the vendor catalog views: