Jump to content

Blueprint:InlineValueSet

From Sahana Eden Wiki
Revision as of 08:59, 23 October 2026 by Dominic (talk | contribs) (→Solution Ideas / Proposals)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Inline Components with Specifications from a third Table

Background

Certain data models define semi-abstract components, with concrete specifications and constraints for the component data determined by records in a third table (spec table).

One example are medical analyses (e.g. blood tests), where the concrete analysis results that can be recorded are specified in a third table, including data types and plausible/permitted ranges:

  • Master: med_analysis
  • Component: med_analysis_result
  • Specification: med_parameter

Problems

While the current InlineComponent concept can facilitate the inline data entry for components, it cannot be configured to use specifications from a third table to build the sub-form rows. Validation is done against the component table model alone, without taking constraints from a third table into account.

Additionally, InlineComponent does not limit the sub-form to a fixed set of specifications - any number of records, including multiple of the same type, can be added. Selection of sub-form rows from a set of specifications is not supported.

Analysis / Requirements

We want a SubForm implementation that

  • generates a list of specifications (parameters) that can be selected by the user for data entry (and de-select, if necessary), permitting only one sub-record per spec
  • support the display of additional information about the selectable specs (parameters), such as normal ranges or instructions
  • reads these specification from a third table, including validation constraints for each individual parameter, using them to provide a suitable input field (varying SELECT or text-INPUT) and validate the input
  • creates or updates the sub-records upon form submission, de-duplicating them by specification (parameter), so that only one record per spec can exist (or zero)
  • supports at least one value-field, as well as additional fields for status or references (which could be boolean or choice)
  • can be embedded and configured in CustomCRUDForm declarations, like InlineComponent
  • (possibly) supports a workflow separation, where the initial planning stage allows the selection of parameters, while a later data entry stage only allows the entry of values into already selected parameters (i.e. hiding the selector); reading the current stage/mode either from the master table, or determining it from user permissions (CREATE+UPDATE vs UPDATE-only), or both

Solution Ideas / Proposals

DataSeriesForm is a draft implementation of a widget that renders a form with selectable specifications for sub-record rows. This design has the widget control the entire form rather than only the sub-record rows, and is tailored to the med_analysis use-case rather than generic.

The DataSeriesForm design could be morphed into a SubForm (proposed class name: InlineValueSet) that can be embedded in a CustomCRUDForm, where it would only control the sub-record rows, analogous to InlineComponent or InlineLink. The client-side control script could use Ajax to retrieve the specifications and validate input via either an extended BasicCRUD.validate or a new, specific end-point. Further, it could be generalized to cover use-cases beyond med_analysis, including supporting configurable secondary fields and workflow separation.

Implementation

Feedback