On-demand Data Acquisition

Although hugelist has constant complexity, it still doesn't suffice for volatile data; neither for distributed systems, where the data source is a remote machine and all data has to be send via network to the display.

The idea behind on-demand data acquisition is to delay any data gathering until the data is displayed. The application’s logic layer won't be littered with data replication code, too.

A short time frame is used after each user interaction, to gather the next data chunk. This time frame should not exceed 210ms; 70ms to see, 70ms to understand and 70ms to act for the user. This 210ms have to suffice for every kind of data acquisition.

On-demand data gathering is an integral feature of hugelist starting with version 1.5.

On-demand data gathering is controlled by the -ondemandcommand property. ondemandcommand accepts a Tcl-procedure as its value. These procedure gets called for every item, immediately before the item is displayed. Three item properties are being queried via ondemandcommand: text, image and vector.

The ID in Example 3, “ondemandcommand Signature” is the value at the position listindex in the hugelist internal listvariable.

hugelist::create .ondemandlist \
    -ondemandcommand cmd ...

itemconfigure and itemcget operate on the hugelist internal stored data. The listvariable values are thus the identifiers (ID) inside the model. Non of the queried data is being stored inside the hugelist! Thus:

itemconfigure 1 -text xyz

replaces the ID at index 1 with xyz; xyz is then queried for with cmd.

hugelist 1.4 does not had the ability for on-demand data acquisition, but it can be added. Example 5, “Virtual Listbox: Inject” and Example 6, “Virtual Listbox: make Inject” display two Tcl-procedures, which are used to release a »trace« on an internal hugelist storage, for injecting on-demand data acquisition into an hugelist.

Example 5, “Virtual Listbox: Inject” is responsible to query for the necessary data and to replace it inside the hugelist. Inside inject the ID –the index inside the listbox variable– is used to identify the data and the storage location in the hugelist.

Example 6, “Virtual Listbox: make Inject” is a service procedure which releases the »trace« for a given internal storage facility and to extend it with »inject«.

Example 7, “Virtual Listbox” shows how both Example 5, “Virtual Listbox: Inject” and Example 6, “Virtual Listbox: make Inject” are used with a hugelist. The newly traced procedure »inject« is hence called together with »hugelist::display« and queries »inject« for each to be visible item.