Displaying nodes is an intricate mix of functionality that is shared by all apps and that is specific to some app. Here is our logistics of pretty displays.
Like a number of other methods
pretty() is defined as a generic function and added as a method to each app:
app.pretty = types.MethodType(pretty, app)
So although we define
pretty(app, ...) as a generic function, through its argument
app we can call app specific functionality.
We follow this pattern for quite a bit of functions. They all have
app as first argument.
The case of
pretty() is the most intricate one, since there is a lot of generic functionality and a lot of corpus specific functionality, as is evident from examples of the BHSA corpus and one from the Uruk corpus below.
Here is the flow of information for
- definition as a generic function
- this function fetches the relevant display parameters and gathers information about the node to display, e.g. its boundary slots;
- armed with this information, it calls the app-dependent
_pretty()function, e.g. from uruk or bhsa;
_pretty()is a function that calls itself recursively for all other nodes that are involved in the display;
- for each node that
_pretty()is going to display, it first computes a few standard things for that node by means of a generic function
prettyPre(); in particular, it will be computed whether the display of the node in question fits in the display of the node where it all began with, or whether parts of the display should be clipped; also, a header label for the current node will be comnposed, including relevant hyperlinks and optional extra information reuqired by the display options;
- finally, it is the turn of the app-dependent
_pretty()to combine the header label with the displays it gets after recursively calling itself for subordinate nodes.
Above: BHSA pretty display
Below: Uruk pretty display