利用者:Theeth/API Design
目次
Introduction
This page will contain informations/opinions on API design, mostly regarding the registration issues.
Definitions
In this text, I will use the following terms:
- extension: python modules/packages that are self sufficient in defining a Blender extension. This can range from a single file to a series of packages.
- Built in RNA types: all RNA types that are defined before any extension comes into play (including extensions that are enabled by default)
- Well defined: a class definition that correctly fulfills the contract of its RNA type
- Register: a class that is registered is recognized as part of the internal RNA system. It is a valid RNA type.
- Unregister: a class that is unregistered is (no longer) a part of the internal RNA system. It is not a valid RNA type.
Protagonists
Types that need registration:
- Operators
- Macro Operators
- ID Property Groups
- UI Elements (Panel, Menu, Header, Generic UI, ...)
- Render Engines
In all cases, the classes need to be well defined before registration.
Things that affect or are affected by registration:
- Defining properties
- Properties on built in RNA types
- Properties on RNA types defined in the same extension
- Loading an extension
- Unloading an extension
Dependencies
Operators
Only after registration:
- Adding operator to a macro
- Need to verify if operator properties can be added after registration or only before. --Theeth 20:52, 7 November 2010 (UTC)
Macro Operators
While macros are also valid operators, they work a bit differently, that's why their dependencies are listed separately.
Only after registration:
- Adding operators in the macro
ID Property Groups
Only after registration:
- Defining properties as part of the group
- Defining a property with the group as its type
- Including using the group as an operator property
Needs to be unregistered after all properties using this type have been removed (including operators)
UI Elements
No dependency. Can be loaded/unloaded in any order.
Note: Order of registration affects drawing order for panels. This is bad and should be changed internally.
Render Engines
No dependency. Can be loaded/unloaded in any order.
Registration Order
The safest "fixed" way:
- ID Property Groups
- Register group
- Define group properties
- Define properties with group as property type
- Operators
- Register operator
- Define operator properties [might have to be done before, not sure]
- Macros
- Register macro
- Add operators to macro
- UI Elements
- Render Engines
Unregistration Order
The safest "fixed" way
- Render Engines
- UI Elements
- Macros
- Operators
- ID Property Groups
- Remove properties with group as property type (only for properties added to built in RNA types)
- Unregister group