commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [configuration] Release 1.2
Date Fri, 30 Sep 2005 15:15:21 GMT
Emmanuel Bourg wrote:

> Oliver Heger wrote:
>
>> - Bugzilla:
>> There are three tickets in the "need info" state, which can be closed 
>> because of lack of feedback. For 35858 we can decide whether the 
>> subset() implementation of HierarchicalConfiguration can be dropped. 
>
>
> It can't be removed right now due to an assertion that fails without 
> this specific implementation. I suggest to keep the method as is for 
> the next release and try to remove it for the 1.3 release.

Hm, I see. Depending on the way the subset is constructed the key passed 
in for the test is either interpreted as 
"(tables.table.fields.field.name)(0)" or as 
"tables.table.fields.field.(name(0))"; these expressions have different 
results. Okay, let's differ that to the 1.3 release.

[...]

>
> There are two issues left that are related to hierarchical 
> configurations in general, fixing these issues could also improve the 
> test coverage:
>
> 1) adding a List, or adding more than once a value with the same key 
> generates several nodes instead of a node with a List value.
>
> For example, with:
>
> config.addProperty("array", "1");
> config.addProperty("array", "2");
>
> The property list will look like this:
>
> {
>     array = 1;
>     array = 2;
> }
>
> instead of:
>
> {
>     array = (1, 2);
> }
>
> same thing with the xml variant:
>
> <plist>
>   <dict>
>     <key>array</key>
>     <string>1</string>
>
>     <key>array</key>
>     <string>2</string>
>   </dict>
> </plist>
>
> instead of:
>
> <plist>
>   <dict>
>     <key>array</key>
>     <array>
>       <string>1</string>
>       <string>2</string>
>     </array>
>   </dict>
> </plist>

Maybe a HierarchicalConfiguration could be made configurable to support 
both models for adding properties (always creating new nodes versus 
using existing ones). We could also define something like an 
AddPropertyStrategy, but this seems to be a bit of an overkill. In any 
case AFICT methods affected by this change would be addPropertyDirect() 
and getProperty().

What would be the semantics for indices? ATM indices are evaluated on a 
per node basis. So e.g. if a node has three values, it will be counted 
as 1, not as 3. Is this okay for acessing property values? Changes this 
could have a major impact I fear.

Oliver
[...]

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message