Here’s a full list of all available settings for the django-scaffold application, in alphabetical order, and their default values.
One of scaffold’s features is that you can order multiple types of content that is attached to a scaffold item. For example, lets say you extend
scaffold.models.BaseSection with a model called Section. By it’s very nature, one section can be the child of another. However, you might also create a model called
Article which has a Foreign-key relationship with a section, and thus is it’s child too. In fact you might even establish a generic foreign key relationship between a model and your
Section model. When this property is set to True, you can order all items relative to each other via the admin interface.
Note that for this to work, all models must share a common field were the order, relative to each other, can be stored as an integer. By default, models that inherit from
scaffold.models.BaseSection assume this field is called ‘order’.
If you don’t want this ordering option to be available in the admin interface for associated content, set this to False.
Default: Not defined
The name of the concrete application which is extending scaffold. Note that this setting is required: scaffold will not work without it.
The location of the model which extends
scaffold.models.BaseSection. By default, it assumes this model is called
Section, thus if you create an app named “pages”, scaffold will try to import
pages.models.Section unless this setting is provided.
The key name under which scaffold stores it’s path cache values. This should only be changed to avoid key collisions in the cache
43200 (that’s equal to 12 hours)
The length of time (in seconds) an item persists in the path cache. The path cache is a way of very quickly (and without a DB call) looking up scaffold items from a url. Note that that adding, editing the slug of, or removing a scaffold item automatically refreshes the cache.
If set to
True this setting will require all slugs to be globally unique. Otherwise, slugs can be reused except among objects with a common parent (in other words, an object cannot have two children with the same slug).
Allows the user to specify the tree model implementation to use. Allowed values are:
Depending on the read/write profile of your site, some node types will be more efficient then others. Refer to the treebeard docs for an explanation of each type.