The Definitions app which is currently in the design phase aims to replace the current Config Overview app PoC. PoC revealed that one of the key features is the ability to group and filter the definitions by various properties. Another important part of the new app is going to the configuration error report. Thanks to the new
Registry API it is now possible to implement both of the things, but unfortunately not without some workarounds and hacks. Here we will list several things that would fill the gaps and make the new definition app developement smoother.
- MAGNOLIA-6086 - Getting issue details... STATUS
- BL-231 - Getting issue details... STATUS
- BL-308 - Getting issue details... STATUS
1. Configuration datasource type in metadata
MAGNOLIA-6081 - Getting issue details... STATUS
Origin/JCR config workspace - if a path is present in config workspace - we could assume that it is served by JCR config source, if path is present in a
ResourceOrigin- then it is file based. Even though this logic works for most of the cases - still it's pretty fragile and also might be costly since such a resolution has to happen for all the definitions displayed in an app.
DefinitionMetadataAPI with a
ConfigSourceTypeproperty easily provided during the metadata population phase via
One thing that might be a concern - what would the config source type be when it comes to definition overlaying? However, I can imagine that overlaying could be done in a form of a layered config source, so this might fit in there as well.
MAGNOLIA-6085 - Getting issue details... STATUS
- If config source type is included into metadata then it would be really simple to add it to
DefinitionQuery and then implement
RegistryFacadeImpl#bySource based on it.
- In addition -
RegistryFacade(?) could at least provide a list of the available
ConfigSourceType's, so that the app could use them in filters.
For the starters
AbstractRegistry.QueryPredicate takes only name and module properties into account. We need to utilise two other existing properties (DefinitionType/location) and possible additional properties in there.
3. Partial name queries
MAGNOLIA-6084 - Getting issue details... STATUS
At the moment
DefinitionQuery already supports regex-search for location accepting the pattern instead of the full value. However, regex are not supported for the name property which is not user friendly at all, since one always remembers only a part of the name => because of that in PoC app we had to query all the definitions from
RegistryFacade and and filter them with Guava capabilities.
MAGNOLIA-6083 - Getting issue details... STATUS
Follow-up proposal: maybe it makes sense to provide arbitrary predicates against the definition metadata
4. Grouped definition query results
To be further discussed
As it was mentioned before, being able to group the definitions by some trait (source type, registry type, module) is another crucial feature for comprehensive configuration UI. Would be nice to combine grouping with filtering. In order to make is simple API-wise, we could add another variant of a
DefinitionQuery execution method.
However, simplest solution here would be probably to do nothing and let the consumers query the filtered query result as they wish with Guava API or similar way.
5. Conversion issues aggregation
To be further discussed
Configuration errors aggregated in UI:
DefinitionProvider only provides info about the issues in a form of a string list. That is not enough to build a UI like above - more meta-information about the issue would be required.
As proposed in following issues: MAGNOLIA-6090 - Getting issue details... STATUS
Problem class could be introduced. It would encapsulate the type of problem (inherently by its type, or by an enum attribute maybe =>
Severity?), and additional relevant properties (short/elaborate/formatted messages etc);
Node2Beanshould be able to track and aggregate errors during the process of conversion. For that we could introduce e.g. a special
Provided that we have an aggregator for the conversion issues, it would be fairly simple to solve the issue since we already recognise the mis-configured properties in Map2Bean
However, we clearly have to add the same to N2B, the exact location is to be defined.
6. Other things
- Possibly allowing for registering the DefinitionTypes/SourceTypes
- Not really relevant to the definitions app
- Verify naming