• Description
• Core Hierarchy Structure
• Critical Distinction: Inheritance vs Copying
• When Inheritance Applies
• Attributes
• How to use it
• Step-by-Step Process
• Creating a Custom Object Master
• Example: Customer Selection Component
• Event Inheritance and Overrides
• Use Cases
• Reusable Components Across Screens
• Use Case 1: Specialized Selection Components
• Use Case 2: Complex Form Patterns
• Default Values and Cascading
• Use Case 3: Company-Wide Defaults
• Special Variants Without Inheritance
• Use Case 4: One-Off Customizations
• Screen and Code Duplication
• Use Case 5: Custom Login Screen
• Best Practices
• Planning Your Hierarchy
• 1. Design Before Building
• 2. Strategic Use of Masters
• 3. Attribute Management
• 4. Documentation Standards
• Common Implementation Patterns
• Pattern 1: Hierarchical Specialization
• Pattern 2: Progressive Enhancement
• Pattern 3: Style Variants
• Troubleshooting Guide
• Changes Not Propagating
• Code Missing After Copy
• Platform Updates Causing Issues
• Migration and Versioning
• Moving from Copies to Inheritance
• Handling Breaking Changes
• Summary

Description

Build.One implements a powerful three-tier inheritance hierarchy that enables code reuse, consistency, and maintainability across applications. The inheritance system flows from Object Types (platform-provided base definitions) through Object Masters (customized versions) to Object Instances (actual usage in screens).

New repository attributes are assigned on the Object Type, where you also provide a default value. The default attributes in Build.One are handled using inheritance. For example, if an Instance object lacks an explicit value, it inherits from the Object Master level, and if the Object Master level also lacks a value, it then inherits the attribute value defined on the Object Type level.

Core Hierarchy Structure

Object Type (e.g., DynSelect - Platform provided)
    ↓ inherits
Object Master (e.g., CustomerDynSelect - Your customization)
    ↓ inherits
Object Instance (Actual usage in forms/screens)

Critical Distinction: Inheritance vs Copying

• Inheritance: Creates an ongoing parent-child relationship where changes to the parent automatically flow to children
• Copying: Creates an independent object with no inheritance relationship - changes to the original do NOT affect the copy

When Inheritance Applies

✅ Inheritance IS active when:

• Creating an Object Master from an Object Type
• Using an Object Master as an Instance in a screen
• Platform updates add new features to Object Types

❌ Inheritance is NOT active when:

• Copying an Object Master to create another Master
• Duplicating screens or forms using copy function
• Creating a “copy of” any object

Attributes

How to use it

When creating a new screen we should always create an Object Master. This will allow us to use the widget (Object Master) in multiple screens without having to redefine all attributes.

Step-by-Step Process

Creating a Custom Object Master

1. Start with an Object Type: Select a platform-provided Object Type (e.g., DynSelect)
2. Create Object Master: Define your customized version with specific attributes
3. Configure at Master Level: Set all common properties, events, and styling
4. Use as Instances: Add the Master to screens where it inherits all configurations

Example: Customer Selection Component

Step 1: Create CustomerDynSelect Master
- Base: DynSelect (Object Type)
- Add customer-specific filters
- Define validation rules
- Set default data source

Step 2: Use in Multiple Screens
- Order Form: Add CustomerDynSelect instance
- Invoice Form: Add CustomerDynSelect instance
- Report Filter: Add CustomerDynSelect instance

Result: All instances inherit from master, updates cascade automatically

Event Inheritance and Overrides

Events defined at the master level are inherited by all instances and can be overridden:

// In CustomerDynSelect master
onInit() {
    // Custom initialization logic
    this.loadCustomerData();
}

// In form instance - can override
onInit() {
    super.onInit(); // Call parent logic
    this.filterByRegion(); // Add instance-specific logic
}

Use Cases

Reusable Components Across Screens

When creating new screens we should always create object masters for our components in order to be able to reuse them in different screens.

Use Case 1: Specialized Selection Components

Scenario: Need customer selection dropdown with consistent behavior across application

Solution:

• Create CustomerDynSelect Master from DynSelect Type
• Configure customer-specific attributes once
• Use instances in Order, Invoice, and Report screens
• Changes to master automatically update all instances

Use Case 2: Complex Form Patterns

Scenario: Address entry forms needed in multiple contexts

Solution:

• Create AddressForm Master with validation and formatting
• Use instances in Customer, Supplier, and Employee screens
• Regional variations handled through instance overrides

Default Values and Cascading

When we require a default value for our component we can always define the default attribute value on the Object Type level.

Use Case 3: Company-Wide Defaults

Scenario: All date pickers should use company standard format

Solution:

• Set format at DatePicker Object Type level
• All masters and instances inherit unless explicitly overridden
• Single point of change for company-wide updates

Special Variants Without Inheritance

Use Case 4: One-Off Customizations

Scenario: Special DeliveryCustomerDynSelect based on CustomerDynSelect

Current Behavior (from real implementation):

CustomerDynSelect → [COPY] → DeliveryCustomerDynSelect

Result:
- DeliveryCustomerDynSelect is independent
- NO inheritance from CustomerDynSelect
- Only inherits from base DynSelect type
- Must be maintained separately

Screen and Code Duplication

Use Case 5: Custom Login Screen

Scenario: Creating custom login based on default

What Happens When Copying:

• ✅ References to code are copied
• ✅ Event handlers are duplicated
• ❌ TypeScript source files NOT automatically copied
• ❌ No inheritance relationship exists

Required Actions:

1. Copy the screen

2. Manually copy TypeScript files if needed

3. Update namespace references (#) to new files

4. Maintain independently

Best Practices

Planning Your Hierarchy

When creating new components to be used in our screens, we should always create an object master and assign its attributes on the Object Master level.

1. Design Before Building

Before creating objects:

• Identify common functionality across all uses
• Determine what needs specialization
• Decide between inheritance (ongoing updates) vs copying (independence)
• Document your hierarchy structure

2. Strategic Use of Masters

Create Object Masters when:

• Multiple screens need the same customized component
• You want centralized control over behavior
• Updates should cascade to all uses
• Consistency is critical

Create Copies (no inheritance) when:

• You need a one-time variant
• The objects will diverge significantly
• You don’t want automatic updates
• Independent evolution is required

3. Attribute Management

Object Type Level: Set platform-wide defaults

• Company standards
• Regulatory requirements
• Universal behaviors

Object Master Level: Configure specific use cases

• Department-specific rules
• Module-specific behaviors
• Shared business logic

Instance Level: Handle exceptions

• Screen-specific overrides
• Contextual adjustments
• Special cases

4. Documentation Standards

Maintain clear documentation of:

• Custom Object Masters and their purpose
• Inheritance relationships and dependencies
• Overridden behaviors at instance level
• Copy vs inheritance decisions and rationale

Common Implementation Patterns

Pattern 1: Hierarchical Specialization

DynSelect (Platform Object Type)
├── CustomerDynSelect (Master for customers)
├── ProductDynSelect (Master for products)
└── UserDynSelect (Master for users)

Pattern 2: Progressive Enhancement

BaseForm (Common validation/structure)
├── CustomerForm (Customer-specific fields)
│   └── EnterpriseCustomerForm (Enterprise additions)
└── SupplierForm (Supplier-specific fields)

Pattern 3: Style Variants

StandardButton (Default styling master)
├── PrimaryButton (Primary action styling)
├── SecondaryButton (Secondary action styling)
└── DangerButton (Destructive action styling)

Troubleshooting Guide

Changes Not Propagating

• Verify inheritance relationship exists (not a copy)
• Clear browser cache and reload
• Check for instance-level overrides blocking inheritance
• Confirm correct master is referenced

Code Missing After Copy

• Manually copy associated TypeScript/JavaScript files
• Update namespace references in copied screen
• Verify all event handlers point to correct files
• Test all functionality thoroughly

Platform Updates Causing Issues

• Review release notes for breaking changes
• Test in development environment first
• Check for conflicts with custom code
• Plan gradual rollout strategy

Migration and Versioning

Moving from Copies to Inheritance

1. Identify duplicated functionality across copies
2. Create consolidated Object Masters
3. Replace copies with instances gradually
4. Test thoroughly at each step

Handling Breaking Changes

1. Create versioned masters (e.g., CustomerDynSelectV2)
2. Migrate instances incrementally
3. Maintain both versions during transition
4. Document differences clearly

Summary

The Build.One inheritance system is designed for maximum reusability and maintainability:

• Always use Object Masters for components used in multiple screens
• Understand inheritance vs copying: Inheritance maintains relationships, copying creates independence
• Configure at the right level: Type for platform defaults, Master for shared behavior, Instance for exceptions
• Document your decisions: Especially when choosing to copy instead of inherit
• Plan before building: Consider your hierarchy structure upfront

Remember: When you want changes to cascade automatically, use inheritance. When you need complete independence, use copying.

Back to Documentation

Back to Home Page