#3 Support for lists of pairs key-value

[Jorge Ferrer]

Similar to the current support of lists it would be
great to be able to specify the following value:

property-name=key1:value1,key2:value2

This could be converted to a list of objects of a very
simple class of the form:

public class KeyValuePair {
private String key;
private String value;
// .... getters and setters .....
}

[Jorge Ferrer]

Logged In: YES
user_id=954801

Recently Brian Chan proposed being able to retrieve all the
different selector values used for a property. For example,
from:
icon[gif]=1.ico
icon[jpg]=2.ico
icon[png]=3.ico
It should be possible to obtain a list "gif,jpg,png".
Discussing this idea with Kortatu we thought about being
able to obtain a full map out of this, using the selectors
as keys.

Later we thought about two difficulties:
1) What happens if there are several nested selectors? For
example:
skin[teacher]=blue
skin[student][softmore]=silver
The solution proposed by kortatu was to create maps of maps
when needed. I agreed this is a good solution.

2) What happens when for 'default values'? For example:
skin=red
skin[student][softmore]=silver
We found no simple solution for this.

[Jorge Ferrer]

Logged In: YES
user_id=954801

After thinking about the feature presented in the previous
comment, I have thought about another way to implement the
"Map property". Instead of using selectors a different
functionality could be used: keys. Which allow creation of
maps with a much nicer format that the one originally
presented in this RFE:

property-name(key1)=value1
property-name(key2)=value2
property-name(key3)=value3

This property could be read using a new method of
ComponentProperties:
public Map getMap(String propertyName);

For example:
Map myProp = getProperties().getMap("property-name");

From this map is is possible to obtain all the keys or an
specific value.
It could also be implemented one way to obtain a property
value directly, but I don't see what value it could have.

Another extra feature is to allow maps nesting. This could
be easyly implemented if it is needed.

Further explanation: the reason why I'm proposing a
different syntax is because I think that treating selectors
as map keys goes against their nature. They should be
considered a facility that the developers gives to the guy
that writes the configuration, but it is an OPTIONAL
facility. So no programming logic should be based on how
many selectors have been used.

[Alvaro Gonzalez]

Logged In: YES
user_id=1269129

Well, it seems good to me. I like the (key) syntax (similar
to struts mapped properties), but i think the meaning is
just the same as one-level selectors. Could it be a little
confusing? Since I could represent the same thing in two ways:

property[key1]=value1
property[key2]=value2
...
and

property(key1)=value1
property(key2)=value2
...

Both of them represents a mapping between key1-value1 and
key2-value2. Why I must write them in two different ways
depending of the use given by the programmer?
Perhaps the guy that writes down the configurations doesn't
know if the user wants to obtain just one value for a key
(using Filters) or the whole map of keys-values to iterate
over them.

I see the problem on using [] for maps, because the
selectors are more permissive with nesting. What would
happens if i ask for the map and in the config file there is
something like:

property=default
property[key1]=value1
property[key2]=value2
property[key1][key1.1]=value1.1
?
I propose that the getMap("property") returns only the first
level map., at least until we find a good solution for
nested maps. Will be this too confusing?