Broadleaf’s Metadata Service is responsible for providing expressive metadata as JSON to tell the admin client what it should render and where it should get the data from. This article will cover the different types of metadata the service provides, including how to add new metadata or extend existing metadata.
There are two types of metadata that you will be providing to the admin through the metadata service: routes and components. Routes provide the admin client with information on how to route the user around the application. The route configuration for the admin will be fetched and cached when it initially loads. When we have a match on a route, the admin client will fetch and cache the component metadata referenced by that route. Once the admin has the component metadata for a route, it will select the React component referenced by the metadata, and render it.
Routes are the first piece of metadata the service provides to the admin client.
Routes represent the relationship between a browser’s location, and the view it renders.
These routes typically consist of a path, e.g. /brands, and a componentId, e.g. brands:browse.
The admin client loads the entire route configuration on page load, and then uses it to route the user around the application.
Routes will be created using a Java DSL within a Spring auto-configuration class, for example:
@Configuration
public class BrandMetadataAutoConfiguration {
@Bean
public ComponentRouteLocator brandMetadataRoutes(RoutesBuilder routesBuilder) {
return routesBuilder.routes()
.route("/brands", r -> r.componentId("brands:browse"))
.build();
}
}To learn more about routes, visit our Routes documentation.
Components are the next piece of metadata the service provides to the admin client. Component metadata tells the admin client what component it should render, how it should be configured, and where it should look to retrieve or submit data. The admin client loads component metadata as the user navigates to the route associated with a given component.
Component metadata will be contributed using a Java DSL within a Spring auto-configuration class, for example:
@Configuration
public class BrandMetadataAutoConfiguration {
@Bean
public ComponentSource brandMetadataComponents() {
return registry -> registry
.add("brands:browse", getBrandsBrowse());
}
private EntityBrowseView<?> getBrandsBrowse() {
return Views.entityBrowseView()
.label("Brands")
.defaultGrid(brandsGrid -> brandsGrid
.readUrl("/brands")
.addColumn("name", Columns.string().label("Name"))
.addColumn("url", Columns.string().label("Url"))
);
}
}To learn more about view components, visit our Views documentation.
Broadleaf provides a number of metadata components out-of-box for its various services. While the metadata provided works for most scenarios, there are going to be situations where it needs to be extended. This is why we designed the metadata DLS to be highly extensible at its core.
Component metadata provided by Broadleaf can be extended by registering a ComponentSource bean similarly as when adding new metadata, for example:
@Configuration
public class MyProductMetadataAutoConfiguration {
@Bean
public ComponentSource myProductMetadataComponents() {
return registry -> {
EntityBrowseView<?> productBrowse = (EntityBrowseView<?>) registry.get(ProductIds.BROWSE);
// extend the product grid to include an additional column
productBrowse.getDefaultGrid()
.addColumn("brandCode", Columns.string()
.label("Brand Code")
.order(5000));
};
}
}It’s also possible to override metadata from the Admin UI itself. This is termed "augmentation." These overrides do not require any server changes or restarts. This is the successor to the custom fields feature in legacy Broadleaf.
Learn more by reading Metadata Augmentation in the Admin UI.