*Hi Mark*
2014-12-26 23:58 GMT+01:00 Mark Struberg <[email protected]>:
Hi!
Trying to get a discussion stated WITHOUT doing tons of code which we
probably might throw away later anyway.
It seems we are all pretty d'accord that that primary configuration is
done in a String/String key-value style. Native Object style as in JNDI is
out of scope and adds too many restrictions.
*+1 *
Of course there is another layer of 'Types' on top of those Strings. E.g.
if a user likes to configure a Date then we should define a default format
(or rather, various ones) + eventually a 'transformer'.
But that doesn't change the fact that _internally_ it only gets stored as
String.
*In the existing code there was an "internal" interface called
PropertySource, which is quite similar to Deltaspike and also is dealing
strictly with Strings only.Similar all subsequent operations like
combining/aggregating/overriding property sources etc was strictly done on
this internal String representation. Aggregation gets as simple as a simple
BiFunction<String,String,String> then.*
*The Configuration interface extended PropertySource (we may also just
duplicate the methods to make it completely independent), hereby adding*
*- one convenient accessor for each basic wrapper type like short, int,
boolean etc.*
*- one generic accessor where the adapter to be used could be passed
explicitly*
*- one generic accessor where no adapter was passed. In this case
PropertyAdapter itself provides a service interface, where you can access
one by calling PropertyAdapter.getInstance(Class<T> type).*
**
*That way users have*
*- full API comfort for the most common types.*
*- a generic typed access, where they dont have to care on the adapter
(respectively Tamaya can provide default adapters as useful; and companies
can add their own adapters for their internal types as well). Users then
don't have to care about adapters, because they are transparently provided.*
*- the power users, or like in the use case you sent (with the password
decryption) an adapter can also be passed explicitly.*
I'd suggest that we keep the core API as String only and then add
formatters on top of that (if any).
*As long as type support ends up as first class citizen in the API part, I
agree. Basically the existing code already does this implicitly: there is
a method Configuration toConfiguration() defined on each PropertySource, to
get an extended instance, where typed access is offered,*
There are various flavours to define the various formats
1.) don't define it at all. Means we let the application deal with
formatting
2.) Only have String/String in our API but suggest default formats in our
documentation.
3.) Only have String/String in our API and just define standard format
Strings for DateFormatter, NumberFormatter, etc in interfaces or helper
classes.
4.) Have the fully typed API. Means we don't only have a getValue(keyName)
but also a getDate(keyName), etc
5.) Stay String/String in our API (same like 2) but add additional
Formatter helpers on top of it.
*As I said I think clearly 5 is the way to go. Simple "type free" low
level handling, but comfort for users when config is accessed. Something
like:*
*PropertySource lowLevelConfig = PropertySource.current();*
*Configuration cfg = Configuration.of(lowLevelConfig);*
*These things can easily be backed up by service implemented in the core
module.*
I personally like 3 and 5. The main reason is that we are most probably
not able to define all formats here. Thus any typed API we do define would
be limited by nature.
There is one major bullet which we should address/take care of: take care
of timezones and locales. We should really think about those if we define
the formats.
*+1 *
There is also a bit of brain to put into array representations. But lets do
that later in a separate discussion.
*+1 arrays and all kind of collections, or at least list/array; map*
LieGrue,
strub
