I just found out that we have to change our idea a little bit, we can't
demand that Resource#adaptTo(ValueMap.class) always returns a value map.
The nice exception is the JcrPropertyResource...
Regards
Carsten
2014-03-14 15:08 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>:
> Hi Felix,
>
> yes, the changes I just committed in fact deprecate
> ResourceUtil.getValueMap() and let that method call resource.getValueMap()
> (if resource is not null of course).
>
> The utility code is an implementation of the value map which supports the
> deep read methods. See the new DeepReadValueMapDecorator class.
>
> Existing implementations which currently return a value map simply need to
> wrap their value map with this new decorator. Of course they are free to
> implement the deep reads by themselves.
>
> I wanted to change the jcr resource provider, but that would introduce
> incompatibilities to a lot of wired path encoding stuff in the
> implementation. So it's safer to leave it as is.
>
> Carsten
>
>
> 2014-03-14 14:58 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>:
>
> Hi
>>
>> Am 14.03.2014 um 11:42 schrieb Carsten Ziegeler <cziege...@apache.org>:
>>
>> > The only other option I see is to make ValueMap a first class citizen
>> and:
>>
>> I think this makes sense independently of deep reads or not -- and maybe
>> we should have done this right when we introduced the ValueMap...
>>
>> > a) add a getValueMap() method to Resource - default implementation in
>> > AbstractResource does the same as ResourceUtil does today
>>
>> In essence ?
>>
>> > ValueMap AbstractResource.getValueMap() {
>> > return ResourceUtil.getValueMap(this);
>> > }
>>
>> or rather copy the ResourceUtil.getValueMap(Resource) method to
>> AbstractResource.getValueMap(), implement the deep-read logic there and do
>>
>> > ValueMap ResourceUtil.getValueMap(Resource r) {
>> > return r.getValueMap();
>> > }
>>
>> while at the same time deprecating ResourceUtil.getValueMap(Resource) ?
>>
>>
>> > b) clearly state that deep gets are allowed for reading from those maps
>>
>> That would go to the JavaDoc of Resource.getValueMap() along with the
>> requirement to never return null.
>>
>> > c) provide utility code in AbstractResource (or maybe somewhere else) so
>> > implementations do not need to copy the same code over and over again
>>
>> What kind of utility code ?
>>
>> What would existing implementations do ?
>>
>> I would assume the JCR-based one would have to be touched to not support
>> deep reads itself, others will benefit. Right ?
>>
>> Regards
>> Felix
>>
>> >
>> > 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 <cziege...@apache.org>:
>> >
>> >> 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. <amitg...@adobe.com>:
>> >>
>> >>> FWIW, there are lots of calls to resource.adaptTo(ValueMap) in
>> rendering
>> >>> code.
>> >>> +1
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> cziege...@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Carsten Ziegeler
>> > cziege...@apache.org
>>
>>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>
--
Carsten Ziegeler
cziege...@apache.org
