Micro Focus Content Manager SDK 10.0
|
Accessing a Record is discussed briefly in the help but there are a variety of ways to get a TrimMainObject.
As discussed in the help use the Name or Uri to instantiate the object.
This example fetches a Classification by name.
As can be seen a certain knowledge of the object type is required to fetch by name. For example, the name property for each object type is different. For most object types the name property is Name
. Here is a list of those object types where that rule does not apply:
Object Types | Name Property |
---|---|
ActionDef | ActionName |
AgendaItem | Number |
Alert | Description |
Classification | Title |
Communication | Description |
Consignment | Number |
ConsignmentApprover | Record |
ConsignmentIssue | Record |
History | EventDescription |
Location | SortName |
MinuteItem | Description |
OfflineRecord | Title |
Record | Number |
RecordAction | ActionName |
Request | Record |
SavedSearch | FullName |
ScheduledTask | Description |
SharePointItem | UniqueId |
Space | Number |
TodoItem | Description |
UserLabel | FullName |
ZipCode | Postcode |
Even with this information there are still things to be aware of, for example:
Location
constructor and there is more than one match, an exception will be thrown.Classification
, Classification.IdNumber will also work.There are a number of methods available on the Database object. They key difference between these and the object constructors is that these return null if the object cannot be found, while the object constructors throw an exception. These methods are:
Note: The URN property is typically used when you need to persist a database- and object-type independent identifier for the object.
TrimMainObjectSearch may be used in place of the constructor and Database
methods of fetching an object. One benefit when fetching by name, where the name may not be unique, is that you can respond better to the various scenarios.
There are a variety of ways to retrieve an electronic document attached to a Record (or other object type). These are:
Record.GetDocument() is the primary way to get an electronic document from a Record and will be used for most .NET SDK applications. It allows the user to fetch a copy of the document from the document store to their local hard drive. If the document is already in the users cache then it will be retrieved from the cache, rather than from the store.
You may wish to set the Record edit status to 'checked out', without fetching the Record. In this case simply call GetDocument()
with a null outputDocumentName
. For example:
This method of fetching documents was added to improve support for web services. The advantage it has over Record.GetDocument() is that it does not require you to store a new copy of the document, copied from your local cache to the path in the outputDocumentName
parameter. If document store caching is disabled, this property will be empty, unless your application is running as a service or web service.
If your workgroup server has document caching enabled, an application running on that server (not on a client machine) can use the DocumentPathInWgsCache
property to get the location of the document in the workgroup server cache. The benefit of doing so is that the workgroup server cache can be pre-emptively loaded, so that the document can be present in the cache before it is first asked for.
DownloadNotifier implements a download mechanism with two advantages over other document access methods:
DownloadNotifier
is of particular use in web applications, where you will want to start returning the file to the end user as soon as possible, rather than waiting until the entire file has been fetched from the document store, and also where you may wish to have a resumable download.
While this document has focused primarily on Records other main and child objects also implement ITrimDocument, and therefore also support electronic documents. These objects will at least support the Client Cache method of getting the document, and may also implement a method returning an ExtractDocument (such as LocationEAddress )
When building a user interface based on the Content Manager SDK, it can be helpful to use the captioned and localised strings provided by Content Manager. Most strings used by Content Manager are available from the SDK in a way that will account for the user's language choice and changes to captions.
TrimApplication.GetMessage() is used to fetch error and other messages from Content Manager. These messages will automatically account for any custom captions.
Many custom strings can be fetched from an objects Caption
property. This is particularly important when captions have been customised.
This code displays the caption (and plural caption) of the DisposalType
enum followed by the captions for each EnumItem.
The PropertyDef class supplies captions for object properties. Use the code below to get all writable property captions for the Location object. Other static methods to get PropertyDef
objects are:
Search clause captions work similarly to property definitions except that you must get a list of SearchClauseIds, and then construct a SearchClauseDef from the SearchClauseId
. The sample below writes the captions for all Activity search clauses.
Menus in Content Manager are available for inspection as well. Once again a definition object, CommandDef, provides metadata such as the menu or status bar string for each menu item.
FormDefiniton is particularly useful for Records where it is possible to set custom captions on the various properties on the Record entry form. As with the other definition objects, FormDefinition
(and its related classes) are useful for much more than captions, and in fact they are the foundation from which the Content Manager Web Client forms are built.
In Content Manager 8.2, LookupSet items were freed from the restrictions of being of type TrimChildObject. This means that a lookup set item (LookupItem) is now a TrimMainObject, at the same level as the lookup set itself. Why was this done? Mainly to allow for large lookup sets. The parent/child relationship among Content Manager objects imposes practical limits on the number of children a main object can have.
To add a new LookupItem, instantiate it using the LookupSet as the constructor parameter.
You can get a list of lookup items, just as you would any other main object type (e.g. record or location), using TrimMainObjectSearch
, as seen here.
When a Record Type has a Record Number containing both manual and automatic portions, user interaction is required to create the Record. This can be done in the SDK by first suggesting a number (to get the auto-generated portion), and then replacing the manual portion with input from the user.