The elements of a Smart Container

Smart Containers are templates for the repeated construction of composite objects. Objects within a smart container are linked by folder membership and/or dm_relations and can form an object graph. One of the objects within the template is identified as the primary object – this is the object returned by the factory method invocation.

What kind of objects can be composed? Let’s take a look.

• Documents. These are documents that already exist prior to the construction of the smart container being templated. If they already exist what are they doing in the template? In many use cases the introduction of a single object initiates a workflow that eventually results in a smart container and that document is often part of the smart container. For example, a claim document might be scanned or imported from the web and this document might form the basis of a claim folder with a predefined structure. This claim document then exists before the claim folder, but is part of it. This is one example of an existing document that might be part of a template. In this case its identity would be parameterized (see later).
• Folders. These are part of templates for similar reasons to Documents. A common example might be a pre-existing folder into which you want all the smart container instances to go.
• New Documents. These are documents that you want to be newly created for each smart container instance. You can establish document state such as attribute values in the template.
• New Folders. These are part of templates for similar reasons to New Documents.
• Templates. These define existing objects that are prototypes for a new document in the smart container. For example an empty PDF form – perhaps a questionnaire. A copy of the Template will be created in the smart container.
• Placeholders. Now we enter the ranks of the exotic. Placeholders are objects that have the potential to exist post-construction, but which will not be created at construction of the smart container. They are ghost objects. It is still useful for the smart container designer to be able to model their future presence and specify their location within the smart container. Post construction, placeholders are manipulated with a special interface (IDfSmartObject) available off the primary object. An example might be an approval document.

Templates can have parameterized elements. This is necessary to support parts of the template that can only be resolved at runtime (like the identity of the claim document mentioned above). You refer to runtime parameters within the template using a string substitution syntax – ${foo} resolves to the value of parameter ‘foo’ (the braces are required). At runtime, the values for parameters are provided by the invoker of the factory method in a Map.

Smart containers need to be anchored in a repository somewhere. By default, of course, any sysobject or folder will be created in the user’s home cabinet. If you want an explicit location then you can model this by including a Folder element in the template and linking the object(s) to it. If the folder to which objects are to be anchored is determined at runtime, then the identity of the Folder element would be parameterized. By the way, this is an example of when the root of a hierarchy is not the primary object.

That’s about the whole story. The rest is detail.