Ch 1: Introduction

About CLD

CLD is software for computational language description, which is to say, the viewing and editing of corpora consisting of integrated recordings, texts, and lexicons. The data resides in a CLD file, whose contents may be as small as a single text or wordlist, or as large as a collection of corpora.

CLD runs either as a desktop application or as a web server. This is accomplished by implementing the desktop application as a private local web server that uses a web browser as user interface.

CLD builds on three main substrate components: a server framework, a persistent-object database, and a content framework.

Substrate

The Server Framework

The Server Framework consists of the web server and surrounding classes. The key components are the following:

Persistent-Object Database

The database provides a hierarchical structure represented by persistent objects in Python.

The Content Framework

The Content Framework provides support for implementing an application that runs within the Server Framework. In this framework, the pathname portion of a request addresses web directories, with the final component addressing a web page. Web directories are instantiated as the pathname is processed; the complete hierarchy is not instantiated. Subdirectories and pages correspond to methods of the web directory; different web directories correspond to different subclasses.

State is not stored in the application function but rather on disk, within the database. As a general matter, the web and disk hierarchies are independent of one another: the disk hierarchy represents the structure of the data, whereas the web hierarchy represents the structure of workflows that apply to the data. There may well be correspondences, but there may well also be differences between the two hierarchies.

The main components of the Content Framework are:

Installation

To install the current version of CLD, install Seal:

$ python -m pip install selkie

The following creates a test corpus named foo.cld:

$ python -m seal.script.cld foo.cld create_test

One can then examine or edit it by doing:

$ python -m seal.script.cld foo.cld run

Examples

Echo

Ency

Ency provides a simple example. The class EncyApp specializes SealApp:

>>> from seal.script.encyd import EncyApp
>>> ency = EncyApp('wsgi')

An app maps a request to a response, so in principle we need to create a request that we can pass to the app. But an app automatically converts strings to requests, allowing us to be lazy:

>>> rsp = ency('/seal/index.html')
>>> rsp
<Response 200 text/html;utf-8 553 bytes>

A Response can be printed to see what gets sent back to the browser:

>>> print(rsp)
<html>
<head>
<title>Seal Documentation</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
...
</body>
</html>

If a request leads to a web directory rather than a web page, the app calls the directory's to_page method, if it exists. In the case of an ency directory, it returns a redirect:

>>> ency('/seal')
<Response 303 /index>

For testing purposes, one may get the web directory itself by using the app's follow() method instead of __call__():

>>> ency.follow('/seal')
<Directory seal>