Hi
for me its not mixed. Assume
config {
"myLocale": "de_DE"
}
This goes through the formatter, which creates
Map: "myLocale" -> "de_DE"
Then accessing the configuration value as Locale would require an adapter (*in
the existing code its called a* *PropertyAdapter*, which is a
Function<String,T>, which then in the example parses "de_DE" and creates a
correct Locale instance.
Anatole
2014-12-27 0:17 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> 3 sounds good but dont you mix type and format? Format was more
> json/xml/...than types
> Le 26 déc. 2014 23:59, "Mark Struberg" <[email protected]> a écrit :
>
> > 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.
> >
> >
> > 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.
> >
> > I'd suggest that we keep the core API as String only and then add
> > formatters on top of that (if any).
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > There is also a bit of brain to put into array representations. But lets
> > do that later in a separate discussion.
> >
> >
> > 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*
