Common Objects

Some objects are identified, others are described, and others have interesting lifecycles. Identifiers, descriptions, and lifecycles are common objects in our model, and we handle them systematically.

Identifiers

The identifiers of specifications are menemonic labels provided by administrative users. Their scope varies across specifications:

some identifiers have global scope. This true of questionnaire specifications, for example, which we want to unambiguously identify in space and over time.
some identifiers have questionnaire scope. This is true of selection specifications, for example, which we need to unambiguosuly refer to from other selections or layout components in the questionnaire, but never outside of it.
some identifiers have parent-scope, i.e. can be distinguished from their sibilings in a hierarchy of specification objects.

Instance objects inherit identifiers from their specifications. This preserves parent and questionnaire scope. To preserve global scope too, we randomly post-fix identifiers.

for example, we post-fix questionnaire identifiers to distinguish between instances of the same questionnaire specifications.

Names, Descriptions, and Descriptors

Descriptions come in a variety of forms, including mnemonic names, free-form textual descriptions, and descriptors, i.e. structured descriptions of domain-specific properties.

questionnaire specifications have names that identify them to users, as well as free-form descriptions that document them. Since we show them only to administrative users, we don't need to keep them in multiple languages. We don't propagate them to instances either, because presentation to end-users is responsibility of layout components (titles, paragraphs, headers, etc.).
selections have descriptors that name their dataset and dimension order. We use descriptors in a variety of contexts and for a variety of purposes, from interpreting correctly the coordinates of their points, to formulating queries to the SWS and load them with data.

Lifecycles

Some models are stateful and it's worth to dedicate other objects to track their lifecycle.

We use lifecycle objects to record the current state of objects, e.g. whether lifecycly have been published or campaigns have already started.

We also use lifecycle objects to record the date of creation, the date of the last modification, and the author of last modification. This gives us a log that we can show to administrative users.

Lifecycle ojects are no more that information containers. They don't perform or validate state transitions; what can or cannot be done with or to an object in a particular state of its lifecycle is domain logic implemented elsewhere in the application.

PreviousModel NextQuestionnaires

Last updated 6 years ago

Identifiers

The identifiers of specifications are menemonic labels provided by administrative users. Their scope varies across specifications:

some identifiers have global scope. This true of questionnaire specifications, for example, which we want to unambiguously identify in space and over time.

some identifiers have questionnaire scope. This is true of selection specifications, for example, which we need to unambiguosuly refer to from other selections or layout components in the questionnaire, but never outside of it.

some identifiers have parent-scope, i.e. can be distinguished from their sibilings in a hierarchy of specification objects.

Instance objects inherit identifiers from their specifications. This preserves parent and questionnaire scope. To preserve global scope too, we randomly post-fix identifiers.

for example, we post-fix questionnaire identifiers to distinguish between instances of the same questionnaire specifications.

Names, Descriptions, and Descriptors

Descriptions come in a variety of forms, including mnemonic names, free-form textual descriptions, and descriptors, i.e. structured descriptions of domain-specific properties.

questionnaire specifications have names that identify them to users, as well as free-form descriptions that document them. Since we show them only to administrative users, we don't need to keep them in multiple languages. We don't propagate them to instances either, because presentation to end-users is responsibility of layout components (titles, paragraphs, headers, etc.).

selections have descriptors that name their dataset and dimension order. We use descriptors in a variety of contexts and for a variety of purposes, from interpreting correctly the coordinates of their points, to formulating queries to the SWS and load them with data.

Lifecycles

Some models are stateful and it's worth to dedicate other objects to track their lifecycle.

We use lifecycle objects to record the current state of objects, e.g. whether lifecycly have been published or campaigns have already started.

We also use lifecycle objects to record the date of creation, the date of the last modification, and the author of last modification. This gives us a log that we can show to administrative users.