TStore class family
TStore is an abstract class and provides no data-specific semantics. However, you can derive subclasses from TStore that do provide storage semantics (for example, TDocumentStore). TStore separates the mechanics of storage from the storage mechanism.
Instantiations of the store class provide the persistence needed by objects and their associated data (for example, presentation data, content data). The instantiation mediates on behalf of these objects with the storage mechanism used to store them.
TDocumentStore provides the interface to the stored document. TDocumentStore should not be subclassed. It is an example of a class derived from the TStore base class to provide storage semantics. TDocumentStore provides an interface for storing and retrieving documents.
The TDocumentStore class can interface with a variety of different storage mechanisms. With storage abstraction, you can derive from TStore to support different storage semantics (for instance, whether data is filed or streamed) and different storage mechanisms. TDocumentComponentStore and TDocumentStore are derived classes used for storing documents and document components respectively.
TPresenterSessionStore is a TStore subclass used for storing persistent presentation data associated with a particular user session (for instance, viewing data in a calendar mode). TPresenterSessionStore should not be subclassed.
For example, OLE" 2.0 uses a flat file. The CommonPoint application system, on the other hand, uses a database. The Basic Document framework supports both of these ways of storing an object's data by defining an abstract TStorageMechanism class, which provides a stream-based API.
A subclass of TStorageMechanism is required to provide the API but is also free to extend the API to take advantage of specific storage services. For example, an OODB-based storage mechanism could add an interface to the API to allow greater addressability than that provided by the standard storage mechanism and its associated document and presenter session stores. Using an OODB-based storage mechanism, each object, rather than just the document state, can be individually identified and accessed.
TSingleBinStorageMechanism and TMultiBinStorageMechanism add interfaces to manage single and multiple storage bins, respectively. Clients of TMultiBinStorageMechanism can create a storage bin for each data category of an object. After a storage bin is created, a client can open an input stream for filing data into memory from storage or an output stream for filing data to the storage bin.
TStandardStorageMechanism is a TMultiBinStorageMechanism subclass that uses TDiskDictionaryOf and File System interface entities to maintain the data. Each storage bin can correspond to a File System interface file (kIndependentData) or a record in the TDiskDictionaryOf (kData, kAnnotation). The collection of storage bins within a storage mechanism corresponds to a File System interface directory.
A TStandardStorageMechanism owns the entire directory, and deleting this store will delete the directory and its contents.
TChildStandardStorageMechanism is a TMultiBinStorageMechanism subclass that uses a TStandardStorageMechanism for its storage. Multiple TChildStandardStorageMechanisms can exist within a TStandardStorageMechanism. Each TChildStandardStorageMechanism represents a collection of bins in the TStandardStorageMechanism.
Externally, each child mechanism appears as an independent storage unit. Operations on the child mechanism only affect the bins associated with the individual child mechanism, and not those of other child mechanisms using the same store.
You should not derive a subclass from TChildStandardStorageMechanism.
TStorageBin is an abstraction to identify a storage bin for the purpose of creating, deleting, opening, and closing it. A storage bin identifies a particular storage area provided by a storage mechanism. For example, a document store would use one bin for document meta-data and another bin for document attributes.
As with TStorageMechanism, TStorageBin does not enforce any high-level semantics. That is, TStorageBin only knows about streams. It has no knowledge of the type of objects it is responsible for storing.
There is no requirement that a child bin form a hierarchy with a parent bin--the default implementation would create all storage bins as nonhierarchical entities within the same storage mechanism. To access an existing data category within a document, you would use a category-defined name:
TStorageMechanism class family
The storage mechanism layer deals with the how of storage. TStorageMechanism provides access to physical storage and does not enforce any high-level semantics. It defines the interface layer, but it also provides for its extensibility. 
TStorageBin
class family
A storage bin identifies a particular storage area provided by a storage mechanism. There are predefined bins for standard data categories in a document (for instance, TDocumentBin).
To extend an existing data category or to add a new data category in a document, you can define a new name, use the name to create a new storage bin, open a stream on this bin, and stream out its data.
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Generated with WebMaker