Empty string in "//name-values/values" attribute v

[Dennis Homann]

The validation of an object definition such as

<object ...>
<property name="...">
<name-values>
<add key="myKey" value=""/>
</name-values>
</property>
</object>

fails, because the schema defines the "values" attribute value as a nonNullString. How can I set a value to an empty string? Shouldn't the schema be changed and allow for empty strings?

Thank you,
Dennis

[Mark Pollack]

Hi Dennis,

I agree - emtpy strings should be allowed. I've changed the schema, added a test and will commit to CVS later today when I have access. I'll update the schema on the web as well.

Thanks for reporting this.

I've thought of adding an optional attribute to the name-value element; multi-value. This would interpret a comma separated list as multiple additions to the NameValueCollection. So the code


<property name="nvProp">
<name-values multi-value="true">
<add key="myKey" value="foo,qwerty,asdf"/>
</name-values>
</property>


would result in

string[] ss = obj1.nvProp.GetValues("myKey");

ss[0] = [foo]
ss[1] = [qwerty]
ss[2] = [asdf]

What do you think?

Cheers,
Mark

[Dennis Homann]

Hi Mark,

Sounds good. Thanks for fixing the issues so quickly!

Dennis

[MikeC]

Hi Dennis,

I agree - emtpy strings should be allowed. I've changed the schema, added a test and will commit to CVS later today when I have access. I'll update the schema on the web as well.

Thanks for reporting this.

I've thought of adding an optional attribute to the name-value element; multi-value. This would interpret a comma separated list as multiple additions to the NameValueCollection. So the code


<property name="nvProp">
<name-values multi-value="true">
<add key="myKey" value="foo,qwerty,asdf"/>
</name-values>
</property>


would result in

string[] ss = obj1.nvProp.GetValues("myKey");

ss[0] = [foo]
ss[1] = [qwerty]
ss[2] = [asdf]

What do you think?

Cheers,
Mark

What happens if you WANT a comma in the string? How do you "escape" it?

[Mark Pollack]

Hi,

Good point, we could specify a character separator that Spring would tokenize on.


<name-values multi-value="true" token=":">
<add key="myKey" value="foo,qwerty:asdf"/>
<name-value>


Would result in


string[] ss = obj1.nvProp.GetValues("myKey");

ss[0] = [foo,qwerty]
ss[1] = [asdf]


Whaddaya think?

[Rick Evans]

Hiya

On a related note, Spring.NET already supports the automatic conversion of comma-delimited strings to their appropriate Type[] arrays.

For example, the string 'true,false,true' when assigned to a bool[] property or ctor-argument gets converted into the equivalent bool[] { true, false, true } array (C# syntax).

Good point about the choice of delimiter though. The above functionality does have that limitation to it (i.e. delimiters must be commas - not an unreasonable default, but it doesn't accomodate corner cases). I'll raise a JIRA issue concerning this.

Ciao
Rick

[Mark Pollack]

Hi,

The corner case is taken care of by specifying the token/delimiter explicity.

- Mark

[Rick Evans]

Hiya

Cheers dude :wink: I was referring to the current implementation, the one that is in place now in the CVS HEAD.

I've updated the relevant JIRA issue to point back to this thread for easy reference when the time comes round to implement said feature.

Rather than adding more configuration attributes into the XML (schema), how about a custom IFactoryObject implementation? We already get enough brickbats thrown our way concerning the perceived complexity of the XML configuration.

Of course, we could always supply another configuration implementation that makes handling cases such as this this so much easier... JScript.NET :D

Ciao
Rick

[Mark Pollack]

Hi,

Yea, I'm all for keeping the number of xml tag/elements to a minimum but this is a variation on an existing config tag so I'm more tolerant to this type of expansion. The other factor pushing me in the direction of additional elements is that it seems odd to switch to a factory style configuration when needing this feature for name-values. Hmmm, guess we need some more votes :)

Cheers,
Mark