This project is read-only.

TreeView raises NullPointer Exception

Apr 23, 2013 at 8:21 AM
I would like to use the TreeView Control to display an organizational structure.

This works fine if I use nodes with a children property of type List as following:
    public class OrgUnit
        public int Id { get; set; }
        public string OrgName { get; set; }
        public ICollection<OrgUnit> Children { get; set; }

        public OrgUnit(int id, string name)
            Id = id;
            OrgName =name;
            Children = new List<OrgUnit>();
But I'm using Entity Framework 5 (Database First). And the auto generated Entity class creates the Children as HashSet, which leads to a NullPointer Exception.
Children = new HashSet<OrgUnit>();
My current workaround: I changed the T4 Template (*.tt) to generate List instead of HashSet.

Is there a chance, that also a children list of type Hashset is supported in the near future?
Or is there another proposal beside changing the T4 Template?

Apr 23, 2013 at 11:05 AM
Edited Apr 23, 2013 at 11:06 AM
Actually, children are not required to be lists, but just an ICollection! Now most of classes that implement ICollection<T> implement also ICollection. Th HashSet<T> class belong to the minority that implements ICollection<T> but doesnt implement ICollection ....for some obscure reason!!!

Anyway this is a problem raised also by other people, so we will try to find a solution. We cant check for ICollection<M> since the type of the children may change in descendant in general we cant forecast type M. However, since all items are required to be ISafeCreation probably we may check for ICollection<ISafeCreation>. Not sure this will work because in general also if M implements ISafeCreation, there is no relation betwee ICollection<M> and ICollection<ISafeCreation>, since differently from IEnumerable<T>, ICollection<T> is neither covariant, not controvariant (see Covariance and Contravariance in Generics)

So I can promit we will review again the issue, but I cant promit we will find a solution....

Anyway...yes there is another solution....the solution is avoiding the use of EF classes in the presentation layer, is not a good pattern, because this way your presentation layer and business layer will be dependent one from the other. A common solution is to put EF classes in a different dll, and to define also a third dll that contains all stuffs used for ensuring communications among business and presentation layer. This means the interface dll will contain classes(that mimics the EF classes) + all Interfaces needed by the "Repository Pattern". The interface dll is among the references of both business and presentation layer....and it is the only connection among the two layers. Dependency injection in the Mvc controllers is used to create concrete instances of the repository interfaces....

Read something about Mvc+Dependency Injection, and about Repository Pattern to know more.
Apr 23, 2013 at 5:06 PM

We prepared a version that is able to work with both ICollection and ICollection<T> for the children...and it appears to work, though we have not done exaustive testing.

We will release in a short time s bug fix 2.4.1 release, before releasing it I will send you a preliminary copy so you can test it in your environment.