Collection Support

[Tom Whitner]

I am trying to configure an object which contains a collection. Using the <list>, everything made sense until Spring reported that the collection property was not writeable. A little investigation uncovered this to be exactly the case. The collection property is defined with a "getter" only. I would guess that Spring is using the <list> to create a new collection and then fails when attempting to set it on the parent object. Am I at least understanding how the collection support works? Also, what is the work around for this condition. Plenty of classed in .NET have get-only collections. Is it possible to enter a collection or array as an object entry? At least this way, I could copy the items in.

Thanks,
Tom

[Aleks Seovic]

Hi Tom,

You are right, we used to throw an exception as soon as we find out that property is not writeable, which should not always be the case.

I modified functionality a bit so now it checks if property it is trying to set is IList, and if it is it simply tries to add all the elements. It still might fail if the list itself is read-only or fixed size, but that's usually not the case.

Right now it only works for read-only IList properties, but I need to do some refactoring that will apply similar logic to collections in general, including dictionaries. Keep in mind that same logic does not apply to arrays, as they are always fixed size.

You can get the latest code from CVS and try your scenario again. If it still breaks I would appreciate if you could send me sample class and your config file so I can include them in our test suite.

Thanks,

Aleks

[Tom Whitner]

This seems to work well. I am wondering if you should call Clear() on the IList before adding the items. This would be functionally equivalent to setting a new collection if the property were writeable. Otherwise, you may leave items in the collection if they existed. I also stumbled a lttle because Spring.Context.dll seems to have disappeared. The classes move into Spring.Core.dll. This makes sense, but caused a small headache. Mainly because my config file needed to be modified since the ConfigSectionHandler moved.

Thanks,
Tom

[Mark Pollack]

Hi,

Sorry, I should have given you a heads up on the reorg of the .dlls.... you seem to have figured it out though. You can find more info about the new project .dll structure here (http://opensource.atlassian.com/confluence/spring/display/NET/Project+Structure).

We are planning on adding clear functionality for lists and also override functionality for dictionaries as optional attributes.

Cheers,
Mark

[Aleks Seovic]

Hi Tom,

Mark and I discussed adding clear/truncate attribute to the list element after your original post and agreed that it might be useful, but when I started working on a fix for your original problem I realized that this would not be as simple to implement as I first thought.

So the questions are:

1. Do we really need clear functionality to be user selectable or is appropriately selected default good enough?

2. If default value is good enough, should we clear list by default or leave it as it is (current behavior).

I tend to lean towards having a default of leaving the list unchanged, as it currently works. The reason for this is that I can't think of a scenario when a) initial list would not be empty, and b) I would want to truncate it before adding new values to it.

Of course, I also might not be very objective on this, because it will be a lot of unexciting work to make this behavior configurable. However, making clear() a default behavior is simple, one line of code, and it might make sense to do it if only to make behavior consistent with writeable properties where whole list is simply replaced.

Let me know what you think is the best approach from an end user's perspective and thanks for your early feedback.

Regards,

Aleks

[Mark Pollack]

Hi,

Just by way of an update, support for configuring read-only ISet and IDictionary properties was added.

Cheers,
Mark