Parameters topic is more broad than just a single class. Therefore, in this section,
Parameters base class will be discussed. There are concrete classes that inherit
from this base class and they are discussed in the sections listed below.
The Parameters base class¶
Each module has a class named
Parameters. This class is a base class
for the more specialized
ModuleParameters classes. The purpose of
this base class is to provide functionality and data that is used in both of the specialized
Parameters classes implementation is a little boiler plate mixed with several module-specific changes. This means that for this tutorial (and for any custom modules that you
may write in the future) it is almost certain that you will be changing parts of it.
For the tutorial’s module, please refer to this link for the correct source code for the
Parameters class. Replicate this implementation in the tutorial’s module.
The Parameters class boilerplate¶
The implementation of the
Parameters class contains some boilerplate code. Let’s look
at that boilerplate and what it means.
The top-of-class variables¶
Parameters class defines several class variables.
|api_map||This is a dictionary (use
|api_attributes||This is a list of attributes for the resource being modified as they
are named in the API. This is used when generating the return value
|updatables||This is a list of attributes that should be updatable. The list
contains internal attribute names; i.e., the
|returnables||This is a list of properties that you want to return to the user after
the module finishes running. The names in this list are sent to the
The top-of-class variables should always be defined (even if they are empty) because they are used through the module.
Parameters class has several
@property definitions included in it. These
are not a requirement for all modules. Instead, putting the properties here allows those
properties (and their return values) to be used in both the
Be sure to only put properties here that are 100% common to the API and Module parameters classes. Even a slight deviation in return values among code in the different parameters classes can cause issues.
Some of the common properties that this module has (but that others may not) are:
Parameters should only be used for the things that are truly generic between
ModuleParameters classes. The most common of these are the
top-of-class variables. Links to deeper dives on the concrete classes are listed at the top
of this topic. Use them as an introduction to those classes and their purpose in the module.