Data pages have many similarities with other clipboard pages. They are accessed the same way, so it is not necessary to write a Java step to access the data on a data page. Data pages also contain the same kinds of data as a regular page, such as properties and embedded pages.
However, there are important differences between data pages and other clipboard pages.
- Clipboard location
- Read-only data pages (all scopes) appear in the data pages area of the clipboard and not under user pages or system pages.
- Editable data pages (thread and requestor scope) appear in user pages.
- Edit operation – Data pages can be read-only or editable.
- Read-only mode: You cannot add or remove data after the data pages are created.
- Editable/savable mode: You can modify the data after the data pages are created.
- Naming convention – The names of data pages must begin with the string Declare_ (for versions 5.1-6.3 SP1) or either D_ or Declare_ (for version 7.1). Other types of pages cannot begin with these strings.
- Creation – A data page is automatically created whenever any properties on the page are accessed, if the page does not already exist. You do not have to explicitly create these pages by using the Page-New method or other methods. Data pages with parameters are loaded only when mandatory parameters are provided.
- Update procedure – Read-only data pages can have an automatic refresh strategy, which ensures that their contents are up-to-date.
- Database persistence
- Unlike other pages (such as work item pages), read-only data pages cannot be saved.
- As a best practice, use a savable data page. For more information, see Savable data pages.
- Passivation – When a requestor is passivated, all of that user information is serialized and temporarily saved to persistent storage. Editable data pages and savable data pages are saved like normal clipboard pages. If the user clipboard contains any read-only data pages, those pages are not saved. Instead, the system deletes these pages when it passivates the requestor, and then re-creates them whenever they are next referenced by that requestor (after the requestor is reactivated).