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 >
