Application Scripting Framework =============================== 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. Framework Concepts ------------------ 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. Limitations ----------- In the current implementation scriptable Trait container types (eg. List, Dict) may only contain objects corresponding to fundamental Python types (eg. int, bool, str). API Overview ------------ 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. Module Level Objects .................... ``get_script_manager()`` The application's script manager is returned. One will be created automatically if needed. ``set_script_manager(script_manager)`` The application's script manager will be set to ``script_manager`` replacing any existing script manager. ``scriptable`` This is a decorator used to explicitly mark methods as being scriptable. Any call to a scriptable method is recorded. If a type's ``__init__()`` method is decorated then the creation of the object will be recorded. ``Scriptable`` This is a wrapper for a trait to explicitly mark it as being scriptable. Any change to the value of the trait will be recorded. Simple reads of the trait will not be recorded unless unless the value read is bound to another scriptable trait or passed as an argument to a scriptable method. Passing ``has_side_effects=True`` when wrapping the trait will ensure that a read will always be recorded. ``create_scriptable_type(script_type, name=None, bind_policy='auto', api=None, includes=None, excludes=None, script_init=True)`` 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. ``make_object_scriptable(obj, api=None, includes=None, excludes=None)`` 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. ScriptManager ............. The ``ScriptManager`` class is the default implementation of the ``IScriptManager`` interface. ``bind_event`` This event is fired whenever an object is bound or unbound. The event's argument implements the ``IBindEvent`` interface. ``recording`` This trait is set if a script is currently being recorded. It is updated automatically by the script manager. ``script`` This trait contains the text of the script currently being recorded (or the last recorded script if one is not being currently recorded). It is updated automatically by the script manager. ``script_updated`` This event is fired whenever the ``script`` trait is updated. The event's argument is the script manager. ``bind(self, obj, name=None, bind_policy='unique', api=None, includes=None, excludes=None)`` This method makes an object scriptable and binds it to a name. See the description of ``create_scriptable_type()`` for an explanation of the ``api``, ``includes``, ``excludes``, ``name`` and ``bind_policy`` arguments. ``bind_factory(self, factory, name, bind_policy='unique', api=None, includes=None, excludes=None)`` This method binds an object factory to a name. The factory is called to create the object (and make it scriptable) only when the object is needed by a running script. See the description of ``create_scriptable_type()`` for an explanation of the ``name`` and ``bind_policy`` arguments. ``run(self, script)`` This method runs a script in a namespace containing all currently bound objects. ``script`` is any object that can be used by Python's ``exec`` statement including a string or a file-like object. ``run_file(self, file_name)`` This method runs a script in a namespace containing all currently bound objects. ``file_name`` is the name of a file containing the script. ``start_recording(self)`` This method starts the recording of a script. ``stop_recording(self)`` This method stops the recording of the current script. IBindEvent .......... The ``IBindEvent`` interface defines the interface that is implemented by the object passed when the script manager's ``bind_event`` is fired. ``name`` This trait is the name being bound or unbound. ``obj`` This trait is the obj being bound to ``name`` or None if ``name`` is being unbound. StartRecordingAction .................... The ``StartRecordingAction`` class is a canned PyFace action that starts the recording of changes to scriptable objects to a script. StopRecordingAction ................... The ``StopRecordingAction`` class is a canned PyFace action that ends the recording of changes to scriptable objects to a script. Implementing Application Scripting ---------------------------------- 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. Static Specification .................... 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 Dynamic Specification ..................... 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) Scripting __init__() .................... 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. .. _API: api/index.html .. _example: https://svn.enthought.com/enthought/browser/AppTools/trunk/examples/appscripting/