Data Field Container and Data Element Container - Revision history

Dgreenwood: /* Appearance Properties: CSS styling */

2025-08-15T16:08:24Z

Appearance Properties: CSS styling

← Older revision		Revision as of 11:08, 15 August 2025
Line 124:		Line 124:
	=== Appearance Properties: CSS styling ===		=== Appearance Properties: CSS styling ===

	The "Style Sheet" and "CSS Class" properties allow you to define custom CSS rules that control the appearance and layout of the container and all its descendants in the Grooper Data Viewer (used during a Review for users to review Extract results).		The "'''Style Sheet'''" and "'''CSS Class'''" properties allow you to define custom CSS rules that control the appearance and layout of the container and all its descendants in the Grooper Data Viewer (used during a Review for users to review Extract results).
	* '''Style Sheet''': Defines CSS rules that are applied to the the container and its child Data Elements.		* '''Style Sheet''': Defines CSS rules that are applied to the the container and its child Data Elements.
	* '''CSS Class''': Applies a class name defined in a Style Sheet on a parent Data Element or in an Included Style Sheet set on the Data Model.		* '''CSS Class''': Applies a class name defined in a Style Sheet on a parent Data Element or in an Included Style Sheet set on the Data Model.

Dgreenwood: /* Fill Methods */

2025-08-15T16:07:58Z

Fill Methods

← Older revision		Revision as of 11:07, 15 August 2025
Line 140:		Line 140:
	==== Fill Methods ====		==== Fill Methods ====

	The "Fill Methods" property lets you define a list of automated actions that populate or modify child fields during extraction.		The "'''Fill Methods'''" property lets you define a list of automated actions that populate or modify child fields during extraction.
	* Primarily, "Fill Methods" are used to run "[[AI Extract]]" in Grooper.		* Primarily, "Fill Methods" are used to run "[[AI Extract]]" in Grooper.
	* Fill Methods are executed for each instance of the container.		* Fill Methods are executed for each instance of the container.

Dgreenwood: /* Appearance Properties: CSS styling */

2025-08-15T16:07:32Z

Appearance Properties: CSS styling

← Older revision		Revision as of 11:07, 15 August 2025
Line 131:		Line 131:

	Styles are written using standard CSS syntax.		Styles are written using standard CSS syntax.
	* You can target elements by type (e.g., <code>.DataField</code>, <code>.DataSection</code>), by ~~code~~ name (e.g., <code>.Invoice_Number</code>), or by using the <code>self</code> selector for the container itself.		* You can target elements by type (e.g., <code>.DataField</code>, <code>.DataSection</code>), by name (e.g., <code>.Invoice_Number</code>), or by using the <code>self</code> selector for the container itself.
	* CSS defined at the container level cascades to all child Data Elements, enabling consistent styling across complex hierarchies.		* CSS defined at the container level cascades to all child Data Elements, enabling consistent styling across complex hierarchies.
	* You can combine the "Style Sheet" property with the "Included Style Sheets" property on the Data Model for a combination of global and local styling.		* You can combine the "Style Sheet" property with the "Included Style Sheets" property on the Data Model for a combination of global and local styling.

Dgreenwood: /* Child Configuration */

2025-08-15T16:07:16Z

Child Configuration

← Older revision		Revision as of 11:07, 15 August 2025
Line 119:		Line 119:

	== Child Configuration ==		== Child Configuration ==

			Many configuration options in Grooper are shared across the main container types: '''Data Model''', '''Data Section''', and '''Data Table'''. These properties allow you to control the behavior, appearance, and logic of all child elements within these containers. Understanding these shared properties helps you build more flexible and maintainable document schemas.

			=== Appearance Properties: CSS styling ===

			The "Style Sheet" and "CSS Class" properties allow you to define custom CSS rules that control the appearance and layout of the container and all its descendants in the Grooper Data Viewer (used during a Review for users to review Extract results).
			* '''Style Sheet''': Defines CSS rules that are applied to the the container and its child Data Elements.
			* '''CSS Class''': Applies a class name defined in a Style Sheet on a parent Data Element or in an Included Style Sheet set on the Data Model.
			**<li class="fyi-bullet"> The Data Model's "Included Style Sheets" property allows users to reference a CSS file added to the Project as a Resource File. This allows multiple Data Models across multiple Content Models to utilize the same CSS styling.


			Styles are written using standard CSS syntax.
			* You can target elements by type (e.g., <code>.DataField</code>, <code>.DataSection</code>), by code name (e.g., <code>.Invoice_Number</code>), or by using the <code>self</code> selector for the container itself.
			* CSS defined at the container level cascades to all child Data Elements, enabling consistent styling across complex hierarchies.
			* You can combine the "Style Sheet" property with the "Included Style Sheets" property on the Data Model for a combination of global and local styling.
			* See the [[CSS Data Viewer Styling]] article for a complete writeup, including some information on CSS basics.

			=== Behavior Properties ===

			==== Fill Methods ====

			The "Fill Methods" property lets you define a list of automated actions that populate or modify child fields during extraction.
			* Primarily, "Fill Methods" are used to run "[[AI Extract]]" in Grooper.
			* Fill Methods are executed for each instance of the container.
			** For Data Models, the entire document instance.
			** For single instance Data Sections, the scope of the single extracted section instance (or its "Miss Disposition" instance).
			** For multi instance Data Sections, each record in a repeating Data Section.
			** For Data Tables, each row.
			* You can add multiple Fill Methods, and they will run in the order listed.

			==== Lookups ====

			The "'''Lookups'''" property allows you to configure external data lookups for child fields. This allows you to use one or more "Lookup Specifications" to integrate external data sources (such as SQL databases) into your extraction.
			* Lookups can validate field values, auto-populate additional fields, or provide reference data from databases, XML files, or web services.
			* Each Lookup Specification defines the criteria fields, target fields, data source, and trigger conditions.
			* Lookups can be set to run automatically after extraction, when a field changes, or on demand.

			'''Examples:'''
			* Validate a "Vendor ID" against a master vendor list.
			* Configure a lookup that uses the extracted "Policy Number" field to query an external insurance database. When a match is found, the lookup automatically fills in related fields such as "Provider Name", "Provider Address", and "Contact Number" in the Data Model, reducing manual entry and ensuring data accuracy.
			* Cross-check extracted values with an external system for accuracy.
			==== Variables ====

			The "'''Variables'''" property enables you to define named variables that can be referenced throughout the container and its descendants.
			* Variables can hold static values, results of expressions, or values calculated during extraction.
			* They are accessible to all child fields (via their expression properties: Calculated Value, Is Valid, etc.), Fill Methods, Lookups, and validation rules within the container.
			* Variables are useful for encapsulating reusable logic, storing intermediate results, or driving dynamic behaviors.
			* Variables make it easy to share data or configuration values across the various properties that can access them.

			'''Examples:'''
			* Store a calculated "IsHighValue" flag to trigger special validation or formatting.
			* Define a variable for a tax rate used in multiple calculations.
			* Define a variable "IsInternational" that evaluates to true if the "Country" field is not "USA". Use this to trigger specialized validation or lookup operations.

			==== Validate Rule ====

			The '''"Validate Rule"''' property lets you attach a custom [[Data Rule]] to the container, providing advanced validation logic that applies to the container and all its children.
			* The rule is executed during validation events. Validation events execute:
			** After extraction.
			** When a user edits data.
			* Use Validate Rules to enforce business logic that spans multiple fields, such as cross-field dependencies or aggregate checks.
			* If the rule fails, a validation error is displayed, and the user is prompted to correct the data.

			'''Examples:'''
			* Ensure that the "Total" field matches the sum of line items.
			* Require that at least one contact method (phone or email) is provided.
			* Enforce that a "Date of Birth" is before a "Service Date".

	== Object Model info ==		== Object Model info ==

Dgreenwood: /* Hierarchy */

2025-08-15T15:27:51Z

Hierarchy

← Older revision		Revision as of 10:27, 15 August 2025
Line 117:		Line 117:
	* "Procedures" is a Data Table within each claim, capturing repeating line items.		* "Procedures" is a Data Table within each claim, capturing repeating line items.
	* "Patient Info" and "Totals" are single-instance sections, representing unique parts of the document.		* "Patient Info" and "Totals" are single-instance sections, representing unique parts of the document.

			== Child Configuration ==

	== Object Model info ==		== Object Model info ==

Dgreenwood: /* Hierarchy */

2025-08-15T15:27:15Z

Hierarchy

@@ Line 52: / Line 52: @@
 == Hierarchy ==
-Data Models, Data Sections and Data Tables serve an important role in defining the
+A '''Data Model''' in Grooper defines the complete structure of data to be extracted from a document. Its hierarchy is essential for accurately subdividing documents, capturing complex relationships, and extracting collections of related data.
 == Object Model info ==

Dgreenwood: Created page with "
{{#lst:Glossary|Data Field Container and Data Element Container}}
== About == Certain Data Elements act as "containers" for other Data Elements. These include: * {{IconName|Data Model}} Data Models * {{IconName|Data Section}} Data Sections * {{IconName|Data Table}} Data Tables **
Data Tables are a specialized container for tabular data. They can only contain Data Columns as their children. These container..."

2025-08-15T14:35:27Z

Created page with "<blockquote>{{#lst:Glossary|Data Field Container and Data Element Container}}</blockquote> == About == Certain Data Elements act as "containers" for other Data Elements. These include: * {{IconName|Data Model}} Data Models * {{IconName|Data Section}} Data Sections * {{IconName|Data Table}} Data Tables **<li class="fyi-bullet"> Data Tables are a specialized container for tabular data. They can only contain Data Columns as their children. These container..."

New page

<blockquote>{{#lst:Glossary|Data Field Container and Data Element Container}}</blockquote>

== About ==
Certain [[Data Element]]s act as "containers" for other Data Elements. These include:
* {{IconName|Data Model}} [[Data Model]]s
* {{IconName|Data Section}} [[Data Section]]s
* {{IconName|Data Table}} [[Data Table]]s
**<li class="fyi-bullet"> Data Tables are a specialized container for tabular data. They can only contain Data Columns as their children.

These containers serve three primary purposes:
# '''Organization''': They organize child Data Elements in a Data Model.
# '''Hierarchy''': They create branching points in a Data Element hierarchy (with the Data Model at the root). This allows you to model documents with nested sections, repeating tables, and collections of fields.
# '''Child Configuration''': Container Data Elements share special properties that control how their child Data Elements are displayed and behave during Review, are extracted, certain validation controls, and how lookups are performed.

== Organization ==

Data Models, Data Sections and Data Tables can't extract data without child elements:
* {{IconName|Data Field}} [[Data Field]]s can be added to Data Models and Data Sections
* {{IconName|Data Column}} [[Data Column]]s can be added to Data Tables.

This is why Data Models, Data Sections and Data Tables are called "containers". If nothing else, they are buckets that hold Data Fields and, in the case of Data Tables, Data Columns.

In terms of organization, '''Data Sections''' play an important role. For larger Data Models, it's often useful to group similar Data Fields together. To do this, Data Fields (and other Data Elements) are simply added to a Data Section with no section logic defined.

Grouping Data Elements with a Data Section can:
* Help Grooper designers locate fields in a large Data Model.
* Help Review users using the Data Viewer locate fields when reviewing extraction results.
* Provide useful ways to target Data Elements for CSS styling.

Example:

In this example, the "Header Details" and "Amounts" sections are used to organize Data Fields related to invoice processing.
: {{IconName|Data Model}} Data Model
:: {{IconName|Data Section}} '''Header Details'''
::: {{IconName|Data Field}} Vendor
::: {{IconName|Data Field}} Invoice Number
::: {{IconName|Data Field}} Invoice Date
::: {{IconName|Data Field}} Due Date
:: {{IconName|Data Section}} '''Amounts'''
::: {{IconName|Data Field}} Subtotal
::: {{IconName|Data Field}} Tax
::: {{IconName|Data Field}} Discounts
::: {{IconName|Data Field}} Amount Due

*<li class="attn-bullet"> When adding a Data Section '''only''' used to organize child Data Elements. Be sure to configure the following properties:
** Leave "Extract Method" blank.
** Set "Scope" to ''Single Instance''.
** Set "Miss Disposition" to ''Default to Parent''.
***<li class="fyi-bullet"> Because this kind of Data Section doesn't have an extract method defined, its child extractors will fail if you don't set the Miss Disposition properly. Without an extract method defined, the Data Section effectively always "misses". Setting to "Default to Parent" ensures its child Data Elements have a document instance to extract from.

== Hierarchy ==

Data Models, Data Sections and Data Tables serve an important role in defining the

== Object Model info ==

Important Note:
* Data Model, Data Section, and Data Table all inherit from "Data Field Container"
** "Data Element Container" inherits from Data Field Container
** ''Only'' Data Model and Data Section inherits from Data Element Container.
* Data Table inherits from "Data Field Container" '''not''' Data Element Container.

=== Data Field Container ===

Type name: '''{{TypeName|Data Field Container}}'''

{{Inheritance|Grooper Object|Connected Object|Node|Data Element|Data Field Container}}

<big>Derived Types</big>

::::: '''Data Field Container''' (''{{HelpLink|Data Field Container}}'')
:::::: {{WikiHelpLinks|Data Element Container}}
::::::: {{WikiHelpLinks|Data Model}}
::::::: {{WikiHelpLinks|Data Section}}
:::::: {{WikiHelpLinks|Data Table}}

=== Data Element Container ===

Type name: '''{{TypeName|Data Element Container}}'''

{{Inheritance|Grooper Object|Connected Object|Node|Data Element|Data Field Container|Data Element Container}}

<big>Derived Types</big>

:::::: '''Data Element Container''' (''{{HelpLink|Data Element Container}}'')
::::::: {{WikiHelpLinks|Data Model}}
::::::: {{WikiHelpLinks|Data Section}}

[[Category:Document Modeling]]