envisage.extension_point module

A trait type used to declare and access extension points.

class envisage.extension_point.ExtensionPoint(trait_type=<class 'traits.trait_types.List'>, id=None, **metadata)[source]

Bases: traits.trait_type.TraitType

A trait type used to declare and access extension points.

Note that this is a trait type and hence does NOT have traits itself (i.e. it does not inherit from ‘HasTraits’).

static bind(obj, trait_name, extension_point_id)[source]

Create a binding to an extension point.

connect(obj, trait_name)[source]

Connect the extension point to a trait on an object.

This allows the object to react when contributions are added or removed from the extension point.

fixme: It would be nice to be able to make the connection automatically but we would need a slight tweak to traits to allow the trait type to be notified when a new instance that uses the trait type is created.

static connect_extension_point_traits(obj)[source]

Connect all of the ‘ExtensionPoint’ traits on an object.

disconnect(obj, trait_name)[source]

Disconnect the extension point from a trait on an object.

static disconnect_extension_point_traits(obj)[source]

Disconnect all of the ‘ExtensionPoint’ traits on an object.

get(obj, trait_name)[source]

Trait type getter.

set(obj, name, value)[source]

Trait type setter.

envisage.extension_point.contributes_to(id)[source]

A factory for extension point decorators!

As an alternative to making contributions via traits, you can use this decorator to mark any method on a ‘Plugin’ as contributing to an extension point (note this is only used on ‘Plugin’ instances!).

e.g. Using a trait you might have something like:

class MyPlugin(Plugin):
    messages = List(contributes_to='acme.messages')

    def _messages_default(self):
        return ['Hello', 'Hola']

whereas, using the decorator, it would be:

class MyPlugin(Plugin):
    @contributes_to('acme.messages')
    def _get_messages(self):
        return ['Hello', 'Hola']

There is not much in it really, but the decorator version looks a little less like ‘magic’ since it doesn’t require the developer to know about Traits default initializers. However, if you know that you will want to dynamically change your contributions then use the trait version because all you have to do is change the value of the trait and the framework will react accordingly.