LaaS UI Elements
An overview of the types of user interface elements you can create in the Community Manager developer portal with lifecycle integration, with illustrations.
Table of Contents
Overview
In Repository Client, in the Global Definition Template, defining the classifier type is part of defining the classifier, as shown below.
Use the table below to help choose data types in Repository Client so that you can create the fields that you want to add in the Community Manager developer portal.
| To create this type of field in Community Manager | Choose this type of data in Repository Client | Can be multi-valued? |
|---|---|---|
|
A field that offers, or enforces, a Boolean value, such as yes/no or on/off. |
boolean classifier. Examples: |
No |
|
Date field. |
date classifier. Examples: |
Yes |
|
Any sort of numeric field, such as integer, decimal, or currency. |
decimal classifier. Examples: |
Yes |
|
Text field including single value or multi-value, simple text or drop-down list, a combination where the user can either choose from a predefined list or provide a user-defined value, or a linked series of closed selection lists (taxonomy). |
string classifier. Examples: |
Yes |
|
URL. |
By-reference artifact. Examples: |
Yes |
Boolean fields
If you want to create a Boolean field in the Community Manager developer portal, use the boolean classifier type in Repository Client.
For Boolean fields you can:
- Make it required
- Make it optional
- Prepopulate a value that is not editable by the user
A sample snippet defining a boolean field in the gdt.xml file is shown below. This classifier defines whether a license is required to use an API.
<define-classifier display-name="Licensing Required" help-text="Indicates whether licensing is required to use the asset" max-occurs="1" name="licensing-required" type="boolean" />
The example below, from a gdt.xml file, illustrates the use of a Boolean field to define an extension properties field in the Community Manager developer portal. This example defines the Allow Anonymous Access field, usually the user's choice, as a read-only field set to No as a security measure.
<define-classifier display-name="Approval Required" help-text="Require approval for access to this implementation. Note that this classifier is only relevant when anonymous access is not allowed." max-occurs="1" name="access-approval-required" type="boolean" />
The examples below show Boolean fields in the Community Manager developer portal.
Date fields
If you want to create a date field in the Community Manager developer portal, use the date classifier type in Repository Client.
The example below, from a gdt.xml file, defines a date field. This example defines the date the asset went into production, as an additional piece of metadata about the asset.
<define-classifier display-name="Production Date" help-text="Date this asset entered production" max-occurs="1" name="production-date" type="date">
For date fields you can:
- Make it required for the user to choose a single date
- Make it optional for the user to choose a single date
- Prepopulate a single value not editable by the user
- Make it required for the user to choose multiple dates
- Make it optional for the user to choose multiple dates
- Prepopulate multiple values not editable by the user
The examples below show single-value date fields in the Community Manager developer portal.
Decimal (number) fields
If you want to create a numeric field in the Community Manager developer portal, use the decimal classifier type in Repository Client.
The example below, from a gdt.xml file, defines a classifier for information about the cost of developing an asset. In this example, the field could be constrained to take two decimal places for a monetary value by using a validator. The definition includes min-occurs="1" and max-occurs="1", so the field is required and only one value is accepted.
<define-classifier display-name="Developer License Cost" help-text="Per developer/seat license cost or equivalent for the asset" max-occurs="1" min-occurs="1" name="developer-license-cost" type="decimal" />
The example below, from a gdt.xml file, defines a classifier for information about the number of working days to create an asset. In this example, the field could be constrained to take only an integer by using a validator. The definition does not include a min-occurs value, and includes max-occurs="1", so the field is optional and only one value is accepted.
<define-classifier display-name="Creation Level of Effort" help-text="Creation level of effort to develop this asset in Person Days" max-occurs="1" name="creation-level-of-effort" type="decimal" />
The examples below show single-value decimal fields in the Community Manager developer portal.
String fields
If you want to create a string field in the Community Manager developer portal, use the string classifier type in Repository Client.
There are several types of fields you can create in the Community Manager developer portal with string values. The sections below define them, with illustrations:
- Text fields, single value or multiple values
- Closed enumerated string fields
- Open enumerated string fields
- Taxonomy fields (string)
Text fields, single value or multiple values
For a text field with a single value you can create the following variations:
- Open string single-value required on create: make it required for the user to provide a single value.
- Open string single-value optional on create: make it optional for the user to provide a single value.
- Open string single-value read-only on create: Prepopulate a single value that is not editable by the user.
The example below, from a gdt.xml file, defines a single-value keyword field. The value max-occurs="1" constrains the field to a single value.
<define-classifier display-name="Keyword" help-text="Word that states an aspect of the asset as an aid to searching" name="keyword" type="string" max-occurs="1"> </define-classifier>
The examples below show single-value text fields in the Community Manager developer portal.
For a text field that supports multiple values you can create the following variations:
- Open string multi-value required on create: make it required for the user to provide multiple values.
- Open string multi-value optional on create: make it optional for the user to provide multiple values.
- Open string multi-value read-only on create: Prepopulate multiple values that are not editable by the user.
The example below, from a gdt.xml file, defines a multi-value keyword field that requires input. The value min-occurs="1" constrains the field to at least one value. This definition does not include max-occurs="1", so multiple values are valid input.
<define-classifier display-name="Keywords" help-text="Words that state an aspect of the asset as an aid to searching" name="keyword" type="string" min-occurs="1"> </define-classifier>
The example below shows an open string multi-value required field in the Community Manager developer portal.
Closed enumerated string fields
For closed enum you can:
- Make it required for the user to choose a single value from a closed list.
- Make it optional for the user to choose a single value from a closed list.
- Prepopulate a single value that is not editable by the user.
- Make it required for the user to choose multiple values from a closed list.
- Make it optional for the user to choose multiple values from a closed list.
- Prepopulate multiple values that are not editable by the user.
The example below, from a gdt.xml file, shows a closed enumerated list. The value open="false" indicates that the list is closed. In this example, max-occurs="1" indicates that the user can select only one value from the list, and min-occurs="1" indicates that the field is mandatory—the user must select a value.
<define-classifier display-name="Architecture Layer" help-text="The architecture layer this asset is assigned to" name="architecture-layer" open="false" type="string" value-ordering="GDT" max-occurs="1" min-occurs="1">
<add-value value="Application" />
<add-value value="API" />
<add-value value="Process Service" />
<add-value value="Business Service" />
<add-value value="Data Service" />
<add-value value="Utility Service" />
<add-value value="Component" />
<add-value value="Schema - Service-Specific" />
<add-value value="Schema - Canonical" />
</define-classifier>
The example below, from a gdt.xml file, shows a closed enumerated list. The value open="false" indicates that the list is closed. In this example, there are no values for max-occurs, so multiple values are acceptable, and min-occurs is not defined, so the field is not required.
<define-classifier display-name="Architecture Layer" help-text="The architecture layer this asset is assigned to" name="architecture-layer" open="false" type="string" value-ordering="GDT" max-occurs="1" min-occurs="1">
<add-value value="Application" />
<add-value value="API" />
<add-value value="Process Service" />
<add-value value="Business Service" />
<add-value value="Data Service" />
<add-value value="Utility Service" />
<add-value value="Component" />
<add-value value="Schema - Service-Specific" />
<add-value value="Schema - Canonical" />
</define-classifier>
The examples below show closed enumerated string fields, where the user can choose from a list (unless the field is read-only) in the Community Manager developer portal.
Open enumerated string fields
You can create a field where the user can choose from a list of predefined values for a property or can provide a different value.
The example below, from a gdt.xml file, shows how this might look.
<define-classifier display-name="Required Open Enumerated String" help-text="Help text for Required Open Enumerated String" max-occurs="1" name="required-open-enumerated-string" open="true" type="string"> <add-value value="valueA" /> <add-value value="valueB" /> <add-value value="valueC" /> </define-classifier> <define-classifier display-name="Optional Open Enumerated String" help-text="Help text for Optional Open Enumerated String" max-occurs="1" name="optional-open-enumerated-string" open="true" type="string"> <add-value value="valueA" /> <add-value value="valueB" /> <add-value value="valueC" /> </define-classifier> <define-classifier display-name="Readonly Open Enumerated String" help-text="Help text for Readonly Open Enumerated String" max-occurs="1" name="readonly-open-enumerated-string" open="true" type="string"> <add-value value="valueA" /> <add-value value="valueB" /> <add-value value="valueC" /> </define-classifier>
With an open enumerated field you can create any of the following:
- Required open enumerated string: the user must provide a single value, either from the list or an additional value.
- Optional open enumerated string: the user can provide a single value, either from the list or an additional value.
Only single values are supported for this type of field.
The examples below show open enumerated string fields, where the user can choose from a list or add a value (unless the field is read-only) in the Community Manager developer portal.
Taxonomy fields (string)
With a taxonomy field, you can define a set of valid values for a hierarchy of fields: a primary field, then a secondary field and so on as needed. In the user interface, when the user chooses a value in one field, the list of valid values becomes available for the next field in the hierarchy.
To do this, in Repository Client, define a set of dependent compound classifiers.
The example below, from a gdt.xml file, illustrates a scenario where each entry defines a valid value in the first field and a valid value in the second field. In this example, there are three choices for the first field, and each of those has two valid values in the second field, so a total of six combinations are defined.
<define-compound-classifier display-name="Business Domain" help-text="The business domain to which this asset applies" max-occurs="1" name="business-domain" open="false" value-ordering="GDT">
<fields>
<field help-text="The general domain of applicability" name="general" />
<field help-text="The specific domain of applicability" name="specific" />
</fields>
<add-value value="Shipping|Request"></add-value>
<add-value value="Shipping|Status"></add-value>
<add-value value="Catalog|Product Selection"></add-value>
<add-value value="Catalog|Maintenance"></add-value>
<add-value value="Credit|Payments"></add-value>
<add-value value="Credit|Verification"></add-value>
<add-value value="Not Applicable|"></add-value>
</define-compound-classifier>
The examples below show taxonomy fields in the Community Manager developer portal.
URL fields
If you want to collect a URL in the Community Manager developer portal to reference an artifact, such as upload of an API description document, use the by-reference artifact type in Repository Client.
If you define a by-reference artifact, you can collect the URL for the artifact in the Community Manager developer portal via a URL field.
The example below, from a gdt.xml file, shows how this might look in Repository Client.
<define-artifact category="swagger-api-definition" containment="by-value|by-reference" display-name="Swagger API Definition" help-text="Swagger document defining the API" />
The examples below show URL fields in the Community Manager developer portal.
