The Application Scripting Framework is a component of the Enthought Tool Suite that provides developers with an API that allows traits based objects to be made scriptable. Operations on a scriptable object can be recorded in a script and subsequently replayed.
The framework is completely configurable. Alternate implementations of all major components can be provided if necessary.
The following are the concepts supported by the framework.
Scriptable Type
A scriptable type is a sub-type of HasTraits that has scriptable methods and scriptable traits. If a scriptable method is called, or a scriptable trait is set, then that action can be recorded in a script and subsequently replayed.
If the __init__() method is scriptable then the creation of an object from the type can be recorded.
Scriptable types can be explicitly defined or created dynamically from any sub-type of HasTraits.
Scriptable API
The set of a scriptable type’s scriptable methods and traits constitutes the type’s scriptable API.
The API can be defined explicitly using the scriptable decorator (for methods) or the Scriptable wrapper (for traits).
For scriptable types that are created dynamically then the API can be defined in terms of one or more types or interfaces or an explicit list of method and trait names. By default, all public methods and traits (ie. those whose name does not begin with an underscore) are part of the API. It is also possible to then explicitly exclude a list of method and trait names.
Scriptable Object
A scriptable object is an instance of a scriptable type.
Scriptable objects can be explicitly created by calling the scriptable type. Alternatively a non-scriptable object can be made scriptable dynamically.
Script
A script is a Python script and may be a recording or written from scratch.
If the creation of scriptable objects can be recorded, then it may be possible for a recording to be run directly by the Python interpreter and independently of the application that made the recording. Otherwise the application must run the script and first create any scriptable objects refered to in the script.
Binding
A script runs in a namespace which is, by default, empty. If the scriptable objects refered to in a script are not created by the script (because their type’s __init__() method isn’t scriptable) then they must be created by the application and added to the namespace. Adding an object to the namespace is called binding.
Scriptable objects whose creation can be recorded will automatically bind themselves when they are created.
It also possible to bind an object factory rather than the object itself. The factory will be called, and the object created, only if the object is needed by the script when it is run. This is typically used by plugins.
The name that an object is bound to need bear no relation to the object’s name within the application. Names may be dotted names (eg. aaa.bbb.ccc) and appropriate objects representing the intermediate parts of such a name will be created automatically.
An event is fired whenever an object is bound (or when a bound factory is invoked). This allows other objects (eg. an embedded Python shell) to expose scriptable objects in other ways.
Script Manager
A script manager is responsible for the recording and subsequent playback of scripts. An application has a single script manager instance which can be explicitly set or created automatically.
In the current implementation scriptable Trait container types (eg. List, Dict) may only contain objects corresponding to fundamental Python types (eg. int, bool, str).
This section gives an overview of the API implemented by the framework. The complete API documentation is available as endo generated HTML.
The example application demonstrates some the features of the framework.
This creates a new type based on an existing type but with certain methods and traits marked as being scriptable. Scriptable objects can then be created by calling the type.
script_type is the existing, non-scriptable, type. The new type will be a sub-type of it. The api, includes and excludes arguments determine which methods and traits are made scriptable. By default, all public methods and traits (ie. those whose name does not begin with an underscore) are made scriptable.
The name and bind_policy arguments determine how scriptable objects are bound when they are created. name is the name that an object will be bound to. It defaults to the name of script_type with the first character forced to lower case. name may be a dotted name, eg. aaa.bb.c.
bind_policy determines what happens if an object is already bound to the name. If it is auto then a numerical suffix will be added to the name of the new object. If it is unique then an exception will be raised. If it is rebind then the object currently bound to the name will be unbound.
api is a class or interface (or a list of classes or interfaces) that is used to provide the names of the methods and traits to be made scriptable. The class or interface effectively defines the scripting API.
If api is not specified then includes is a list of method and trait names that are made scriptable.
If api and includes are not specified then excludes is a list of method and trait names that are not made scriptable.
If script_init is set then the __init__() method is made scriptable irrespective of the api, includes and excludes arguments.
If script_init is not set then objects must be explicitly bound and name and bind_policy are ignored.
This takes an existing unscriptable object and makes it scriptable. It works by calling create_scriptable_type() on the the objects existing type and replacing that existing type with the new scriptable type.
See the description of create_scriptable_type() for an explanation of the api, includes and excludes arguments.
The ScriptManager class is the default implementation of the IScriptManager interface.
The IBindEvent interface defines the interface that is implemented by the object passed when the script manager’s bind_event is fired.
The StartRecordingAction class is a canned PyFace action that starts the recording of changes to scriptable objects to a script.
The StopRecordingAction class is a canned PyFace action that ends the recording of changes to scriptable objects to a script.
The key part of supporting application scripting is to design an appropriate scripting API and to ensure than the application itself uses the API so that changes to the data can be recorded. The framework provides many ways to specify the scripting API. Which approach is appropriate in a particular case will depend on when it is a new application, or whether scripting is being added to an existing application, and how complex the application’s data model is.
A scripting API is specified statically by the explicit use of the scriptable decorator and the Scriptable trait wrapper. For example:
from enthought.appscripting.api import scriptable, Scriptable from enthought.traits.api import HasTraits, Int, Str class DataModel(HasTraits): foo = Scriptable(Str) bar = Scriptable(Int, has_side_effects=True) @scriptable def baz(self): pass def weeble(self) pass # Create the scriptable object. It's creation won't be recorded because # __init__() isn't decorated. obj = DataModel() # These will be recorded. obj.foo = '' obj.bar = 10 obj.baz() # This will not be recorded. obj.weeble() # This won't be recorded unless 'f' is passed to something that is # recorded. f = obj.foo # This will be recorded because we set 'has_side_effects'. b = obj.bar
A scripting API can also be specified dynamically. The following example produces a scriptable object with the same scriptable API as above (with the exception that has_side_effects cannot be specified dynamically):
from enthought.appscripting.api import create_scriptable_type from enthought.traits.api import HasTraits, Int, Str class DataModel(HasTraits): foo = Str bar = Int def baz(self): pass def weeble(self) pass # Create a scriptable type based on the above. ScriptableDataModel = create_scriptable_type(DataModel, excludes=['weeble']) # Now create scriptable objects from the scriptable type. Note that each # object has the same type. obj1 = ScriptableDataModel() obj2 = ScriptableDataModel()
Instead we could bypass the type and make the objects themselves scriptable as follows:
from enthought.appscripting.api import make_object_scriptable from enthought.traits.api import HasTraits, Int, Str class DataModel(HasTraits): foo = Str bar = Int def baz(self): pass def weeble(self) pass # Create unscriptable objects. obj1 = DataModel() obj2 = DataModel() # Now make the objects scriptable. Note that each object has a different # type, each a sub-type of 'DataModel'. make_object_scriptable(obj1, excludes=['weeble']) make_object_scriptable(obj2, excludes=['weeble'])
With a more sophisticated design we may choose to specify the scriptable API as an interface as follows:
from enthought.appscripting.api import make_object_scriptable from enthought.traits.api import HasTraits, Int, Interface, Str class DataModel(HasTraits): foo = Str bar = Int def baz(self): pass def weeble(self) pass class IScriptableDataModel(Interface): foo = Str bar = Int def baz(self): pass # Create an unscriptable object. obj = DataModel() # Now make the object scriptable. make_object_scriptable(obj, api=IScriptableDataModel)
Making a type’s __init__() method has advantages and disadvantages. It means that the creation of scriptable objects will be recorded in a script (along with the necessary import statements). This means that the script can be run independently of your application by the standard Python interpreter.
The disadvantage is that, if you have a complex data model, with many interdependencies, then defining a complete and consistent scripting API that allows a script to run independently may prove difficult. In such cases it is better to have the application create and bind the scriptable objects itself.