This document outlines the UI design and configuration of screens and components for the application. It includes schema requirements, support for dynamic sections, and the necessary master data to facilitate data flow.
Key Points to Consider:
Schema Integration Based on Project Type
The UI design should incorporate schemas that vary depending on the selected project type.
Dynamic rendering of components and fields based on schema definitions.
Enable AddSection Functionality
Provide an option to dynamically add sections to the screen configuration.
Ensure sections can be personalized and managed efficiently.
Master Data Requirements
The following master data sets are required to support the UI design and component configurations:
AppScreenConfigTemplate
Predefined templates for application screen configurations based on project type.
AppScreenConfigPersonalized
Personalized configurations for screens, tailored to specific user roles or preferences.
ComponentMetaDataMaster
Metadata defining the components, such as type, properties, and behavior.
FieldTypeMaster
Master data for supported field types, including their attributes (e.g., input, dropdown, date picker).
Master Data: AppScreenConfigTemplate
Schema Overview
The AppScreenConfigTemplate defines the configuration and structure of application screens. It supports dynamic field addition, sections, comments, and card-based layouts.
{
// Array of screens for the application
"screens": [
{
// Unique name for the screen
"name": "screen1",
// Parent category of the screen
"parent": "Registration",
// Screen headers and descriptions
"headers": [
{
// Header label
"label": "KJHSJKDHKJH",
// Type of the header (e.g., header, info, description)
"type": "header"
},
{
"label": "KJHSJKDHKJH",
"type": "info"
},
{
"label": "KJHSJKDHKJH",
"type": "description"
}
],
// Screen configuration settings
"config": {
// Allows adding fields dynamically to the screen
"enableFieldAddition": true,
// Allows adding sections dynamically to the screen
"enableSectionAddition": true,
// Enables commenting functionality on the screen
"enableComment": true,
// Specifies where fields can be added (e.g., body, header, footer)
"allowFieldsAdditionAt": [
"body"
],
// Specifies where comments can be added
"allowCommentsAdditionAt": [
"body"
]
},
// Cards within the screen (UI components grouped into cards)
"cards": [
{
// Card header text
"header": "Header",
// Card description text
"description": "Desc",
// Fields inside the card
"fields": [
{
// Path for binding data in the field
"jsonPath": "Screen heading",
// Type of the field (e.g., text, dropdown)
"type": "text",
// Label for the field
"label": "dzdzddadadad",
// Specifies if the field is mandatory
"required": true,
// Indicates if the field is active
"active": true,
// Additional metadata for the field
"metaData": {
// Field is read-only
"readOnly": true,
// Field supports comments
"isComment": true
}
},
{
"jsonPath": "Description",
"type": "text",
"label": "dzdzddadadad",
"required": true,
"active": true,
"metaData": {
"isComment": true
}
},
{
"jsonPath": "Description",
"type": "text",
"label": "Address Line 1",
"required": true,
"active": true,
"metaData": {}
},
{
// Unique ID for the field
"id": "field2",
// Field type is dropdown
"type": "dropdown",
// Label for the dropdown field
"label": "Beneficiary Status",
// Additional metadata for dropdown field
"metaData": {
// Field is mandatory
"required": true,
// Options available for the dropdown
"options": [
{
// Label for the dropdown option
"label": "Beneficiary Absent",
// Value associated with the dropdown option
"value": "absent"
},
{
"label": "Delivery Successful",
"value": "successful"
}
]
}
}
]
}
]
},
{
// Placeholder for additional screen configurations
}
]
}
This provides the configuration and metadata for various input field types used in the application. Each field type is mapped to a specific appType and includes metadata such as data types, validation rules, and other properties.
The Drawer Master Data defines the configuration for the list of fields to be displayed in the drawer. Each field includes a label for identification and a fieldType that determines the type of input control to be rendered in the UI.
Step Description: The app configuration master data is fetched from the MDMSv2 (Master Data Management System version 2). This data includes the settings, components, field types, and other configurations that dictate the structure and behavior of the app’s screens and components.
Flow Detail:
The data is fetched asynchronously via an API call to the MDMSv2.
Once the data is fetched, it is stored in the application’s global state using React’s useContext. This ensures the data is accessible across various components throughout the app.
The data might look like:
Screen configurations (e.g., component layout, form field types).
Master data for field types, component metadata, drawer configurations, etc.
Considerations:
Ensure that proper error handling is in place if the API call fails (e.g., retry logic or fallback UI).
The context should be memoized or optimized for performance if the app grows large.
User Interactions (Editing, Adding, Deleting Components):
Step Description: Once the data is loaded and the UI is rendered based on the fetched configuration, users can interact with the UI by editing, adding, or deleting fields and components.
Flow Detail:
Editing: Users can modify the existing field values or configurations. For example, changing field labels, modifying validation rules, or adjusting layout properties.
Adding: Users can add new components, fields, or sections to the form. The UI should dynamically update to accommodate new fields or components.
Deleting: Users can delete specific components, fields, or entire sections, and the UI should reflect these changes instantly.
The updates made by the user are stored in the local state (managed by React’s useState or within the useContext).
Considerations:
The system must handle edge cases such as removing fields that are required or have dependencies.
Ensure that updates are validated locally before sending them back to MDMSv2, to prevent inconsistencies.
Restructuring Data for Web or Mobile Outputs:
Step Description: After the user makes changes, the data must be restructured based on the target platform (e.g., web or mobile). This restructuring ensures that the configuration is correctly formatted to match the specifications required by the platform.
Flow Detail:
Once the data is updated, it is transformed according to the specific platform’s output format. For example:
For web applications, the configuration might need to be structured in a way that fits the web component framework (e.g., React).
For mobile applications, it may need to follow mobile-specific guidelines (e.g., using mobile UI components or formats).
The restructuring process may involve:
Converting configuration fields to fit the layout constraints of mobile screens (e.g., adjusting padding, margins).
Changing input types or validations for mobile responsiveness.
Adapting field types and labels based on the platform (e.g., dropdowns might be replaced with modals on mobile).
Considerations:
This step may require conditional logic to determine which platform the configuration is being prepared for.
It’s crucial that no data is lost during the restructuring process, so careful testing is needed.
Updating MDMSv2 (Client Master Data Structure):
Step Description: After the changes are made and the data has been restructured for the appropriate platform, the final updated configuration needs to be sent back to MDMSv2. This update is stored as the ClientMasterData structure.
Flow Detail:
The modified data is packaged into a ClientMasterData structure, which conforms to the MDMSv2 schema.
An API call is made to send the updated data back to MDMSv2, where it is stored.
The ClientMasterData structure typically includes:
Updated configuration for screens, components, fields, and other UI elements.
Any changes to validation rules, field types, or component properties.
The system should notify the user once the update has been successfully pushed to MDMSv2, ideally with a confirmation message or toast notification.
Considerations:
Ensure data integrity is maintained during the update process.
The system should handle error scenarios (e.g., failed updates, validation errors) and provide appropriate feedback to users.
Implementing a versioning system for the configuration data could help manage updates and rollback scenarios, ensuring consistency over time.
Sequence Diagram
Flow Diagram
App Integration
Once the config is created, if it is directly for MDMS v2, we will enrich it with additional metadata and send it directly to MDMS v2.
If code generation is required based on the alternative approach, we will convert the config into code changes and push it to GitHub for app generation.
