Data Model Compiler

Compiles a Data Model into a dynamic .NET type, enabling strongly-typed access and advanced expression evaluation.

Remarks

Overview

The 'Data Model Compiler' transforms a configured Data Model—including its fields, sections, tables, and variables—into a dynamic .NET class at runtime. This enables Grooper to provide strongly-typed, code-friendly access to extracted data, support advanced expression evaluation, and facilitate integration with custom logic or automation.

The compiler generates source code for the data model structure, compiles it into an in-memory assembly, and exposes the resulting types for use in extraction, validation, and scripting scenarios. This approach allows for high performance, type safety, and flexibility when working with complex document schemas.

Role and Usage in Grooper

• Used internally by Grooper to generate dynamic types for each Data Model, supporting property access, variable evaluation, and navigation of hierarchical data.
• Enables advanced features such as calculated fields, validation rules, and custom expressions that reference model elements by name.
• Supports inheritance, parent/child relationships, and variable definitions, ensuring that all aspects of the data model are accessible in code.

How It Works

1. The compiler parses the Data Model and its descendants, generating source code that defines a .NET class structure mirroring the model's hierarchy.
2. Each field, section, table, and variable is represented as a property or nested type, with appropriate type information and documentation.
3. The generated code is compiled into a .NET assembly, which is loaded into memory and made available for use by Grooper's extraction and scripting engines.
4. At runtime, Grooper uses the compiled types to provide strongly-typed access to data instances, evaluate expressions, and execute custom logic.
5. The compiler manages versioning, assembly cleanup, and dynamic type resolution to ensure consistency and performance.

Automatic Compilation

• The compiler is invoked automatically when a Data Model is created or modified.
• In some cases it may be necessary to hard refresh browser sessions or restart services after making changes to the Data Model structure.
• The generated types are used by Grooper's expression editors, validation logic, and automation features to provide IntelliSense, error checking, and code navigation.

Exposing Parent and Sibling Data

The 'Child Of' and 'Sibling Of' properties on Content Type enable advanced data access scenarios by exposing related data elements to the expression environment of a Data Model.

• Child Of:
  When a Content Type is configured with a 'Child Of' parent, all data elements from the parent type are made available in expressions within the child. This allows you to reference parent fields directly in validation rules, calculated values, export mappings, and other expressions. For example, if a "Benefits Change Form" is a child of "Personnel File", you can reference Personnel_File.Employee_ID in any expression on the child.

• Sibling Of:
  The 'Sibling Of' property allows a Content Type to access data from sibling types within the same parent. This is useful for scenarios where related documents or forms need to share or validate data against each other. Sibling data elements are exposed using a property named after the sibling Content Type.

• Expression Environment:
  When these relationships are configured, the compiler generates additional properties in the dynamic type, making parent and sibling data accessible by name. This enables complex, cross-document logic and supports advanced normalization, validation, and export requirements.

Example Data Model and Generated Code Environment

The 'Data Model Compiler' generates a strongly-typed .NET class structure that mirrors the hierarchy of your Data Model. This enables intuitive property access and expression evaluation for all fields, sections, tables, and variables.

Example Data Model Structure

Suppose you have the following Data Model for an invoice:

• Invoice Data Model
  • Invoice Number (Data Field, string)
  • Invoice Date (Data Field, DateTime)
  • Vendor (Data Section)
    • Vendor Name (Data Field, string)
    • Vendor Address (Data Field, string)
  • LineItems (Data Table)
    • Description (Data Field, string)
    • Quantity (Data Field, int)
    • Unit Price (Data Field, decimal)
    • Line Total (Data Field, decimal)
  • Total Amount (Data Field, decimal)
  • Is Paid (Variable Definition, bool)

Generated Code Environment

The compiler transforms this hierarchy into a .NET class with nested types and properties, making each element accessible by name. Any spaces in Data Element names are converted to underscores. For example:

• The root class (e.g., Invoice_Type) exposes properties for each top-level field, section, and table:

  • Invoice_Number (string)
  • Invoice_Date (DateTime)
  • Vendor (nested class representing the Vendor section)
  • Line_Items (collection of nested row classes)
  • Total_Amount (decimal)
  • Is_Paid (bool, variable)

• Nested sections and tables are represented as their own classes or collections:

  • Vendor.Vendor_Name and Vendor.Vendor_Address
  • Line_Items is a collection, with each row exposing Description, Quantity, Unit_Price, and Line_Total

• Parent and sibling data (if exposed via 'Child Of' or 'Sibling Of') are available as additional properties, allowing cross-document logic.