[jira] [Commented] (TAMAYA-355) Revise mapping of xml, json and yaml configurations to honor lists

["Anatole Tresch (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAMAYA-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690055#comment-16690055 ] 

Anatole Tresch commented on TAMAYA-355:
---------------------------------------

Enhanced the internal representation of configuration information by extending the existing _*PropertyValue*,_ with
 * _*ObjectValue* extends PropertyValue_, containing a (uniquely) named Map of children, and
 * _*ArrayValue*_ _extends PropertyValue_, containing an (optionally) named array of children.

Children hereby can be any PropertyValue. As a consequence all tree like structures as can be found in JSON, XML, YAML formats can be mapped. By default these structures map to a fully property map as follows:

{{// value 'a' and 'a.b' as _ObjectValue_}}
{{a=b}}
{{a.b.prop1=val1}}
{{a.b.prop2=val2}}

{{// 'a.c' as _ArrayValue_:}}
{{a.c[0]=val1}}
{{a.c[1]=val2}}

{{// Combined}}
{{a=b}}
{{a.c[0]=val1}}
{{a.c[1]=val2}}
{{a.b.prop1=val1}}
{{a.b.prop2=val2}}

Converters hereby have full access to the all PropertyValues as returned by the property sources. And can benefit from this extended functonality if needed. As an example the tamaya-collections module supports both, textual representation and representation by nodes. With the given example also textual representation works:

{{a.b=prop1:val1,prop2:val2}}

or

{{a.c=val1,val2}}

The advantages come, when more complex cases must be mapped, e.g. accessing configuration template classes:

{{List<ServerEndPoint> endpoints = config.get(new TypeLiteral<List<EndPoint>>(){})}}

 

 

> Revise mapping of xml, json and yaml configurations to honor lists
> ------------------------------------------------------------------
>
>                 Key: TAMAYA-355
>                 URL: https://issues.apache.org/jira/browse/TAMAYA-355
>             Project: Tamaya
>          Issue Type: Improvement
>          Components: Core, Extensions
>    Affects Versions: 0.3-incubating
>            Reporter: Anatole Tresch
>            Assignee: Anatole Tresch
>            Priority: Blocker
>             Fix For: 0.4-incubating
>
>
> Given the following config:
> {{<config>}}
> {{  <a>}}
> {{    <b>23</b>}}
> {{  </a>}}
> {{  <a>}}
> {{    <b>15</b>}}
> {{  </a>}}
> {{</config>}}
> The current mapping (in _core_, and the _format_ related modules) results in a.b=15, which is invalid, because it actually looses information.
> This is basically similar for other formats. This change defines that list entries are mapped to arrays as follows:
> {{a[0].b=23}}
> {{a[1].b=15}}
> This syntax does not loose information and is simple enough to reestablish access logic such as 
> {{List<Map<String,String>> as = configuration.query(ListQuery.of("a"));}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)