I've commited a first version based on this. The good news is that only a few bundles are affected. Apart from API, we need to update the JMX Resource Provider, the Merge Resource Provider and the Mongo DB Resource Provider. The JCR Resource Provider has already an implementation - while this is wrong, changing this would be incompatible (due to encoding stuff). So I think we should leave it as is. The bundle resource provider never implemented adaptTo(ValueMap) so it reverts to the new default implementation returning an empty map While the servlet and the file resource provider do not implement deep reading, I think we can leave them as is as resources provided by those are leaves in the resource tree and don't have any child resources.
Regards Carsten 2014-03-14 11:42 GMT+01:00 Carsten Ziegeler <[email protected]>: > The only other option I see is to make ValueMap a first class citizen and: > a) add a getValueMap() method to Resource - default implementation in > AbstractResource does the same as ResourceUtil does today > b) clearly state that deep gets are allowed for reading from those maps > c) provide utility code in AbstractResource (or maybe somewhere else) so > implementations do not need to copy the same code over and over again > > This would mean: > a) current code does not need to change, regardless whether ResourceUtil > or adaptTo is used > b) a value map is always provided > c) all value maps support deep reads > d) no code duplication necessary > > Carsten > > > 2014-03-14 11:37 GMT+01:00 Carsten Ziegeler <[email protected]>: > > The idea behind ResourceUtil.getValueMap is that it never returns null >> while resource.adaptTo(ValueMap) can. >> That's the whole point of this utility method. >> >> I assume people who do resource.adaptTo(ValueMap) never check for null >> which is bound to fail >> >> Carsten >> >> >> 2014-03-14 11:30 GMT+01:00 Amit.. Gupta. <[email protected]>: >> >> > FWIW, there are lots of calls to resource.adaptTo(ValueMap) in >>> rendering code. >>> +1 >>> >>> >> >> >> -- >> Carsten Ziegeler >> [email protected] >> > > > > -- > Carsten Ziegeler > [email protected] > -- Carsten Ziegeler [email protected]
