adminInfo

This section of the wiki provides nearly a definitive guide to all adminInfo tweaks supported by the Vi.

In general, the adminInfo is a member variable defined in the final modules of a ViUR application. This variable targets in most cases to a dict defining several, extending configuration settings which are processed by the administration tool.

As an example, we refer to the Person module as it is explained in the official documentation.

modules/person.py:

class Person(List):
	adminInfo = {
		"handler": "list",
		"name": u"People",
		"icon": "icons/modules/users.svg"
	}

Here you can see three option keys: handler, name and icon. These option keys are used to be generic option keys which can - and in case of handler must be used - in all adminInfo dictionaries in general.

handler

The handler is the only mandatory option required in an adminInfo. It specifies which handler the vi should invoke to render and work on the provided module. This can be either one of the four default handlers "list", "singleton, "hierarchy" and "tree", which are described below. If your project uses a custom handler, this can be specified either.

List is the most commonly used prototype. It implements a flat collection of datasets of the same kind, which can be granulated using filters to particular selections. This prototype is used in most cases, and can be seen like a database table in a relational database management system. Click here for a detailed description of list-specific adminInfo settings.

Singleton is a prototype for implementing modules that hold only one single dataset entry. It can be used for modules that implement application-global settings or a per-user configuration.

Hierarchy is a prototype for a module that stores its data in a hierarchical structure, where every dataset can be a child of another dataset or can have its own children.

Tree is used for implementing modules that store their data in a hierarchy, but differ between nodes and children. The most common usage is the File module, where nodes (Folders) and leafs (Files) are distinguished.

"handler": "list.persons"

Above example is a more distinctive notation for the handler to enable the correct module recognition for module-based plugins additionally to the default behavior relating to the list handler.

name

"name": u"Persons"

This is the name used for the module in the module bar on the left.

icon

"icon": u"/static/images/icons/heads.png"

Specifies a custom icon path to visually better describe the module. The path starty, by default, from the vi/ directory, so that one can specify it to ViUR standard modules using "icons/modules/users.svg" or an absolute path relating to the domain can be specified, like above.

hideInMainBar

This boolean option can be specified, setting it to True, to hide the module in the module bar on the left. Anyway, it the specified information is provided to the Vi to show and run the module in other context, e.g. in case of a relationalBone selection function.

"hideInMainBar": True

sortIndex

Allows to specify another sorting. By default, modules are sorted in alphabetical order. To change this behavior, a sortIndex has to set in the adminInfo to allow for another sorting. The higher the number, the lower it is sorted. The best way is to provide negative sort indices, where the lowest number will be presented the highest.

# first adminInfo...
"sortIndex": 10

# ...second adminInfo
"sortIndex": 20

If different modules share the same sortIndex, they are first sorted by sortIndex, then by alphabetical order.

disabledFunctions

Defines a list of toolbar functions that should be disabled in general.

actions

Defines a list of toolbar functions that should additionally be made available in the module.