Blueprint:InlineValueSet - Revision history

Dominic: /* Solution Ideas / Proposals */

2026-10-23T08:59:32Z

Solution Ideas / Proposals

← Older revision		Revision as of 08:59, 23 October 2026
Line 32:		Line 32:

	=== 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.		[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.		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 ===

Dominic: /* Solution Ideas / Proposals */

2026-10-23T08:58:00Z

Solution Ideas / Proposals

← Older revision		Revision as of 08:58, 23 October 2026
Line 32:		Line 32:

	=== 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.

	=== Implementation ===		=== Implementation ===

	=== Feedback ===		=== Feedback ===

Dominic: /* Analysis / Requirements */

2026-10-23T08:36:44Z

Analysis / Requirements

← Older revision		Revision as of 08:36, 23 October 2026
Line 29:		Line 29:
	* 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 ~~stage~~ 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 from the master table, or from user permissions (CREATE+UPDATE vs UPDATE-only)		* (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 ===

Dominic: /* Analysis / Requirements */

2026-10-23T08:35:45Z

Analysis / Requirements

← Older revision		Revision as of 08:35, 23 October 2026
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-~~selected~~), permitting only one sub-record per spec		* 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 stage 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 from the master table, or from user permissions (CREATE+UPDATE vs UPDATE-only)

	=== Solution Ideas / Proposals ===		=== Solution Ideas / Proposals ===

Dominic: /* Problems */

2026-10-23T08:30:32Z

Problems

← Older revision		Revision as of 08:30, 23 October 2026
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 ===

Dominic: /* Problems */

2026-10-23T08:29:21Z

Problems

← Older revision		Revision as of 08:29, 23 October 2026
Line 15:		Line 15:
	=== Problems ===		=== Problems ===

	~~Wile~~ 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.

Dominic: Created page with "* All Blueprints == 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/p..."

2026-10-23T08:27:02Z

Created page with "* All Blueprints == 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/p..."

New page

* [[Blueprint:Index|All Blueprints]]

== 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: <code>med_analysis</code>
* Component: <code>med_analysis_result</code>
* Specification: <code>med_parameter</code>

=== Problems ===

Wile 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.

=== 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-selected), permitting only one sub-record per spec
* 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 <code>CustomCRUDForm</code> declarations, like <code>InlineComponent</code>

=== Solution Ideas / Proposals ===

=== Implementation ===

=== Feedback ===