*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 > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
