Skip to main content

Desktop Client Data Layer

This page documents the desktop-side entity model that mirrors Nuxeo-backed documents, archives, people, organizations, and metadata definitions.

Purpose​

The desktop client data layer is the transport and persistence model used by the desktop runtime. It is responsible for mapping Nuxeo documents into editable Java entities and for converting entity state back into request properties when the client creates or updates content.

Scope​

This page covers the shared desktop entity model in suredms-desktop-client-data. It does not cover the desktop connector runtime or remote API transport, which are documented separately.

Entry Points​

  • SC/suredms-desktop-client-data/src/main/java/com/sureclinical/suredms/entity/BaseEntity.java
  • SC/suredms-desktop-client-data/src/main/java/com/sureclinical/suredms/entity/Archive.java
  • SC/suredms-desktop-client-data/src/main/java/com/sureclinical/suredms/entity/Document.java
  • SC/suredms-desktop-client-data/src/main/java/com/sureclinical/suredms/entity/Person.java
  • SC/suredms-desktop-client-data/src/main/java/com/sureclinical/suredms/entity/Organization.java
  • SC/suredms-desktop-client-data/src/main/java/com/sureclinical/suredms/entity/DataPropertyDef.java

Primary Components​

  • BaseEntity is the shared base class for desktop entities. It stores the backing Nuxeo document, common Dublin Core fields, modified/trash state, request-property generation, and document creation helpers.
  • Archive represents a study or drive archive. It stores the archive identifier, name, content model version, duplication policy, numbering scheme, and lock state.
  • Document represents a persisted archive document. It links to archive, content type, organization, person, form, signatures, lifecycle state, and discrepancy data.
  • Person models contact records and tracks names, role, organization, addresses, country, and activation state.
  • Organization models company or site records and tracks role, primary person, location, time zone, and lock state.
  • DataPropertyDef defines configurable metadata fields, required flags, and visibility rules used by archive content models.

Data Flow​

  1. The desktop client creates entity instances through the registered factory in each type.
  2. The entity loads values from a Nuxeo document in loadProps and loadDublinCodePropertiesFromDoc.
  3. When the user creates or updates an item, the entity writes a PropertyMap through setRequestProperties.
  4. BaseEntity then creates or updates the remote document through the automation client.

Key Behaviors​

  • Each concrete entity registers itself with the factory registry so the runtime can instantiate the correct type from a Nuxeo document type.
  • Entities keep transient UI state separate from persisted state, especially for loaded children, annotations, and cached references.
  • Document and Archive expose product-specific properties such as training flags, controlled-document state, duplication policy, and content model data.
  • Person and Organization maintain both the persisted archive link and the desktop-friendly display fields used in forms and lists.

Dependencies and Integrations​

  • The entities depend on the Nuxeo automation client for document creation, update, and blob retrieval.
  • Shared utility classes such as RemoteExceptionHelper, EnumUtils, and StringUtils keep the entity code compact.
  • The data layer feeds the desktop workflow, quality, signing, and connector modules through the same domain objects.

Edge Cases and Constraints​

  • Some entity classes still support older field names or legacy mappings for compatibility with archived data.
  • Document and Archive are not UI models; they are persistence-aware data contracts.
  • Many fields are marked modified when setters are called so the client can decide whether a save is required.