Broadleaf Microservices

Customizing the Broadleaf Admin with Metadata

Broadleaf allows users to define metadata to determine how to display and interact with entities in the Admin UI. Metadata allows configuring endpoints for CRUD operations, which fields to display, validation rules, and so on. The out-of-box entities should already have metadata defined for them. However, users will often want to modify the existing metadata particularly by adding new fields or entirely new entities to display and manage.

Tip
For more on Broadleaf metadata, Check out the Unified Admin docs.

Broadleaf Support Utilities

Broadleaf has set up the underlying metadata with various support classes and enums to make looking up the base views, forms, and fields much easier.

View ID Constants

To reference views, use the *Ids utilities, e.g., CustomerIds. There are three main types of views: CREATE, UPDATE, and BROWSE. Their names are mostly self-explanatory.

  • The forms for creating an entity will appear in the CREATE view.

  • Forms for updates will be part in UPDATE.

  • The main entity grid will be under BROWSE This is what you see when you go to /customers or /products in the admin.

Endpoint Path Constants

To reference the URI paths to the various endpoints needed for CRUD operations, check out the *Paths utilities, e.g., CustomerPaths. The paths can contain path variables, e.g., "/customer/customers/${id}" where the ID is a variable that will be hydrated in the Admin dynamically based on the active entity’s form data.

Request Scope Constants

To reference the request scopes appropriate for the API calls made by the forms related to your entity, see the *Scopes utility. This will always at least include the base scope for the main entity itself since that’s necessary for any CRUD operations, for example PRODUCT or CUSTOMER.

Form ID Constants

Forms other than the general form (i.e., the default form for a view) can be referenced using the *Forms constants. The DSL allows referencing the general form directly since it’s always present rather than custom.

Form Group ID Constants

Form groups can be referenced using *Groups constants.

Form Field ID Constants

Form fields can be referenced via the *Props utility classes, in this case CustomerProps. Therefore, if you wanted to find the name field, you can reference CustomerProps.NAME rather than a "name" string literal. This takes the guess work out of entity field names and risk of typos.

Change Container Constants

Sandbox-trackable entities need to specify their "change containers" to group separate change information under the same top-level entity. These are listed in *ChangeContainers utilities.