Agreed. I've found that repeated elements are the best way to do a list.
[to commons-config developers]
So in .properties:
foo.name=fred
foo.name=jim
creates a List
In .xml:
<foo>
<name>fred</name>
<name>jim</name>
</foo>
Though I do currently have a problem with:
...
<foo><name>fred</name></foo>
<foo><name>jim</name></foo>
...
as it puts them in the same list, rather than understanding some kind of
hierarchical concept, which might not be easy to even specify in a
.properties file.
Hen
On Sun, 29 Feb 2004, Basil James Whitehouse III wrote:
> I've been using a commons-configuration nightly build from February 15,
> 2004 rather successfully. Recently I have run into a problem with
> strings containing a comma "," in them.
>
> I'm using XML to store properties, here's an example of the XML that is
> causing me grief.
>
> <configuration>
> <message-text>A message, with a comma.</message-text>
> <configuration>
>
> When I use .getString( "message-text" ) the resulting property value is
> "A message", whereas I expected the full string. If the comma is
> escaped (\,) then the resulting value is as expected ("A message, with a
> comma."). While escaping a string isn't that difficult, nor uncommon,
> for a developer, it's not something I'd want the lay person to have to
> do, and it's easy to forget that it needs to be escaped. BTW: this
> particular bit of configuration is going to be done by an average user
> who is competent with XML structures, but not much beyond that.
>
> From looking at the source I figured out that the comma is used to
> create a List, and I could in fact recreate the text (if the comma is
> not escaped) by running though the list and adding back in the commas.
> While I've only glanced at the source, this doesn't seem like the best
> approach since if the token changes in the future, or there are
> additional tokens added (like a semi-colon), then I'd have to figure out
> what token was used. It also seems like a List would be returned if the
> same property was defined twice in the same file, which I wouldn't be
> able to tell the difference that and a string with a comma in it. As
> well right now I'm going to assume that there's only going to be one
> message, but I can think of future cases where I might find multiple
> property definitions handy, but also want a string with commas in it, in
> the same file.
>
> So I guess my question is, can this behavior be changed? If .getString
> is used could it return the whole string for the given property, and if
> .getList was used could it parse the property then and give it back as a
> List?
>
> Looking at the source I think I've found the bit that does the string
> parsing, AbstractConfiguration.addProperty calls processString which
> parses out a List based on commas. My cursory glance made me think that
> processString could be called in getList, and hence getString would
> return the complete string, but since I don't know how multiple
> properties with the same name (thus creating a list) are represented
> this may not be a correct guess. I don't presume to know all the
> details of the source, nor driving factors to make these decisions, so
> take my code commentary with some salt, but please consider this feature
> request.
>
> Let me know if I can provide any other information, I'd even be willing
> to create a test case to support this feature.
>
> Responses to my email would be appreciated since I'm not subscribed to
> the list.
>
> Thanks,
> Jamie.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
