Hi Stefan, I see the use-case and in a different context I also came across a use-case for 'wildcards' in the rules. I think this would be a good feature. I'll try to prototype something for that over the coming few days and ping back here once I have something to try out.
Cheers, David On 19 August 2016 at 23:16, Stefan Seifert <[email protected]> wrote: > we want to use the converter service as part of the sling context-aware > configuration, and started with a first implementation. [1] > > in sling we have a special form of map (a ValueMap) which supports > additional features like typed access (with a resource provider-specific > conversion magic under the hood), and support for nested maps. we want to > map such valuemaps to annotation classes. this is working fine, but it does > not use the special valuemap typed methods, and nested classes are not > supported either because the child resources are not represented as nested > maps in the valuemap. > > what we need is a custom rule to provide some code to the converter how to > handle the valuemap specifics. but neither the current converter > implementation nor the API defined in [2] seems to support this currently. > > what is supported are rules von converting class A to B and vice versa, > but A and B have to be well-known. what we need is A to X and vice versa, > where A is well-known, but X can by any class (e.g. any project-specific > annotation class). details what we want to do described in [3]. > > is it planned to add such a more flexible rule to the specification (and > implementation)? in the current implementation only one of the rule-related > methods are implemented. > > stefan > > [1] https://svn.apache.org/repos/asf/sling/trunk/contrib/ > extensions/contextaware-config > [2] https://github.com/osgi/design/raw/master/rfcs/ > rfc0215/rfc-0215-object-conversion.pdf > [3] https://issues.apache.org/jira/browse/SLING-5982 > > >
