How to initialize Property with empty string?

[Erich Eichinger]

Hi all,

I can't initialize a property with an empty string:

<property name="mystringprop" value="" />

because according to the xml-schema value is of type "nonNullString" which need a minimum length of 1.

Is this a bug or are there some reasons for this?

cheers,
Erich

[Aleks Seovic]

I don't think there is a good reason, even if there is one. What you are trying to do should definitely be allowed, although I would probably prefer to set it to String.Empty explicitly...

- Aleks

[Erich Eichinger]

Originally Posted by Aleks Seovic

I would probably prefer to set it to String.Empty explicitly

How would you do that?

Writing

<property name="mystringprop" value="string.Empty" />

results in mystringprop="string.Empty".

<property name="TestData"><object type="System.String" /></property>

gives an error since System.String doesn't have a public no-argument ctor. Passing an argument results in the same problem of how to pass string.Empty.

And coming up with a PropertyRetrievingFactoryObject is imho a slight overkill for injecting an empty string...


Edit:

I just found an easy solution:

<property name="TestData"><value /></property>

works.



Btw:
I was looking at Spring.Expressions to find a way, but had no luck (they are not used in this case). But I had an idea: What about adding some "ExpressionFactoryObject" to Spring.Core? Since expressions are a real mighty tool, one could easily inject many things with less xml-verbosity.

e.g. above problem could be solved with

<property name="TestData"><value type="ExpressionEvaluatingFactoryObject">String.Empty</value></property>

Of course any expression may be used here. It's result just needs to be convertible to string (in this case)

cheers,
Erich

[Bruno Baia]

Originally Posted by Erich Eichinger

Btw:
I was looking at Spring.Expressions to find a way, but had no luck (they are not used in this case). But I had an idea: What about adding some "ExpressionFactoryObject" to Spring.Core? Since expressions are a real mighty tool, one could easily inject many things with less xml-verbosity.

e.g. above problem could be solved with

<property name="TestData"><value type="ExpressionEvaluatingFactoryObject">String.Empty</value></property>

Of course any expression may be used here. It's result just needs to be convertible to string (in this case)

cheers,
Erich

Hi,

or something like this :

<property name="TestData"><eval>String.Empty</eval></property>

That's something I'm doing for a basic WPF integration :

<ItemsControl ItemsSource="{s:Eval '@TheMovieLister.GetAllMovies()'}" />

- Bruno

[Erich Eichinger]

Hi,

I made JIRA entries for both the bug above (#SPRNET-379) and the "DI by expressions"-feature (#SPRNET-378)

cheers,
Erich

[Aleks Seovic]

Yeah, I agree that we should be able to use expressions to set property values.

Probably the best approach would be to add expression attribute and element to the configuration schema, which could be used wherever value attribute/element is used.

That way you would be able to set your empty string like this:

<property name="mystringprop" expression="String.Empty" />

or this

<property name="mystringprop" expression="''" /> (single quotes are used to specify an empty string expression)

- Aleks

[Bruno Baia]

Hi,

Added an issue in JIRA about the expression attribute/element and an IFactoryObject Implementation that returns an Expression evaluation :

<object id="logger" type="ExpressionEvaluatorFactoryObject">
   <property name="expression" value="IMpsLogMgr.getLogger("com.foo.bar")"/>
</object>

[Edit]
Oups, just remember that Erich already added one issue about this...
[/Edit]

Bruno

[Aleks Seovic]

I see that you two started to create duplicate issues for this and decided that it should be fixed before there are 10 more related issues in JIRA

This feature has been implemented and tested and it's in the CVS. It should be in the nightly build as soon as CI server issues are resolved.

- Aleks

[Bruno Baia]

Originally Posted by Aleks Seovic

I see that you two started to create duplicate issues for this and decided that it should be fixed before there are 10 more related issues in JIRA

Don't think you are safe by fixing it, I can still create another issue for the documentation

Bruno