Traditional applications have custom forms that define the user experience for each type of record (Customer, Order, Invoice etc.). These user experience forms usually have extensive code-behind to control state transitions, workflow, and basic CRUD operations. Making changes to the fields of a record means changing and re-testing the application source code and then going through a complete deployment cycle across all platforms to ensure that a consistent user experience is rendered on all types of devices.
trellispark is built on a Data Agnostic Service architecture and utilizes a dynamic page building framework to eliminate the need for custom user experience forms and the associated code behind.
Why use Dynamic Page Generation?
- Record data is typically presented to Users in a Form
- Forms provide a lot of generic functions:
- Create, Read, Update and Delete (CRUD) of Record data
- Security – what the user can see and do with the Record data
- Control the life-cycle of the Record data
- Calling actions and workflow on the Record
- Dynamic Page Builders enable us to eliminate custom forms
- The Record data is already in a data agnostic storage format such as XML
- Combine with a data driven Form Definition that specifies the user experience
- Significantly reduces effort, cost, time and risk
- Whilst improving quality and robustness of the solution
trellispark DAS-DP renders User Experience at runtime and is implemented in three major components:
- UX Creator – a trellispark application used to create and maintain the Form Definition data used to configure the user experience that will be rendered
- Server-Side API – written in C# and deployed in IIS, used to combine the Form Definitions with the Instance Data of the requested record and current User’s Data to produce a UX Definition
- Client-Side Dynamic Page Builder – written in C#/Blazor, used to render the UX definition on the client’s device
UX Creator
The UX Creator application in the trellispark platform defines a user experience as a set of Form Definitions using configuration data. Changing the Form Definition is as simple as editing the configuration data. These Form Definitions can then be tested in a development environment, validated in a separate QA environment, and then published to production. To promote the Form Definitions across environments, export the required Form Definitions as XML files and then import them into the target environment. Once the import is complete refresh any cached Form Definitions.
When changing the user experience, there is no need to push a new version of the application. This is a minor issue for websites (just one change on the web server). However, for cross-platform applications, consider all the older application versions running on all the devices. At some point they all must be updated. Making sure that all users have the latest version of the application on a phone or tablet is a logistic challenge. Since the Form Definitions are deployed to the central DAS-RSS, the changes are immediately available to all users when they next load/refresh the form.
This is particularly important for publishing applications through a store front. This approach eliminates the wait time because user experience changes no longer require publishing a new version of an application in the app store, waiting for it being reviewed and finally made available to your users for update/download.
What is a Form Definition?
- Completely defines the user’s experience of a Form
- What can the user see?
- What can the user do?
- Determined by several factors:
- The user’s authorization – groups, teams, roles
- The current state of the record being displayed
- Custom business rules (implemented within the Data in Action Service Area)
What can the user see?
- Forms are divided into a set of Tabs
- Each Tab has a set of Rows
- Each Row has a set of Fields
- Each Field implements a single aspect of the Record data
- Display a data field that the user can modify
- Display read-only data – possibly a mash up with other data (ex: Google Maps)
- The Field implementation is generic, and its function is determined by:
- The specific Record data being displayed
- The Form Definition controlling the user experience
What can the user do?
- Forms display commands that can be used to initiate action against the Record
- Separation of Concerns – implemented within the Data in Action service area
- Presentation initiates the action but does not participate in it
- Completion of the command returns a result and the user experience refreshes
- Forms display events that can be used to change the state of the Record
- Special case of a command where the intent is to change record state
- Can cascade state changes down into descendent Records
- Controls the life-cycle of a Record using a State Transition Diagram
- Can initiate action before/after the state transition
- Presentation initiates the action but does not participate in it
- Completion of the command returns a result and the user experience refreshes
Server-Side UX Definition
The UX Definition process sits on a server-side Core API for both security and performance reasons.
Communication between the Client and Server is done over https using data types defined in the Shared project. This project is built using C#.
Endpoints for the Core API are defined using .NET MVC Controllers in the Rest-WebAPI-Core project. This project is built using C#.
The logic used to implement the endpoints is in the Rest-Logic project. This project is built using C#.
The interface to the DAS-RSS database is implemented in the Res-Database project
Client-Side UX Rendering
The UX Rendering process sits on the client’s device to optimize user experience performance and take advantage of the device features. As the user experience starts up it detects which device it is being rendered on, and in the case of mobile devices, the orientation of the device. This information is available to the dynamic page builder as it renders the user experience.
The application state and communication with the Rest-WebAPI-Core endpoints is mediated by the UX-WASM-Services project. This project is built using C#.
If the user experience is running under MAUI on a device, then additional device features are surfaced using the UX-MAUI-Services project. This project is built using C# and the MAUI Essentials package.
All of the user experience rendered by the dynamic page builder is in the UX-WASM-Components project. This project is built using Blazor/C#.
Authentication of users is handled by specific authentication projects written in C#. The following projects are currently available:
- UX-AUTH-AAD – used for Azure Active Directory authentication
- UX-AUTH-SA – used for Stand-Alone authentication (user/password in trellispark)
Deployable applications are a combination of an authentication project, the components project and the services project. The following projects are available:
- UX-MAUI-SA – used for Stand-Alone authentication on devices
- UX-WASM-B2B – used for AAD B2B authentication on WASM websites
- UX-WASM-B2C – used for AAD B2C authentication on WASM websites
- UX-WASM-SA – used for Stand-Alone authentication on WASM websites
Dev Ops
The DevOps section of the academy provides detailed information about how GreatIdeaz builds trellispark. The DevOps section contains three key sub-sections:
- Standards – how to ensure the consistency and quality of trellispark components
- Processes and Procedures – how to perform common task when configuring aspects of trellispark
- Infrastructure – how to download and deploy a trellispark Release
Sustainability Considerations
- Platform specific Dynamic Page Builders
- Can focus on providing high quality user experience
- Are easy to replace as new technology comes available
- Easy to build and test
- Form Definitions
- Reduce the Cost, Effort, Time and Risk to develop user experience
- Blazor WASM for Web and Hybrid Blazor/MAUI for devices
- Moves rendering the client user experience onto the client’s device
- Significantly reduces the server-side infrastructure and network overhead
