Validate
||
Pedestal
Validated HTML 4.0
Pedestal has a command hierarchy similar to that of other frameworks, though with some slight differences. Instead of bearing anthropomorphic names like Bureaucrat and Commander, Pedestal's units of control are simply called 'tasks'. Another, perhaps less nominal difference is that the tasks represented by the abstract Task class (PedTask) are not comingled with views or panes. A task represents some process of finite duration that has a discrete beginning, middle, and end. While some screen elements may be associated with tasks, they are distinct: A click in the close box is interpreted as a command to close the window by the Window class, but the fulfillment of that command (or its cancellation, as well as the invocation of a 'save changes' dialog to determine which) is handled by a task (specifically, an agent).
[Editor's note: PedView now derives from PedTask, so the above information is no longer entirely correct. It happens. -- jdj, 2000-10-17]
Tasks may have subtasks to whom subsets of the parent task's responsibility is delegated. The root task is the application itself, whose purpose is to provide some core functionality to the user, and host an interface to expose that functionality. Subclasses include Agents (PedAgent), which manage windows (e.g. setting the window's name, deciding to close the window immediately or ask the user first), Documents (PedDocument), which model documents as we know them (usually with an Agent subtask and a file reference), and Operations (PedOperation), which oversee some operation such as transfering a file or performing a search. While it's quite plausible for an operation to be a kind of task, the derivation of the other subclasses is less intuitive -- and explained thus: Whereas a file transfer has a point of initiation, a point of completion, and the work done in between, an application, agent or document is at some point opened, later closed, and in the interim is processing events. Both have a beginning, middle, and end. The conceptual difference is that an operation is 'getting stuff done' while the user is idle, and the tasks which merely respond to events have nothing to do then, so a document appears as a static 'thing', rather than a running process.
In addition to responding to events, tasks can get time in between events to perform chores. A chore (PedChore) is not a task. Rather than having a beginning, middle, and end, the chore is atomic -- accomplished in one function call -- for example, calling ::TEIdle() or drawing a frame of an animation. In order to be run, a task's chores must be installed either in its repeat queue or its idle queue. The repeat queue is run in between every event, and the idle queue is run only after a null event. A queue is run by sending the appropriate message to the root task, which runs the queue and forwards the message to all of its subtasks.