Reading again I am sure I get your point ;) What benefits should the convertermanager bring? What api? I dont see the connection to my post. Pleae help! Anatole Tresch <[email protected]> schrieb am Fr., 23. Jan. 2015 um 08:20:
> Hi Romain > 1) We already have getProperties() > 2) non scannable propertysources may be not considered: really bad > 3) i need the feature only for single keys typically. > > So I dont agree ;) > Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. 2015 > um 07:54: > > Hi Anatole, reading your last point I'm tempted to say if we export >> the config as a map it is doable through converter API so maybe we >> should give them a bit more space in the API >> (config.getConverterManager() maybe) >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-23 7:49 GMT+01:00 Anatole Tresch <[email protected]>: >> > Hi Oliver >> > >> > The TypeLiteral is also very useful for non muli values. Eg if someone >> > wants to access a parametrized type from a single value. So I think >> > alternatives not using it are worse. >> > >> > I personally clearly prefer the pure String,String design ( especially >> > since i played araound with multiple alternatives in code ). Multivalues >> > can be done with that as well and it adds unnecessary complexity on >> > propertysource. Also it adds basically a redundant level of config: it >> is >> > not sufficient to say.I read key 'x.y'. I also must say if I read a >> single >> > or a multivalue. So we have logically two redundant config layers. For >> me a >> > no go. >> > >> > Said that for me the outcome is clear: >> > - we dont need multivalues >> > - we need typeliterals in addition to what we have. >> > - we need control about the mechanism that is combining entries of >> > subsequent proptertsourced, still keeping overrides as default: >> therefore I >> > proposed the ValueCollector interface. >> > Romain Manni-Bucau <[email protected]> schrieb am Fr., 23. Jan. >> 2015 um >> > 07:28: >> > >> >> Yes but we need tons of methods then, one for List, Set, Map, >> SortedSet, >> >> SortedMap, MultiMap at least. >> >> Le 23 janv. 2015 07:16, "Oliver B. Fischer" <[email protected]> >> a >> >> écrit : >> >> >> >> > Hi, >> >> > >> >> > I prefer the get(...)/getMultivalue(...) approach. >> >> > >> >> > Why? It leads to a cleaner API and expresses the expectation of user. >> >> Even >> >> > if TypeLiteral is working never liked the code I have to write for >> it. >> >> > >> >> > Bye, >> >> > >> >> > Oliver >> >> > >> >> > Am 21.01.15 um 11:46 schrieb Anatole Tresch: >> >> > >> >> >> Which is basically my original proposal. I would say, given what we >> have >> >> >> discussed so far, it would be interesting what others think. >> >> >> I personally also think the basic map design is sufficient. So lets >> >> focus >> >> >> a >> >> >> bit on that so we can then compare the possible solutions ;) >> >> >> >> >> >> Given that I would say we need: >> >> >> - TypeLiterals for being able to pass exactly what tsrget we expect >> >> >> - the possibility of having more control about how a final value is >> >> >> evaluated based on the values returned by the (multiple) property >> >> sources >> >> >> >> >> >> Both festures I think would also be useful for single values. So we >> >> might >> >> >> define a Functional interface PropertyCollector with: >> >> >> >> >> >> string collect(string currecurrentCollected, String newValue); >> >> >> >> >> >> Type conversion is still done with the PropertyConverter we already >> have >> >> >> in >> >> >> place. >> >> >> Wdyt? >> >> >> Romain Manni-Bucau <[email protected]> schrieb am Mi., 21. Jan. >> >> 2015 >> >> >> um >> >> >> 11:29: >> >> >> >> >> >> Point is if property source is responsible then converters are >> quite >> >> >>> useless or design is messy. Was surely a quick win solution but I'm >> >> >>> sure we can do something better. This is possible but change the >> >> >>> design we have of Map<String, String> more or less and moreover how >> >> >>> will you handle maps and other needs? I really think we should >> stick >> >> >>> to key=value and let converters handle other formats >> >> >>> >> >> >>> >> >> >>> Romain Manni-Bucau >> >> >>> @rmannibucau >> >> >>> http://www.tomitribe.com >> >> >>> http://rmannibucau.wordpress.com >> >> >>> https://github.com/rmannibucau >> >> >>> >> >> >>> >> >> >>> 2015-01-21 11:03 GMT+01:00 Tresch, Anatole >> >> <anatole.tresch@credit-suisse. >> >> >>> com>: >> >> >>> (mail from Mark). One of the questions was how to support "arrays" >> at >> >> >>> all. >> >> >>> getList(String key); to the PropertySource. Advantage hereby is >> that >> >> the >> >> >>> property source >> >> >>> based on Strings. Basically this would work as well, though we >> would >> >> then >> >> >>> require >> >> >>> similar to a JDK 8 collector), because the current "default" >> strategy >> >> >>> simply overrides everything >> >> >>> what you want... >> >> >>> [email protected]>: >> >> >>> Given that we have 2 types of config entries returned by a >> >> PropertySource >> >> >>> 1) single value properties, 2) multi value (list properties). >> >> >>> the property source chain into one big list in sequence. The >> >> >>> MultiValueConverter then can decide what todo with them: >> >> >>> ordering, given the entries have some format, e.g. key:value, also >> a >> >> Map >> >> >>> can be created easily with similar possibilities about handling >> >> duplicate >> >> >>> keys etc. >> >> >>> PropertyConverter, just the for arrays... >> >> >>> ordering of ALL values as returned by various property sources for >> a >> >> key. >> >> >>> the converter then receives this ALL list and can do whatever is >> >> >>> appropriate... >> >> >>> [email protected]>: >> >> >>> case of the broader concept, multi-value support. >> >> >>> converter); >> >> >>> first class citizen, hereby keeping so we would end up in a pretty >> >> >>> symmetric API: >> >> >>> converter); >> >> >>> like: >> >> >>> single properties), we have a complete symmetric API >> >> >>> mailto:[email protected]>>: >> >> >>> functionality? >> >> >>> annotation >> >> >>> item >> >> >>> depending on >> >> >>> a >> >> >>> items >> >> >>> methods for >> >> >>> require >> >> >>> available that >> >> >>> the >> >> >>> e.g. >> >> >>> to the >> >> >>> itemType); >> >> >>> available that >> >> >>> e.g. >> >> >>> to the >> >> >>> converter, >> >> >>> e.g. >> >> >>> to the >> >> >>> <mailto:[email protected]>>: >> >> >>> [email protected]<mailto:[email protected]>> >> >> >>> >> >> >> >> >> > -- >> >> > 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 >> >> > >> >> > >> >> >> >
