F
Fritz Bosch
We are in the process of refactoring our GUI-based test application
for radio equipment and are rewriting a significant part in Python.
The new architecture will substantially be based on the
model-view-controller pattern, as follows:
User Input
|
v
+-------------+ service request service request +-------------+
| aController +----------------+ +----------------+ aTestScript |
+-------------+ | | +-------------+
v v
+--------+ update +------------------+
| aView |<------------+ aModelObject |
+--------+ +------------------+
^
|
v
test equipment
In interactive mode, the user generates stimuli for and performs
measurements on the devices under test via the GUI, using controller
objects. The controller objects send service request to model objects
where the actual work is performed. Changes in the (data of) model
objects are visualized by view objects. So far nothing special ;-)
In order to automate test sequences, the user can also write test
scripts (in Python), which send similar requests to the model objects
(which are also written in Python). This should be made as simple as
possible, as the users are not software developers. For instance, the
user should normally not have to worry about the creation of the model
objects ? these are typically created (in the user's global namespace)
at initialization time (based on configuration files) or interactively
using factories (which are also model objects).
In addition, we have the requirement to record the service requests
resulting from user input in interactive mode, in order to 'replay'
these later - in other words a kind of macro recorder. The recording
should be in the form of a Python script, which could be edited before
its execution. It is important to record the service requests and not
the user's interaction with controller objects. Naturally only the
requests originating from controller objects should be intercepted and
recorded.
For the recording mechanism, we have two very different ideas:
1. The controller objects issue the requests as texts strings,
which are eval'ed to perform the actual service request
invocation. These texts could then be intercepted and
recorded.
2. Using an interceptor (see thread 'Python interceptor package'
of 2004-06-16) to intercept the method invocations of model
objects.
The interceptor then obtains the name of the object from the
user's global namespace (see thread 'Import into specified
namespace' of 2004-09-08), analyses the call parameters and
reconstructs a textual representation of the invocation
(before delegating the invocation to the actual method).
Both approaches have advantages and drawbacks, and we probably don't
see all implications as yet.
Does anyone have experience with such mechanisms, or could point me to
relevant literature or (even better) to open source projects employing
such mechanisms (preferably in Python)?
Thanks in advance
Fritz
for radio equipment and are rewriting a significant part in Python.
The new architecture will substantially be based on the
model-view-controller pattern, as follows:
User Input
|
v
+-------------+ service request service request +-------------+
| aController +----------------+ +----------------+ aTestScript |
+-------------+ | | +-------------+
v v
+--------+ update +------------------+
| aView |<------------+ aModelObject |
+--------+ +------------------+
^
|
v
test equipment
In interactive mode, the user generates stimuli for and performs
measurements on the devices under test via the GUI, using controller
objects. The controller objects send service request to model objects
where the actual work is performed. Changes in the (data of) model
objects are visualized by view objects. So far nothing special ;-)
In order to automate test sequences, the user can also write test
scripts (in Python), which send similar requests to the model objects
(which are also written in Python). This should be made as simple as
possible, as the users are not software developers. For instance, the
user should normally not have to worry about the creation of the model
objects ? these are typically created (in the user's global namespace)
at initialization time (based on configuration files) or interactively
using factories (which are also model objects).
In addition, we have the requirement to record the service requests
resulting from user input in interactive mode, in order to 'replay'
these later - in other words a kind of macro recorder. The recording
should be in the form of a Python script, which could be edited before
its execution. It is important to record the service requests and not
the user's interaction with controller objects. Naturally only the
requests originating from controller objects should be intercepted and
recorded.
For the recording mechanism, we have two very different ideas:
1. The controller objects issue the requests as texts strings,
which are eval'ed to perform the actual service request
invocation. These texts could then be intercepted and
recorded.
2. Using an interceptor (see thread 'Python interceptor package'
of 2004-06-16) to intercept the method invocations of model
objects.
The interceptor then obtains the name of the object from the
user's global namespace (see thread 'Import into specified
namespace' of 2004-09-08), analyses the call parameters and
reconstructs a textual representation of the invocation
(before delegating the invocation to the actual method).
Both approaches have advantages and drawbacks, and we probably don't
see all implications as yet.
Does anyone have experience with such mechanisms, or could point me to
relevant literature or (even better) to open source projects employing
such mechanisms (preferably in Python)?
Thanks in advance
Fritz