We have a fairly large custom LOB app that, for the time being, requires that we support .net 2/3/3.5. So moving to .net or CSLA 4.0 is not currently an option.
In our recent WPF experiences, we've been running into lots of issues where we end up "wrapping" BLB collections in ObservableCollection<>. For ex., (from what my guys tell me) sorting/filtering automatically works with the DataGrid from the WPF toolkit (my guess is that grids from vendors like infragistics would work out of the box). In other cases, we are trying to do binding related to the SelectedItem property that (apparently) only works with an ObservableCollection.
Looking at the latest tags for CSLA 3.X and 4, we noticed that the CSLA 4.x code's BLB inherits from ObservableBindingList, which eventually inherits from Microsoft's ObservableCollection.
Is there something precluding this change from being implemented in 3.8? It seems like it would make a lot of functionality "just work" and a lot of annoying issues would also disappear. Is this just because the 3.8 codebase is providing more backwards support for Winforms?
Hi,
If you have to support .NET 2 then you do not have access to ObservableCollection.
Surely List classes that inherits from ObservableCollection could have been implemented in 3.8.x. But in Csla 4 this is a breaking change and List classes for BindingList has been renamed to offer continued support for WindowsForms applications and the regular list classes inherit from ObservableCollection.
Another very important change is that LinqIndexing is removed from the list classes.
Unfortunately - there is limited resources going into the development of Csla and I wouldn't expect to see these changes coming in Csla 3.8.x
The 3.8 codebase is in maintenance mode - major bug fixes only. All active development has been on CSLA 4 for about a year now, and 4.1 is in beta.
As Jonny said, there's limited dev resources for CSLA.
If someone wants to create a "CSLA 4 N3" version (CSLA 4 for .NET 3.5 SP1), I'm open to this idea. This is what Jonny did to create the N2 version - it was 3.6 and 3.7 backported to work (almost completely) with .NET 2.0. Very good stuff.
But to the original point - if you go back through the forum you'll find some very, very spirited debates about this topic. And a lot of angst on my part as I tried to find a decent solution (there isn't one).
Ultimately the only answer was a major breaking change - and if at all possible I hold those for major version changes (3.x to 4.x for example) because they break everyone across the board. That's not something I would choose to do within a major version unless it was SO important that almost nobody could use the framework without the change. And that wasn't the case with CSLA 3.8.
Copyright (c) Marimer LLC