> I explained it already a few times: > 1) a format may provide entries of different priorities. > 2) depending on the config location priorities can be different > 3) depending on the input type priorities can be different.
For none of those things we need a FORMATTER. All the mentioned attributes can easily be handled within each PropertySource. At this level we simply don't have any format. The native configuration is String/String only! The 'formatting' is only done at a more outer level (the PropertyAdapters). LieGrue, strub > On Sunday, 4 January 2015, 13:22, Anatole Tresch <[email protected]> wrote: > > See inline... > > - > Anatole Tresch > Glärnischweg 10 > 8620 Wetzikon > Tel +41 (43) 317 05 30 > - > Send from Mobile > >> Am 04.01.2015 um 12:23 schrieb Mark Struberg <[email protected]>: >> >> Hi! >> >> Please check the >> org.apache.tamaya.core.formatspackage >> >> As far as I understand this is just another layer between the end format > and a PropertySource. I fail to understand what it should be used for. What > format should we define for those if any? What about other formats? Imo it > doesn't add enough value. But happy to get it explained. > I explained it already a few times: > 1) a format may provide entries of different priorities. > 2) depending on the config location priorities can be different > 3) depending on the input type priorities can be different. > > So it allows modelling the config parsing separately. There is only a one to > one > mapping for very trivial scenarios! This allows to separate format parsing > making it a true reusable feature not bundled with the propertysource. The > property source is a concrete resource, a concrete format and a defined > ruleset > of priorities that are Applied. > With pattern based config loading you then have a pattern that resolves to a > set > of resources. You can combine that with a number of formats supported (here > also > the effective priorities produced by the formats may vary), which at the end > produced a collection of propertysources. > For both scenarios the format code can be reused instead of being it > hardcoded ! > So its not another layer, its modularity, unbundling and independence of the > formatting logic from the property sources. > >> >> Please list up use cases how this should later be used. >> >> If it is intended as 'base' part for helping other users to > implement their own PropertySources, why don't we simply add a few abstract > base classes into our extensions module? >> > As I said that depends on what we agree core should be or not... > > >> >> LieGrue, >> strub >
