- v1.0.0-latest-prod
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 has set up the underlying metadata with various support classes and enums to make looking up the base views, forms, and fields much easier.
To reference views, use the *Ids utilities, e.g., CreditAccountIds.
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.
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.
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.
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 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.