Skip to content
EN FR

View projections and UXfc

Documentation status: guide — see Maturity and evidence.

A logiCells view is a projection of a concept, class, object, relation, process, or service in a particular interaction context. It is not the owner of the domain model and it is not defined by one concrete widget toolkit.

Design a view in this order

  1. Identify the conceptual target being projected.
  2. Identify the user intention: exploration, selection, consultation, edition, validation, navigation, comparison, sequencing, or another stable interaction goal.
  3. Choose the functional components required by that intention.
  4. Declare the page data surfaces and event contracts.
  5. Bind the functional components to those surfaces.
  6. Select or register the concrete implementation for the target platform.
  7. Keep appearance, styling, skins and exact layout outside the reusable functional contract.

Class-level and object-level views

A class-level view normally receives concept-level context and is suited to browsing, search, selection, creation, or lists of instances. An object-level view receives instance context and is suited to details, editing, validation, workflow steps, or object-specific dashboards.

Functional and intentional components

A functional component says what interaction function is required, for example a field, list, tabular view, split view, tabbed view, status surface, consultation frame, selector, action panel, or reactive region. An intentional UXfc component says why the interaction exists: explore, select, consult, edit, validate, navigate, compare, or sequence.

The reusable contract is therefore:

user activity
 -> interaction intention
 -> functional constraints
 -> UXfc/functional component
 -> registered concrete implementation
 -> rendered interface

Non-visual parameters

Prefer functional parameters such as data source name, selected identifier, current cursor, navigation mode, history policy, validation prerequisites, selection cardinality, and event contracts. Avoid making color, toolkit-specific class names, pixel layout, or implementation details part of the conceptual model.

Events

Component events should describe meaning rather than implementation. SelectionChanged, ResourceLoaded, ValidationRequested, Reload, or Browse are better reusable contracts than events named after a particular control or component instance.