[Admin: This content comes from the original mobile-friendly PDF.]
Implementing UX: Can we dig deeper into the UX model?
Of course! As I just mentioned, the model is used “to retrieve the data and trigger the business logic”. To be clear, this is where you can define your models in whatever way you see fit to fulfill your business needs. First, you must define your models before you can develop your views.
Each model can be made up of the following components:
- Data Sources.
- Child Data Sources.
- Related Data Sources.
- Data Source Fields.
- Data Source Actions.
Before we look at some screenshots, here are some longer descriptions.
|Data Sources||You can define data sources, child data sources, and related data sources to pull together all of the data needed for a model. A data source can be one of several types:
If you have any questions about these data source types, feel free to check out the Application Building for the IBM TRIRIGA Application Platform 3 user guide.
|Child Data Sources||Child data sources are not required, but can also be powerful in shaping the user experience.
They are identical to other data sources, but they operate as children at a lower level beneath their parent data source. In fact, you can add several levels to build a hierarchy of data sources.
To illustrate, let’s say that you defined Spaces Query as your first-level data source. Then you might define Space BO and People Query as second-level child data sources, where the Space BO would be a related (contextual) data source for People Query. Lastly, you might also define Person BO as a third-level child data source of People Query.
With this hierarchy, a user can (1) see a list of spaces, (2) drill into a single space and see people assigned to that space, and (3) drill into a single person record. In our classic framework, this scenario could only be achieved by using many workflows to set variables. In our UX framework, we can achieve this with zero workflows!
|Related Data Sources||Related (or contextual) data sources are not required either. But they can be just as powerful in filtering the results of one data source, based on the context of another data source. Imagine that!
To illustrate, let’s say that you defined Work Task as one data source. Then you might define Responsible Organization as another data source with the related data source of Work Task. You might also define Manager of Organization as yet another data source with the related data source of Responsible Organization.
|Data Source Fields||Each data source must define at least one field. Each field corresponds to a field in the data source type.
To illustrate, let’s say that you defined a data source with a Business Object type. Then each field in your data source references a corresponding field in the business object.
|Data Source Actions||With data source actions, you define which business rules or workflow logic can be triggered by your data source.
For convenience, your actions can also be grouped together into action groups.
Here’s a basic diagram of the data source hierarchy and its relationships.
Next, here’s an example of a blank model metadata form, where you define your model and add its data sources. In case you’re wondering, while new UX applications will use MVC views, the UX metadata will use traditional forms until our UX framework matures. So stay tuned!
Here’s an example of a blank data source metadata form, where you define your data source and add its fields, actions, and child data sources.