This was exactly my question some days ago. And as far as I remember we
agreed that we have currently only implementations of PropertySource to
read a specific format from a specific location.
Oliver
Am 04.01.15 um 13:45 schrieb Mark Struberg:
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
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E [email protected]
S oliver.b.fischer
J [email protected]
X http://xing.to/obf
