Blueprint:InlineValueSet: Difference between revisions
| (4 intermediate revisions by the same user not shown) | |||
| Line 17: | Line 17: | ||
While the current <code>InlineComponent</code> 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. | While the current <code>InlineComponent</code> 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, <code>InlineComponent</code> 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. | Additionally, <code>InlineComponent</code> 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 === | === Analysis / Requirements === | ||
| Line 23: | Line 23: | ||
We want a SubForm implementation that | We want a SubForm implementation that | ||
* generates a list of specifications (parameters) that can be selected by the user for data entry (and de- | * 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 | * 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) | * 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) | * 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 <code>CustomCRUDForm</code> declarations, like <code>InlineComponent</code> | * can be embedded and configured in <code>CustomCRUDForm</code> declarations, like <code>InlineComponent</code> | ||
* (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 === | === Solution Ideas / Proposals === | ||
[https://github.com/sahana/eden/blob/dev/modules/core/methods/dseries.py '''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 <code>DataSeriesForm</code> design could be morphed into a <code>SubForm</code> (proposed class name: ''InlineValueSet'') that can be embedded in a <code>CustomCRUDForm</code>, where it would only control the sub-record rows, analogous to <code>InlineComponent</code> or <code>InlineLink</code>. The client-side control script could use Ajax to retrieve the specifications and validate input via either an extended <code>BasicCRUD.validate</code> 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 === | === Implementation === | ||
=== Feedback === | === Feedback === | ||
Latest revision as of 08:59, 23 October 2026
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
CustomCRUDFormdeclarations, likeInlineComponent - (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.